[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1607271637140.1664-100000@iolanthe.rowland.org>
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
Powered by blists - more mailing lists