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 19:21:06 +0000
From:   Valentin Schneider <valentin.schneider@....com>
To:     Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>
Cc:     Lai Jiangshan <jiangshanlai@...il.com>,
        linux-kernel@...r.kernel.org, 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 11/01/21 18:16, Peter Zijlstra wrote:
> Sadly it appears like io_uring() uses kthread_create_on_cpu() without
> then having any hotplug crud on, so that needs additinoal frobbing.
>

I noticed that as well sometime ago, and I believed then (still do) this
usage is broken. I don't think usage of kthread_create_on_cpu() outside
of smpboot makes sense, because without any hotplug step to park the
thread, its affinity can end up being reset after its dedicated CPU gets
offlined.

I'm clueless about io_uring, but if it *actually* has a good reason to
use some pcpu kthreads (it seems it doesn't have to be on all CPUs?),
then it needs to register some hotplug step to park them / do something
sensible on hotplug.

> Also, init_task is PF_KTHREAD but doesn't have a struct kthread on.. and
> I suppose bound workqueues don't go through this either.
>
> Let me rummage around a bit...
>
> This seems to not insta-explode... opinions?
>

I like having a proper distinction between 'intended' and 'accidental'
pcpu kthreads.

I'm less fond of the workqueue pcpu flag toggling, but it gets us what
we want: allow those threads to run on !active CPUs during online, but
move them away before !online during offline.

Before I get ahead of myself, do we *actually* require that first part
for workqueue kthreads? I'm thinking (raise alarm) we could try another
approach of making them pcpu kthreads that don't abide by the !active &&
online rule.

> ---
>  include/linux/kthread.h |  3 +++
>  kernel/kthread.c        | 25 ++++++++++++++++++++++++-
>  kernel/sched/core.c     |  2 +-
>  kernel/sched/sched.h    |  4 ++--
>  kernel/smpboot.c        |  1 +
>  kernel/workqueue.c      | 12 +++++++++---
>  6 files changed, 40 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 15d2562118d1..e71f9e44789e 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -7277,7 +7277,7 @@ static void balance_push(struct rq *rq)
>        * Both the cpu-hotplug and stop task are in this case and are
>        * required to complete the hotplug process.
>        */
> -	if (is_per_cpu_kthread(push_task) || is_migration_disabled(push_task)) {
> +	if (rq->idle == push_task || is_per_cpu_kthread(push_task) || is_migration_disabled(push_task)) {

I take it the p->set_child_tid thing you were complaining about on IRC
is what prevents us from having the idle task seen as a pcpu kthread?

>               /*
>                * If this is the idle task on the outgoing CPU try to wake
>                * up the hotplug control thread which might wait for the
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index 12ada79d40f3..3679f63e0aa2 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -2697,10 +2697,10 @@ static inline bool is_per_cpu_kthread(struct task_struct *p)
>       if (!(p->flags & PF_KTHREAD))
>               return false;
>
> -	if (p->nr_cpus_allowed != 1)
> +	if (!(p->flags & PF_NO_SETAFFINITY))
>               return false;
>
> -	return true;
> +	return kthread_is_per_cpu(p);
>  }
>  #endif
>
> diff --git a/kernel/smpboot.c b/kernel/smpboot.c
> index 2efe1e206167..b0abe575a524 100644
> --- a/kernel/smpboot.c
> +++ b/kernel/smpboot.c
> @@ -188,6 +188,7 @@ __smpboot_create_thread(struct smp_hotplug_thread *ht, unsigned int cpu)
>               kfree(td);
>               return PTR_ERR(tsk);
>       }
> +	kthread_set_per_cpu(tsk, true);
>       /*
>        * Park the thread so that it could start right on the CPU
>        * when it is available.
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index 9880b6c0e272..824276e4fb2e 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -1861,6 +1861,8 @@ static void worker_attach_to_pool(struct worker *worker,
>        */
>       if (pool->flags & POOL_DISASSOCIATED)
>               worker->flags |= WORKER_UNBOUND;
> +	else
> +		kthread_set_per_cpu(worker->task, true);
>

I thought only pcpu pools would get the POOL_DISASSOCIATED flag on
offline, but it seems unbound pools also get it at init time. Did I get
that right?

Also, shouldn't this be done before the previous set_cpus_allowed_ptr()
call (in the same function)? That is, if we patch
__set_cpus_allowed_ptr() to also use kthread_is_per_cpu().

>       list_add_tail(&worker->node, &pool->workers);
>       worker->pool = pool;