linux-kernel - Re: [PATCH -tip V3 0/8] workqueue: break affinity initiatively

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, 11 Jan 2021 12:01:03 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Lai Jiangshan <jiangshanlai@...il.com>,
        linux-kernel@...r.kernel.org,
        Valentin Schneider <valentin.schneider@....com>,
        Qian Cai <cai@...hat.com>,
        Vincent Donnefort <vincent.donnefort@....com>,
        Dexuan Cui <decui@...rosoft.com>,
        Lai Jiangshan <laijs@...ux.alibaba.com>,
        Paul McKenney <paulmck@...nel.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH -tip V3 0/8] workqueue: break affinity initiatively

On Mon, Jan 11, 2021 at 11:07:34AM +0100, Thomas Gleixner wrote:
> On Fri, Jan 08 2021 at 12:46, Peter Zijlstra wrote:
> > On Sat, Dec 26, 2020 at 10:51:08AM +0800, Lai Jiangshan wrote:
> >> From: Lai Jiangshan <laijs@...ux.alibaba.com>
> >> 
> >> 06249738a41a ("workqueue: Manually break affinity on hotplug")
> >> said that scheduler will not force break affinity for us.
> >
> > So I've been looking at this the past day or so, and the more I look,
> > the more I think commit:
> >
> >   1cf12e08bc4d ("sched/hotplug: Consolidate task migration on CPU unplug")
> >
> > is a real problem and we need to revert it (at least for now).
> >
> > Let me attempt a brain dump:
> >
> >  - the assumption that per-cpu kernel threads are 'well behaved' on
> >    hot-plug has, I think, been proven incorrect, it's far worse than
> >    just bounded workqueue. Therefore, it makes sense to provide the old
> >    semantics.
> 
> I disagree. Per-cpu kernel threads which are magically stopped during
> hotplug and then migrated to a random other CPU are just wrong.
> 
> We really need to fix that and not proliferate the sloppy and ill
> defined behaviour.

Well yes, but afaict the workqueue stuff hasn't been settled yet, and
the rcutorture patch Paul did was just plain racy and who knows what
other daft kthread users are out there. That and we're at -rc3.

So I'm really tempted to revert for now and try again later.