Changes since v3: ================ - v3 can be seen here: https://lore.kernel.org/lkml/20250507110444.963779-1-bhup...@igalia.com/ - As suggested by Petr and Steven, used 'comm_ext' name instead of 'real_comm'. Correspondingly the macro name is changed to 'TASK_COMM_EXT_LEN' for the 64-byte extended comm. - Rebased this patchset on linux-next/master, which contain the following patch from Steven now: 155fd6c3e2f0 ("tracing/sched: Use __string() instead of fixed lengths for task->comm") - Accordingly, v4 drops the changes done for 'trace/sched' events in v3, but retains the 'safe' memcpy' changes for other kernel trace users.
Changes since v2: ================ - v2 can be seen here: https://lore.kernel.org/lkml/20250331121820.455916-1-bhup...@igalia.com/ - As suggested by Yafang and Kees, picked Linus' suggested approach for this version (see: <https://lore.kernel.org/all/CAHk-=wjAmmHUg6vho1KjzQi2=psr30+cogfd4axrthr2gsi...@mail.gmail.com/>). - Dropped kthreads patch from this version. It would be sent out separately, if we have a consensus on this approach. Changes since v1: ================ - v1 can be seen here: https://lore.kernel.org/lkml/20250314052715.610377-1-bhup...@igalia.com/ - As suggested by Kees, added [PATCH 3/3] to have a consistent 'full_name' entry inside 'task_struct' which both tasks and kthreads can use. - Fixed the commit message to indicate that the existing ABI '/proc/$pid/task/$tid/comm' remains untouched and a parallel '/proc/$pid/task/$tid/full_name' ABI for new (interested) users. While working with user-space debugging tools which work especially on linux gaming platforms, I found that the task name is truncated due to the limitation of TASK_COMM_LEN. Now, during debug tracing, seeing truncated names is not very useful, especially on gaming platforms where the number of tasks running can be very high. This patchset does not touch 'TASK_COMM_LEN' at all, i.e. 'TASK_COMM_LEN' and the 16-byte design remains untouched. Via this patchset, as Linus suggested, we can add the following union inside 'task_struct': union { char comm[TASK_COMM_LEN]; char comm_ext[TASK_COMM_EXT_LEN]; }; and then modify '__set_task_comm()' to pass 'tsk->comm_ext' to the existing users. So, eventually: - users who want the existing 'TASK_COMM_LEN' behavior will get it (existing ABIs would continue to work), - users who just print out 'tsk->comm' as a string will get the longer new "extended comm", - users who do 'sizeof(->comm)' will continue to get the old value because of the union. After this change, gdb is able to show full name of the task, using a simple app which generates threads with long names [see 1]: # gdb ./threadnames -ex "run info thread" -ex "detach" -ex "quit" > log # cat log NameThatIsTooLongForComm[4662] [1]. https://github.com/lostgoat/tasknames Bhupesh (3): exec: Remove obsolete comments treewide: Switch memcpy() users of 'task->comm' to a more safer implementation exec: Add support for 64 byte 'tsk->comm_ext' fs/exec.c | 6 +++--- include/linux/coredump.h | 3 ++- include/linux/sched.h | 14 ++++++++------ include/trace/events/block.h | 5 +++++ include/trace/events/oom.h | 1 + include/trace/events/osnoise.h | 1 + include/trace/events/signal.h | 1 + include/trace/events/task.h | 2 ++ 8 files changed, 23 insertions(+), 10 deletions(-) -- 2.38.1
