linux-kernel - Re: [PATCH workqueue/for-6.10-fixes] workqueue: Refactor worker ID formatting and make wq_worker

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: Tue, 21 May 2024 11:05:58 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Yafang Shao <laoar.shao@...il.com>
Cc: Tejun Heo <tj@...nel.org>, Jan Engelhardt <jengelh@...i.de>, Craig Small <csmall@....com.au>, 
	linux-kernel@...r.kernel.org, Lai Jiangshan <jiangshanlai@...il.com>
Subject: Re: [PATCH workqueue/for-6.10-fixes] workqueue: Refactor worker ID
 formatting and make wq_worker_comm() use full ID string

On Mon, 20 May 2024 at 19:34, Yafang Shao <laoar.shao@...il.com> wrote:
>
> We discussed extending it to 24 characters several years ago [0], but
> some userspace tools might break.

Well, the fact that we already expose names longer than 16 bytes in
/proc means that at least *that* side of it could use an extended
comm[] array.

Yes, some other interfaces might want to still use a 16-byte limit as
the length for the buffers they use (tracing?) but I suspect we could
make the comm[] array easily bigger.

But what I suspect we should do *first* is to try to get rid of a lot
of the "current->comm" users. One of the most common uses is purely
for printing, and we could actually just add a new '%p' pointer for
printing the current name. That would allow our vsprintf() code to not
just use tsk->comm, but to use the full_name for threads etc.

So instead of

   printf("%s ..", tsk->comm..);

we could have something like

   printf("%pc ..", tsk);

to print the name of the task.

That would get rid of a lot of the bare ->comm[] uses, and then the
rest should probably use proper wrappers for copying the data (ie
using 'get_task_comm()' etc).

That would not only pick up the better names for printk and oopses, it
would also make future cleanups simpler (for example, I'd love to get
rid of the 'comm' name entirely, and replace it with 'exe_name[24]'
and have the compiler just notice when somebody is trying to access
'comm' directly).

            Linus