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]
Date:	Wed, 27 Aug 2014 10:13:03 -0400
From:	Joe Lawrence <joe.lawrence@...atus.com>
To:	Jeff Moyer <jmoyer@...hat.com>
CC:	Jens Axboe <axboe@...nel.dk>, <linux-kernel@...r.kernel.org>,
	"Jiri Kosina" <jkosina@...e.cz>,
	Boaz Harrosh <bharrosh@...asas.com>
Subject: Re: [PATCH v3 0/2] block,scsi: fixup blk_get_request dead queue
 scenarios

On Tue, 26 Aug 2014 18:01:23 -0400
Jeff Moyer <jmoyer@...hat.com> wrote:

> Jens Axboe <axboe@...nel.dk> writes:
> 
> >> I have applied the first one, will look over the second one and hand
> >> apply it. Seems the NULL return was completely removed, so we _should_
> >> be ok on the IS_ERR() conversion, though that sort of thing always
> >> worries me a little bit. A NULL return can quickly show up again, and
> >> then they would all fail.
> 
> Well, we could guard against that with a BUG_ON in blk_get_request,
> right?

Since the two error cases (ENOMEM and ENODEV) are rare exceptions,
could the reintroduction of a NULL return slip by a quick bench test?

> > Additionally, there's still quite a few places that call
> > blk_get_request() and don't check the error return if __GFP_WAIT is set.
> > Since most of the point of this is to fix segfaulting on queue dead
> > scenarios, why aren't they all converted?
> 
> Odd, I thought they all were converted last I checked.  They definitely
> should be.

I largely left the ide-*.c files alone.  The only guy who bothered
checking the blk_get_request return was ide-park, which I updated with
IS_ERR.  If the others should be hardened (I assumed these were mostly
deprecated drivers), I can add that code in a v3.

Jens, were there other callers that were missed?  I'm using cscope to
find them, so perhaps I inadvertently filtered a file out of the search.

Regards,

-- Joe
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ