linux-kernel - Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread

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 Jul 2016 16:45:19 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Tejun Heo <tj@...nel.org>
cc:	Oliver Neukum <oneukum@...e.com>,
	Bhaktipriya Shridhar <bhaktipriya96@...il.com>,
	Geliang Tang <geliangtang@....com>,
	"GeyslanG.Bem@...yakshetra" <geyslan@...il.com>,
	Masanari Iida <standby24x7@...il.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Michal Hocko <MHocko@...e.com>,
	Vlastimil Babka <vbabka@...e.cz>,
	Mel Gorman <mgorman@...hsingularity.net>,
	Saurabh Karajgaonkar <skarajga@...teon.com>,
	<linux-kernel@...r.kernel.org>, <linux-usb@...r.kernel.org>
Subject: Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue

On Wed, 27 Jul 2016, Tejun Heo wrote:

> Hello, Alan.
> 
> On Wed, Jul 27, 2016 at 02:54:51PM -0400, Alan Stern wrote:
> > > Hmm... I didn't know the whole USB stack could operate without
> > > allocating memory.  Does usb stack have mempools and stuff all the way
> > > through?
> > 
> > No -- the USB stack does need to allocate memory in order to operate.  
> > But it is careful to use GFP_NOIO or GFP_ATOMIC for allocations that
> > might be on the block-device path.
> 
> Hmm... That doesn't really make them dependable during memory reclaim.

True.  But it does mean that they can't cause a deadlock by waiting
indefinitely for some other memory to be paged out to the very device
they are on the access pathway for.

> What happens when those allocations fail?

The same thing that happens when any allocation fails -- the original
I/O request fails with -ENOMEM or the equivalent.  In the case of 
usb-storage, this is likely to trigger error recovery, which will need 
to allocate memory of its own...  A bad situation to get into.

Alan Stern