On Sat, Nov 06, 2021 at 05:12:24PM +0800, Yafang Shao wrote:

On Sat, Nov 6, 2021 at 7:57 AM Michał Mirosław [off-list ref] wrote:

quoted

On Fri, Nov 05, 2021 at 02:34:58PM +0800, Yafang Shao wrote:

quoted

On Thu, Nov 4, 2021 at 9:37 AM Michał Mirosław [off-list ref] wrote:

quoted

On Mon, Nov 01, 2021 at 06:04:08AM +0000, Yafang Shao wrote:

quoted

There're many truncated kthreads in the kernel, which may make trouble
for the user, for example, the user can't get detailed device
information from the task comm.

This patchset tries to improve this problem fundamentally by extending
the task comm size from 16 to 24, which is a very simple way.

[...]

Hi,

I've tried something like this a few years back. My attempt got mostly
lost in the mailing lists, but I'm still carrying the patches in my
tree [1]. My target was userspace thread names, and it turned out more
involved than I had time for.

[1] https://rere.qmqm.pl/git/?p=linux;a=commit;h=2c3814268caf2b1fee6d1a0b61fd1730ce135d4a
    and its parents

Hi Michal,

Thanks for the information.

I have looked through your patches.  It seems to contain six patches
now and can be divided into three parts per my understanding.

1. extend task comm len
This parts contains below 4 patches:
[prctl: prepare for bigger
TASK_COMM_LEN](https://rere.qmqm.pl/git/?p=linux;a=commit;h=cfd99db9cf911bb4d106889aeba1dfe89b6527d0)
[bluetooth: prepare for bigger
TASK_COMM_LEN](https://rere.qmqm.pl/git/?p=linux;a=commit;h=ba2805f5196865b81cc6fc938ea53af2c7c2c892)
[taskstats: prepare for bigger
TASK_COMM_LEN](https://rere.qmqm.pl/git/?p=linux;a=commit;h=4d29bfedc57b36607915a0171f4864ec504908ca)
[mm: make TASK_COMM_LEN
configurable](https://rere.qmqm.pl/git/?p=linux;a=commit;h=362acc35582445174589184c738c4d86ec7d174b)

What kind of userspace issues makes you extend the task comm length ?
Why not just use /proc/[pid]/cmdline ?

This was to enable longer thread names (as set by pthread_setname_np()).
Currently its 16 bytes, and that's too short for e.g. Chrome's or Firefox'es
threads. I believe that FreeBSD has 32-byte limit and so I expect that
major portable code is already prepared for bigger thread names.

The comm len in FreeBSD is (19 + 1) bytes[1], but that is still larger
than Linux :)
The task comm is short for many applications, that is why cmdline is
introduced per my understanding, but pthread_{set, get}name_np() is
reading/writing the comm or via prctl(2) rather than reading/writing
the cmdline...

Is the truncated Chrome or Firefox thread comm really harmful or is
extending the task comm just for portable?
Could you pls show me some examples if the short comm is really harmful?

Per my understanding, if the short comm is harmful to applications
then it is worth extending it.
But if it is only for portable code, it may not be worth extending it.

[1]. https://github.com/freebsd/freebsd-src/blob/main/sys/sys/param.h#L126

I don't think it is harmful as in exposing a bug or something. It's just
inconvenient when debugging a system where you can't differentiate
between threads because their names have been cut too short.

Best Regards
Michał Mirosław