linux-kernel - Re: [RFD] workqueue: WQ_MEM_RECLAIM usage in network drivers

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: <20160317213216.731d1fcc@synchrony.poochiereds.net>
Date:	Thu, 17 Mar 2016 21:32:16 -0400
From:	Jeff Layton <jlayton@...chiereds.net>
To:	Tejun Heo <tj@...nel.org>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Trond Myklebust <trond.myklebust@...marydata.com>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	Anna Schumaker <anna.schumaker@...app.com>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-nfs@...r.kernel.org,
	Amitoj Kaur Chawla <amitoj1606@...il.com>,
	kernel-team@...com, Johannes Weiner <hannes@...xchg.org>,
	Johannes Berg <johannes@...solutions.net>,
	Eva Rachel Retuya <eraretuya@...il.com>,
	Bhaktipriya Shridhar <bhaktipriya96@...il.com>,
	linux-wireless@...r.kernel.org
Subject: Re: [RFD] workqueue: WQ_MEM_RECLAIM usage in network drivers

On Thu, 17 Mar 2016 09:45:46 -0700
Tejun Heo <tj@...nel.org> wrote:

> Hello,
> 
> Years ago, workqueue got reimplemented to use common worker pools
> across different workqueues and a new set of more expressive workqueue
> creation APIs, alloc_*workqueue() were introduced.  The old
> create_*workqueue() became simple wrappers around alloc_*workqueue()
> with the most conservative parameters.  The plan has always been to
> examine each usage and convert to the new interface with parameters
> actually required for the use case.
> 
> One important flag to decide upon is WQ_MEM_RECLAIM, which declares
> that the workqueue may be depended upon during memory reclaim and thus
> must be able to make forward-progress even when further memory can't
> be allocated without reclaiming some.  Of the network drivers which
> already use alloc_*workqueue() interface, some specify this flag and
> I'm wondering what the guidelines should be here.
> 
> * Are network devices expected to be able to serve as a part of
>   storage stack which is depended upon for memory reclamation?
> 

I think they should be. Cached NFS pages can consume a lot of memory,
and flushing them generally takes network device access.

> * If so, are all the pieces in place for that to work for all (or at
>   least most) network devices?  If it's only for a subset of NICs, how
>   can one tell whether a given driver needs forward progress guarantee
>   or not?
> 
> * I assume that wireless drivers aren't and can't be used in this
>   fashion.  Is that a correction assumption?
> 

People do mount NFS over wireless interfaces. It's not terribly common
though, in my experience.

-- 
Jeff Layton <jlayton@...chiereds.net>