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]
Message-ID: <20160801142005.GB2542@mtj.duckdns.org>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ