linux-kernel - Re: [Bug] premature worker thread wakeup

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: <xhsmhwmj67hni.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
Date: Fri, 20 Sep 2024 12:18:09 +0200
From: Valentin Schneider <vschneid@...hat.com>
To: "Yan, Zheng" <ukernel@...il.com>, Linux Kernel Mailing List
 <linux-kernel@...r.kernel.org>
Cc: Peter Zijlstra <peterz@...radead.org>
Subject: Re: [Bug] premature worker thread wakeup

On 20/09/24 15:25, Yan, Zheng wrote:
>
> Looks like the newly created kthread got woke up prematurely. Checking
> the source code, path "workqueue: Unbind kworkers before sending them
> to exit()" looks suspicious. The patch wakes up dying worker's task up
> without holding pool->lock.  Is it possible that another worker thread
> recently died, the newly create worker thread reused the dead thread's
> task_struct and wrongly  got woke up.
>

Per the comment in idle_cull_fn():

         * Grabbing wq_pool_attach_mutex here ensures an already-running worker
         * cannot proceed beyong set_pf_worker() in its self-destruct path.
         * This is required as a previously-preempted worker could run after
         * set_worker_dying() has happened but before detach_dying_workers() did.

the task shouldn't be able to exit() even if we don't hold &pool->lock.

Also, things have changed a little in this area, for instance see
  f4b7b53c94af ("workqueue: Detach workers directly in idle_cull_fn()")
Could you try to reproduce this using a more recent upstream kernel?


> Regards
> Yan, Zheng