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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071115084705.GE638@kernel.dk>
Date:	Thu, 15 Nov 2007 09:47:05 +0100
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Attempt to get eject failures back to ioctl(CDROMEJECT)

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@...tcorp.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/