Re: [PATCH] Attempt to get eject failures back to ioctl(CDROMEJECT)

[Jens Axboe <jens.axboe@oracle.com>]

On Thu, Nov 15 2007, Rusty Russell wrote:
> On Wednesday 14 November 2007 23:39:31 Jens Axboe wrote:
> > On Wed, Nov 14 2007, Rusty Russell wrote:
> > > Hi Jens,
> > >
> > >     As you asked for some time ago.  Of course, it turns out that the
> > > eject command ignores the error anyway, but it's nice that it now errors.
> > >
> > >     Not entirely comfortable with this patch: there's a req->errors but
> > > that seems to have some existing semantics I'm not sure of, so I simply
> > > added a new way of flagging an error.
> >
> > It is a bit of a hack, but it's not really your fault. ->errors is
> > somewhat messy and has different meaning depending on the request type.
> > I'll add your patch and then do a sanitize on top of it, so that we can
> > switch things over to a unified ->errno instead.
> 
> Thanks!
> 
> Oh, I also noticed this in scsi_tgt_lib:
> 
> From: Rusty Russell <rusty@rustcorp.com.au>
> Date: Fri, 9 Nov 2007 20:04:54 +1100
> Subject: [PATCH] scsi_tgt_lib: BUG_ON() impossible condition.
> 
> If blk_rq_map_sg returns more than was allocated, it's a bug, and something's
> already been overwritten.  BUG_ON() is probably the right thing here.

It really just means that it mapped more segments than the block layer
said it would. Usually that wont overwrite memory here since scsi rounds
up on allocating the sg list, but it indeed can. Similar code has been
in scsi_lib.c for ages, I'd suggest covering that in the same patch.

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/