linux-kernel - Re: [PATCH v5 3/3] treewide: Switch from tsk->comm to tsk->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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=whCDEuSH7w=zQBpGkustvis26O=_6cEdjwCanz=ig8=4g@mail.gmail.com>
Date: Thu, 17 Jul 2025 11:35:45 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Bhupesh Sharma <bhsharma@...lia.com>, Bhupesh <bhupesh@...lia.com>, akpm@...ux-foundation.org, 
	kernel-dev@...lia.com, linux-kernel@...r.kernel.org, bpf@...r.kernel.org, 
	linux-perf-users@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	linux-mm@...ck.org, oliver.sang@...el.com, lkp@...el.com, 
	laoar.shao@...il.com, pmladek@...e.com, rostedt@...dmis.org, 
	mathieu.desnoyers@...icios.com, arnaldo.melo@...il.com, 
	alexei.starovoitov@...il.com, mirq-linux@...e.qmqm.pl, peterz@...radead.org, 
	willy@...radead.org, david@...hat.com, viro@...iv.linux.org.uk, 
	keescook@...omium.org, ebiederm@...ssion.com, brauner@...nel.org, 
	jack@...e.cz, mingo@...hat.com, juri.lelli@...hat.com, bsegall@...gle.com, 
	mgorman@...e.de, vschneid@...hat.com, linux-trace-kernel@...r.kernel.org, 
	kees@...nel.org
Subject: Re: [PATCH v5 3/3] treewide: Switch from tsk->comm to tsk->comm_str
 which is 64 bytes long

On Wed, 16 Jul 2025 at 13:47, Andrii Nakryiko <andrii.nakryiko@...il.com> wrote:
>
> But given how frequently task->comm is referenced (pretty much any
> profiler or tracer will capture this), it's just the widespread nature
> of accessing task->comm in BPF programs/scripts that will cause a lot
> of adaptation churn. And given the reason for renaming was to catch
> missing cases during refactoring, my ask was to do this renaming
> locally, validate all kernel code was modified, and then switch the
> field name back to "comm" (which you already did, so the remaining
> part would be just to rename comm_str back to comm).

Yes. Please.

Renaming the field is a great way to have the compiler scream loudly
of any missed cases, but keep it local (without committing it), and
rename it back after checking everything.

Then just talk about how every case has been checked in the commit message.

             Linus