linux-kernel - Re: [RFC PATCH v2 1/2] workqueue: Unbind workers before sending them to exit()

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: <YuLH/l9YZYG6FRSW@slm.duckdns.org>
Date:   Thu, 28 Jul 2022 07:31:42 -1000
From:   Tejun Heo <tj@...nel.org>
To:     Valentin Schneider <vschneid@...hat.com>
Cc:     Lai Jiangshan <jiangshanlai@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Frederic Weisbecker <frederic@...nel.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Phil Auld <pauld@...hat.com>,
        Marcelo Tosatti <mtosatti@...hat.com>
Subject: Re: [RFC PATCH v2 1/2] workqueue: Unbind workers before sending them
 to exit()

Hello,

On Thu, Jul 28, 2022 at 06:24:17PM +0100, Valentin Schneider wrote:
> > I don't understand why this would need MEM_RECLAIM when it isn't sitting in
> > the memory reclaim path. Nothing in mm side can wait on this.
> 
> Vaguely reading the doc I thought that'd be for anything that would
> directly or indirectly help with reclaiming memory (not explicitly sitting
> in some *mm reclaim* path), and I assumed freeing up a worker would count as
> that - but that's the understanding of someone who doesn't know much about
> all that :-)

Oh, it's just needed for things that mm might end up waiting on. Here,
there's no way for mm to know about or trigger this at all, so it doesn't
need the flag.

> > There actually are spurious wakeups. We can't depend on there being no
> > wakeups than ours.
> 
> Myes, I suppose if a to-be-destroyed kworker spuriously wakes before having
> been unbound then there's not much point in having the unbinding (harm has
> been done and the kworker can do_exit(), though arguably we could reduce
> the harm and still move it away), but let me see what I can do here.

Yeah, it kinda sucks but is a kernel-wide thing and pretty rare, so for the
most part, we can pretend that they don't exist but under specific
conditions, there can be asynchronous wakeups coming from whereever, so we
gotta be crash proof against those.

Thanks.

-- 
tejun