linux-kernel - 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: <CALOAHbCgaJ83qZVj6qt8tgJBd4ojuLfgSp2Ce7CgzQYshM-amQ@mail.gmail.com>
Date:   Tue, 2 Nov 2021 09:26:35 +0800
From:   Yafang Shao <laoar.shao@...il.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Petr Mladek <pmladek@...e.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Arnaldo Carvalho de Melo <arnaldo.melo@...il.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 Tue, Nov 2, 2021 at 9:18 AM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Tue, 2 Nov 2021 09:09:50 +0800
> Yafang Shao <laoar.shao@...il.com> wrote:
>
> > So if no one against, I will do it in two steps,
> >
> > 1. Send the task comm cleanups in a separate patchset named "task comm cleanups"
> >     This patchset includes patch #1, #2, #4,  #5, #6, #7 and #9.
> >     Cleaning them up can make it less error prone, and it will be
> > helpful if we want to extend task comm in the future :)
>
> Agreed.
>
> >
> > 2.  Keep the current comm[16] as-is and introduce a separate pointer
> > to store kthread's long name
>
> I'm OK with this. Hopefully more would chime in too.
>
> >      Now we only care about kthread, so we can put the pointer into a
> > kthread specific struct.
> >      For example in the struct kthread, or in kthread->data (which may
> > conflict with workqueue).
>
> No, add a new field to the structure. "full_name" or something like that.
> I'm guessing it should be NULL if the name fits in TASK_COMM_LEN and
> allocated if the name had to be truncated.
>
> Do not overload data with this. That will just make things confusing.
> There's not that many kthreads, where an addition of an 8 byte pointer is
> going to cause issues.
>

Sure, I will add a new field named "full_name", which only be
allocated if the kthread's comm is truncated.

> >
> >      And then dynamically allocate a longer name if it is truncated,
> > for example,
> >      __kthread_create_on_node
> >          len = vsnprintf(name, sizeof(name), namefmt, args);
> >          if (len >= TASK_COMM_LEN) {
> >              /* create a longer name */
>
> And make sure you have it fail the kthread allocation if it fails to
> allocate.
>
> >          }
> >
> >      And then we modify proc_task_name(), so the user can get
> > kthread's longer name via /proc/[pid]/comm.
>
> Agreed.
>
> >
> >      And then free the allocated memory when the kthread is destroyed.
>
> Correct.
>
> Thanks,
>
> -- Steve



-- 
Thanks
Yafang