On Tue, Nov 2, 2021 at 9:18 AM Steven Rostedt [off-list ref] wrote:

On Tue, 2 Nov 2021 09:09:50 +0800
Yafang Shao [off-list ref] wrote:

quoted

So if no one against, I will do it in two steps,

1. Send the task comm cleanups in a separate patchset named "task comm cleanups"
    This patchset includes patch #1, #2, #4,  #5, #6, #7 and #9.
    Cleaning them up can make it less error prone, and it will be
helpful if we want to extend task comm in the future :)

Agreed.

quoted

2.  Keep the current comm[16] as-is and introduce a separate pointer
to store kthread's long name

I'm OK with this. Hopefully more would chime in too.

quoted

     Now we only care about kthread, so we can put the pointer into a
kthread specific struct.
     For example in the struct kthread, or in kthread->data (which may
conflict with workqueue).

No, add a new field to the structure. "full_name" or something like that.
I'm guessing it should be NULL if the name fits in TASK_COMM_LEN and
allocated if the name had to be truncated.

Do not overload data with this. That will just make things confusing.
There's not that many kthreads, where an addition of an 8 byte pointer is
going to cause issues.

Sure, I will add a new field named "full_name", which only be
allocated if the kthread's comm is truncated.

quoted

     And then dynamically allocate a longer name if it is truncated,
for example,
     __kthread_create_on_node
         len = vsnprintf(name, sizeof(name), namefmt, args);
         if (len >= TASK_COMM_LEN) {
             /* create a longer name */

And make sure you have it fail the kthread allocation if it fails to
allocate.

quoted

         }

     And then we modify proc_task_name(), so the user can get
kthread's longer name via /proc/[pid]/comm.

Agreed.

quoted

     And then free the allocated memory when the kthread is destroyed.

Correct.

Thanks,

-- Steve

-- 
Thanks
Yafang