linux-kernel - Re: [PATCH 3/4] workqueue: Tag bound workers with KTHREAD_IS_PER

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: <jhjpn28zngy.mognet@arm.com>
Date:   Wed, 13 Jan 2021 18:43:57 +0000
From:   Valentin Schneider <valentin.schneider@....com>
To:     paulmck@...nel.org
Cc:     Lai Jiangshan <jiangshanlai@...il.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>, Qian Cai <cai@...hat.com>,
        Vincent Donnefort <vincent.donnefort@....com>,
        Dexuan Cui <decui@...rosoft.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Steven Rostedt <rostedt@...dmis.org>, Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH 3/4] workqueue: Tag bound workers with KTHREAD_IS_PER_CPU

On 13/01/21 09:52, Paul E. McKenney wrote:
> On Wed, Jan 13, 2021 at 02:16:10PM +0000, Valentin Schneider wrote:
>> You might be right; at this point we would still have BALANCE_PUSH set,
>> so something like the below could happen
>>
>>   rebind_workers()
>>     set_cpus_allowed_ptr()
>>       affine_move_task()
>>         task_running() => stop_one_cpu()
>>
>>   ... // Stopper migrates the kworker here in the meantime
>>
>>   switch_to(<pcpu kworker>) // Both cpuhp thread and kworker should be enqueued
>>                             // here, so one or the other could be picked
>>   balance_switch()
>>     balance_push()
>>     ^-- no KTHREAD_IS_PER_CPU !
>>
>> This should however trigger the WARN_ON_ONCE() in kthread_set_per_cpu()
>> *before* the one in process_one_work(), which I haven't seen in Paul's
>> mails.
>
> The 56 instances of one-hour SRCU-P scenarios hit the WARN_ON_ONCE()
> in process_one_work() once, but there is no sign of a WARN_ON_ONCE()
> from kthread_set_per_cpu().

This does make me doubt the above :/ At the same time, the
process_one_work() warning hinges on POOL_DISASSOCIATED being unset,
which implies having gone through rebind_workers(), which implies
kthread_set_per_cpu(), which implies me being quite confused...

> But to your point, this does appear to be
> a rather low-probability race condition, once per some tens of hours
> of SRCU-P.
>
> Is there a more focused check for the race condition above?
>

Not that I'm aware of. I'm thinking that if the pcpu kworker were an RT
task, then this would guarantee it would get picked in favor of the cpuhp
thread upon switching out of the stopper, but that still requires the
kworker running on some CPU (for some reason) during rebind_workers().



>                                                       Thanx, Paul