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

From: Rusty Russell
Date: Wed Nov 14 2007 - 21:36:04 EST


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@xxxxxxxxxxxxxxx>
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.

Signed-off-by: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
---
drivers/scsi/scsi_tgt_lib.c | 11 +++--------
1 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/scsi_tgt_lib.c b/drivers/scsi/scsi_tgt_lib.c
index a91761c..66266c8 100644
--- a/drivers/scsi/scsi_tgt_lib.c
+++ b/drivers/scsi/scsi_tgt_lib.c
@@ -367,14 +367,9 @@ static int scsi_tgt_init_cmd(struct scsi_cmnd *cmd, gfp_t gfp_mask)

dprintk("cmd %p cnt %d %lu\n", cmd, cmd->use_sg, rq_data_dir(rq));
count = blk_rq_map_sg(rq->q, rq, cmd->request_buffer);
- if (likely(count <= cmd->use_sg)) {
- cmd->use_sg = count;
- return 0;
- }
-
- eprintk("cmd %p cnt %d\n", cmd, cmd->use_sg);
- scsi_free_sgtable(cmd);
- return -EINVAL;
+ BUG_ON(count > cmd->use_sg);
+ cmd->use_sg = count;
+ return 0;
}

/* TODO: test this crap and replace bio_map_user with new interface maybe */
--
1.5.2.5




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