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 > > 2. A fix > > Below patch: > > [procfs: signal /proc/PID/comm write > > truncation](https://rere.qmqm.pl/git/?p=linux;a=commit;h=d72027388d4d95db5438a7a574e0a03ae4b5d6d7) > > > > It seems this patch is incomplete ? I don't know what it means to do. > > Currently writes to /proc/PID/comm are silently truncated. This patch > makes the write() call return the actual number of bytes actually written > and on subsequent calls return -ENOSPC. glibc checks the length in > pthread_setname_np() before write(), so the change is not currently > relevant for it. I don't know/remember what other runtimes do, though. > > > 3. A feature provided for pthread_getname_np > > Below patch: > > [procfs: lseek(/proc/PID/comm, 0, > > SEEK_END)](https://rere.qmqm.pl/git/?p=linux;a=commit;h=2c3814268caf2b1fee6d1a0b61fd1730ce135d4a) > > > > It seems this patch is useful. With this patch the userspace can > > directly get the TASK_COMM_LEN through the API. > > This one I'm not really fond of because it abuses lseek() in that it > doesn't move the write pointer. But in case of /proc files this normally > would return EINVAL anyway. > Another possible way is introducing a new PR_GET_COMM_LEN for prctl(2), but I'm not sure if it is worth it. -- Thanks Yafang
