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 10:20:05 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Michal Hocko <mhocko@...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

Hello,

On Mon, Aug 01, 2016 at 03:50:36PM +0200, Michal Hocko wrote:
> > 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.
...
> > 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).

Oliver, Alan, what do you think?  If USB itself can't operate without
allocating memory during transactions, whatever USB storage drivers
are doing isn't all that meaningful.  Can we proceed with the
workqueue patches?  Also, it could be that the only thing GFP_NOIO and
GFP_ATOMIC are doing is increasing the chance of IO failures under
memory pressure.  Maybe it'd be a good idea to reconsider the
approach?

Thanks.

-- 
tejun