Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760272Ab3CIC7c (ORCPT ); Fri, 8 Mar 2013 21:59:32 -0500 Received: from netrider.rowland.org ([192.131.102.5]:51587 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1760092Ab3CIC7a (ORCPT ); Fri, 8 Mar 2013 21:59:30 -0500 Date: Fri, 8 Mar 2013 21:59:29 -0500 (EST) From: Alan Stern X-X-Sender: stern@netrider.rowland.org 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 In-Reply-To: <2925850.6XPAdGF0iQ@linux-5eaq.site> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1867 Lines: 44 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 (linuxtesting.org). > > > > 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 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/