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] [thread-next>] [day] [month] [year] [list]

Message-ID: <874kmdfndd.fsf@nanos.tec.linutronix.de>
Date:   Thu, 29 Oct 2020 09:27:26 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "Zhang\, Qiang" <Qiang.Zhang@...driver.com>,
        "pmladek\@suse.com" <pmladek@...e.com>,
        "tj\@kernel.org" <tj@...nel.org>
Cc:     "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 03:14, Qiang Zhang wrote:
> Really, this patch is not considered that work may be put into the
> queue after the bound CPU is offline.  in addition, when the bound CPU
> goes online again, before restoring the worker's CPU affinity, work
> may be put into the queue.

And how is that supposed to be correct?

> Although int this (powerclamp) way，that's not a problem, that it is
> solved by destroying and creating tasks when the CPU hotplug, in
> addition, when CPU going down , this need call 'cancel_work_sync' func
> in offline callback, this may be blocked long time. these operation is
> expensive.

It does not matter whether it's expensive or not. It's correct and
that's what matters most.

> this patch only just to recover the worker task's affinity when CPU go
> to online again that create by "kthread_create_worker_on_cpu" func ,
> likely per-CPU worker method when CPU hotplug in "workqueue" and
> "io-wq".

I know what this patch just does, but that makes it not any more
correct. It creates a semanticaly ill defined illusion of correctness.

We are not "fixing" a problem by making it work for your particular and
even not explained use case.

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.

Thanks,

        tglx