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  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:	Fri, 8 Mar 2013 21:59:29 -0500 (EST)
From:	Alan Stern <>
To:	Oliver Neukum <>
cc:	Alexey Khoroshilov <>,
	Greg Kroah-Hartman <>,
	Hans de Goede <>,
	USB list <>,
	Kernel development list <>,
Subject: Re: [PATCH] usb/core/devio.c: Don't use GFP_KERNEL while we cannot
 reset a storage device

On Fri, 8 Mar 2013, Oliver Neukum wrote:

> On Friday 08 March 2013 12:55:08 Alan Stern wrote:
> > On Sat, 9 Mar 2013, Alexey Khoroshilov wrote:
> > 
> > > As it was described by Oliver Neukum in commit acbe2fe
> > > "USB: Don't use GFP_KERNEL while we cannot reset a storage device":
> > > 
> > >   Memory allocations with GFP_KERNEL can cause IO to a storage device
> > >   which can fail resulting in a need to reset the device. Therefore
> > >   GFP_KERNEL cannot be safely used between usb_lock_device()
> > >   and usb_unlock_device(). Replace by GFP_NOIO.
> > > 
> > > The patch fixes the same issue in usb/core/devio.c.
> > > All the allocations fixed are under usb_lock_device() from usbdev_do_ioctl().
> > > 
> > > Found by Linux Driver Verification project (
> > 
> > I don't know if this is a good idea.  People can and do submit 
> > transfers requiring a lot of buffer space.  Switching to GFP_NOIO 
> > will make those allocations a lot more likely to fail.
> > 
> > Oliver, what do you think?
> Ideally we'd split memory allocation and use, by it fixes a bug.
> Better allocation failure than deadlock.

In fact we wouldn't deadlock.  This is because 
usb_lock_device_for_reset() gives up if it can't obtain the device lock 
after one second of trying.  We'd just end up with a failure to reset, 
leading to an I/O failure.

Probably the mass-storage device would be taken off-line...  but there
wouldn't be a deadlock.  Under the circumstances, I'd say that the 
consequences of merging this patch would be worse than the consequences 
of keeping things as they are now.

Alan Stern

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists