lkml.org 
[lkml]   [2021]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v7 00/11] extend task comm from 16 to 24
    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@rere.qmqm.pl> 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.

    > 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.

    Best Regards
    Michał Mirosław

    \
     
     \ /
      Last update: 2021-11-06 00:57    [W:2.360 / U:0.696 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site