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:	Mon, 1 Aug 2016 15:50:36 +0200
From:	Michal Hocko <mhocko@...nel.org>
To:	Tejun Heo <tj@...nel.org>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	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>,
	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,
	Johannes Weiner <hannes@...xchg.org>
Subject: Re: [RFC] usb: host: u132-hcd: Remove deprecated
 create_singlethread_workqueue

On Fri 29-07-16 09:11:47, Tejun Heo wrote:
> Hello, Alan.
> 
> On Wed, Jul 27, 2016 at 04:45:19PM -0400, Alan Stern wrote:
> > > 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.
> 
> All that would do is deferring the deadlock, right?  I'm not sure it
> makes a lot of sense to protect an IO path against memory pressure
> half-way.  It either can be depended during memory reclaim or it
> can't. 

Completely agreed! If the rescuer thread can block on a memory
allocation be it GFP_NOIO or others it is basically useless.

> The use of GFP_NOIO / ATOMIC is probably increases the chance
> of IO errors under moderate memory pressure too when there are
> dependable memory backing devices (and there better be) which can push
> things forward if called upon.
> 
> Can MM people please chime in?  The question is about USB stoage
> devices and memory reclaim.  USB doesn't guarantee forward progress
> under memory pressure but tries a best-effort attempt with GFP_NOIO
> and ATOMIC.  Is this the right thing to do?

If any real IO depends on those devices then this is not sufficient and
they need some form of guarantee for progress (aka mempool).
-- 
Michal Hocko
SUSE Labs