linux-kernel - Re: [PATCH 0/5] kthread: increase the size of kthread's comm

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] [day] [month] [year] [list]

Message-ID: <CALOAHbDhwJsYO+a7dyTn-HxrpVNnaLi_xrJ7gk-mBwjPNV4YMw@mail.gmail.com>
Date:   Sun, 3 Oct 2021 22:20:46 +0800
From:   Yafang Shao <laoar.shao@...il.com>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Petr Mladek <pmladek@...e.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Valentin Schneider <valentin.schneider@....com>,
        Kees Cook <keescook@...omium.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        qiang.zhang@...driver.com, robdclark@...omium.org,
        christian@...uner.io, Dietmar Eggemann <dietmar.eggemann@....com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/5] kthread: increase the size of kthread's comm

On Sun, Oct 3, 2021 at 11:41 AM Al Viro <viro@...iv.linux.org.uk> wrote:
>
> On Wed, Sep 29, 2021 at 11:50:31AM +0000, Yafang Shao wrote:
>
> > That motivates me to do this improvement.
> >
> > This patch increases the size of ktread's comm from 16 to 24, which is
> > the same with workqueue's. After this change, the name of kthread can be
> > fully displayed in /proc/[pid]/comm, for example,
> >
> >     rcu_tasks_kthread
> >     rcu_tasks_rude_kthread
> >     rcu_tasks_trace_kthread
> >     ecryptfs-kthread
> >     vfio-irqfd-cleanup
> >     ext4-rsv-conversion
> >     jbd2/nvme0n1p2-8
> >     ...
> >
> > Because there're only a few of kthreads, so it won't increase too much
> > memory consumption.
>
> That's a bloody massive overkill.  If you care about /proc/*/comm, you
> might want to take a look at the function that generates its contents:
>
> void proc_task_name(struct seq_file *m, struct task_struct *p, bool escape)
> {
>         char tcomm[64];
>
>         if (p->flags & PF_WQ_WORKER)
>                 wq_worker_comm(tcomm, sizeof(tcomm), p);
>         else
>                 __get_task_comm(tcomm, sizeof(tcomm), p);
>
>         if (escape)
>                 seq_escape_str(m, tcomm, ESCAPE_SPACE | ESCAPE_SPECIAL, "\n\\");
>         else
>                 seq_printf(m, "%.64s", tcomm);
> }
>
> Hint: it's not always p->comm verbatim...

Right, I found it.  That's why I was wondering  storing the kthread's
comm in kthread_data.[1]
But after Petr's suggestion, I find increasing the size of comm to 24
for COFNIG_BASE_FULL and keeping it as 16 for COFNIG_BASE_SMALL is a
better solution.

[1]. https://lore.kernel.org/lkml/CALOAHbD3HUqUnjMYKX7NGwVWiS4K7OvS6uPNWucnOA5Cy3pn9w@mail.gmail.com/#t

-- 
Thanks
Yafang