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] [day] [month] [year] [list]
Date:   Wed, 9 Dec 2020 10:25:43 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     "David S . Miller" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Horatiu Vultur <horatiu.vultur@...rochip.com>,
        "Allan W . Nielsen" <allan.nielsen@...rochip.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Steen Hegelund <steen.hegelund@...rochip.com>
Subject: Re: [PATCH v3 net-next] net: mscc: ocelot: install MAC addresses in
 .ndo_set_rx_mode from process context

On Wed, 9 Dec 2020 01:56:14 +0000 Vladimir Oltean wrote:
> On Mon, Dec 07, 2020 at 05:09:37PM -0800, Jakub Kicinski wrote:
> > > +	ocelot->owq = alloc_ordered_workqueue("ocelot-owq", WQ_MEM_RECLAIM);  
> >
> > Why MEM_RECLAIM ?  
> 
> Ok, fine, I admit, I copied it.
> 
> After reading the documentation a bit more thoroughly, I am still as
> clear about the guidelines as before. The original logic was, I am
> allocating a memory area and then freeing it from the work item. So it
> must be beneficial for the kernel to want to flush this workqueue during
> the memory reclaim process / under memory pressure, because I am doing
> no memory allocation, and I am also freeing some memory in fact.
> 
> The thing is, there are already a lot of users of WQ_MEM_RECLAIM. Many
> outside of the filesystem/block subsystems. Not sure if all of them
> misuse it, or how to even tell which one constitutes a correct example
> of usage for WQ_MEM_RECLAIM.

Agreed, I wasn't 100% sure either.

I double checked with Tejun, he says it's only needed if the work 
queue is directly used in memory reclaim paths, like writing pages 
out to swap and such.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ