linux-kernel - Re: [PATCH v2] kthread_worker: re-set CPU affinities if CPU come online

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]

Message-ID: <87pn51dqjp.fsf@nanos.tec.linutronix.de>
Date:   Thu, 29 Oct 2020 16:01:46 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Petr Mladek <pmladek@...e.com>
Cc:     "Zhang\, Qiang" <Qiang.Zhang@...driver.com>,
        "tj\@kernel.org" <tj@...nel.org>,
        "akpm\@linux-foundation.org" <akpm@...ux-foundation.org>,
        "linux-mm\@kvack.org" <linux-mm@...ck.org>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] kthread_worker: re-set CPU affinities if CPU come online

On Thu, Oct 29 2020 at 14:08, Petr Mladek wrote:
> On Thu 2020-10-29 09:27:26, Thomas Gleixner wrote:
>> The expected semantics of a cpu bound kthread_worker are completely
>> unclear and undocumented. This needs to be fixed first and once this is
>> established and agreed on then the gaps in the implementation can be
>> closed.
>
> I thought about some sane semantic and it goes down to
> the following problem:
>
> The per-CPU kthread workers are created by explicitly calling
> kthread_create_worker_on_cpu() on each CPU.
>
> The API does _not_ store the information how to start the worker.
> As a result, it is not able to start a new one when the CPU
> goes online "for the first time". I mean when the CPU was offline
> when the API user created the workers.
>
> It means that the API user is responsible for handling CPU hotplug
> on its own. We probably should just document it and do nothing else [*]

> [*] IMHO, it does not even make sense to manipulate the affinity.
>     It would just give a false feeling that it is enough.

Agreed on both.

> Alternative solution would be to extend the API and allow to create
> kthread_worker on each online CPU. It would require to store
> parameters needed to create the kthread only new online CPUs.
> Then we might think about some sane semantic for CPU hotplug.

That facility already exists: smpboot_register_percpu_thread()

So "all" you'd need to do is to provide a kthread_worker variant which
utilizes that. It's straight forward, but not sure whether it's worth
the trouble.

> Well, it might be hard to define a sane semantic unless there are
> more users of the API. So, I tend to keep it simple and just
> document the status quo.

Ack.

Thanks,

        tglx