On Mon 2021-10-25 17:05:03, Steven Rostedt wrote:

On Mon, 25 Oct 2021 11:10:09 -0700
Alexei Starovoitov [off-list ref] wrote:

quoted

It looks like a churn that doesn't really address the problem.
If we were to allow long names then make it into a pointer and use 16 byte
as an optimized storage for short names. Any longer name would be a pointer.
In other words make it similar to dentry->d_iname.

That would be quite a bigger undertaking too, as it is assumed throughout
the kernel that the task->comm is TASK_COMM_LEN and is nul terminated. And
most locations that save the comm simply use a fixed size string of
TASK_COMM_LEN. Not saying its not feasible, but it would require a lot more
analysis of the impact by changing such a fundamental part of task struct
from a static to something requiring allocation.

I fully agree. The evolution of this patchset clearly shows how many
code paths depend on the existing behavior.

Unless you are suggesting that we truncate like normal the 16 byte names
(to a max of 15 characters), and add a way to hold the entire name for
those locations that understand it.

Yup. If the problem is only with kthreads, it might be possible to
store the pointer into "struct kthread" and update proc_task_name().
It would generalize the solution already used by workqueues.
I think that something like this was mentioned in the discussion
about v1.

Best Regards,
Petr