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 <mirq-linux@xxxxxxxxxxxx> wrote: > > > > On Fri, Nov 05, 2021 at 02:34:58PM +0800, Yafang Shao wrote: > > > On Thu, Nov 4, 2021 at 9:37 AM Michał Mirosław <mirq-linux@xxxxxxxxxxxx> wrote: > > > > > > > > On Mon, Nov 01, 2021 at 06:04:08AM +0000, Yafang Shao wrote: > > > > > 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
