netdev - Re: [PATCH v7 00/11] extend task comm from 16 to 24

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YYXEzlHn28/d5C6A@qmqm.qmqm.pl>
Date:   Sat, 6 Nov 2021 00:57:06 +0100
From:   Michał Mirosław <mirq-linux@...e.qmqm.pl>
To:     Yafang Shao <laoar.shao@...il.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>,
        Petr Mladek <pmladek@...e.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Valentin Schneider <valentin.schneider@....com>,
        Qiang Zhang <qiang.zhang@...driver.com>,
        robdclark <robdclark@...omium.org>,
        christian <christian@...uner.io>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Ingo Molnar <mingo@...hat.com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>, Martin Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        john fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>,
        dennis.dalessandro@...nelisnetworks.com,
        mike.marciniszyn@...nelisnetworks.com, dledford@...hat.com,
        jgg@...pe.ca, linux-rdma@...r.kernel.org,
        netdev <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        "linux-perf-use." <linux-perf-users@...r.kernel.org>,
        linux-fsdevel@...r.kernel.org, Linux MM <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel test robot <oliver.sang@...el.com>,
        kbuild test robot <lkp@...el.com>
Subject: Re: [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@...e.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