linux-kernel - Re: [RFC PATCH] workqueue: Fix rescuer task's name truncated

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 24 Apr 2024 23:12:24 +0800
From: Wenchao Hao <haowenchao22@...il.com>
To: Aaron Tomlin <atomlin@...mlin.com>, Wenchao Hao <haowenchao2@...wei.com>
Cc: Tejun Heo <tj@...nel.org>, Lai Jiangshan <jiangshanlai@...il.com>,
 linux-kernel@...r.kernel.org, neelx@...hat.com
Subject: Re: [RFC PATCH] workqueue: Fix rescuer task's name truncated

On 4/24/24 3:12 PM, Aaron Tomlin wrote:
> On Tue, Apr 23, 2024 at 12:55:22PM +0800, Wenchao Hao wrote:
>> Hi Tejun and all:
>>
>> I added another logic in wq_worker_comm() to append worker's desc when
>> worker is not attached to a work pool. I don't know why the origin
>> logic only append worker's desc when worker is attached to a work pool,
>> so I am not sure if it's safe to using worker here directly.
> 
> Hi Wenchao,
> 
> A worker description is always updated under the per-pool workqueue lock.
> You can indeed use the rescuer's own description to store its associated
> workqueue name - good idea. We know the caller of set_worker_desc() will
> never touch a rescuer. For this unique rescuer case, if I understand
> correctly, you can read a rescuer's description outside the per-pool
> workqueue lock; albeit, you need to prevent a race with destroy_workqueue()
> to avoid a use-after-free.
> 

Hi Aaron, thanks a lot for your reply.

I think destroy_workqueue() may not race with wq_worker_comm(),
wq_pool_attach_mutex is used to avoid race, below is my analysis.
(Welcome to point out if my understand is incorrect)

t1 which call destroy_workqueue()     rescuer->task

destroy_workqueue()
  kthread_stop(rescuer->task)
                                      rescuer_thread()
	                                if (should_stop) {
	                                  __set_current_state(TASK_RUNNING);
	                                  set_pf_worker(false);
                                            mutex_lock(&wq_pool_attach_mutex);
				            current->flags &= ~PF_WQ_WORKER;
				            mutex_unlock(&wq_pool_attach_mutex);
	                                  return 0;
	                                }

  kfree(rescuer)

wq_worker_comm() would acquire wq_pool_attach_mutex then check if task->flags
is set PF_WQ_WORKER.
If PF_WQ_WORKER is not set, wq_worker_comm() would not access this task's worker
any more;
If PF_WQ_WORKER is set, the wq_pool_attach_mutex is held durning access of task's
worker.

What confuse me mostly is why the origin logic only append worker's desc when
worker is attached to a work pool.

Thinks.

> 
> Kind regards,
>