Re: [PATCH v2 2/6] treewide: Get rid of get_task_comm()

[David Laight]

On Sun, 24 May 2026 19:38:52 -0300
André Almeida <andrealmeid@xxxxxxxxxx> wrote:

> Since commit 4cc0473d7754 ("get rid of __get_task_comm()"),
> get_task_comm() does just a redundant check for the buffer size and call
> strscpy_pad(). Replace get_task_comm() calls with strscpy_pad(), that will
> do the right thing if the buffers sizes doesn't match: zero-pad if it's
> bigger, and truncate if it's smaller.
> 
> Link: https://lore.kernel.org/lkml/CAHk-=wi5c=_-FBGo_88CowJd_F-Gi6Ud9d=TALm65ReN7YjrMw@xxxxxxxxxxxxxx/
> Co-developed-by: Bhupesh <bhupesh@xxxxxxxxxx>
> Signed-off-by: Bhupesh <bhupesh@xxxxxxxxxx>
> Signed-off-by: André Almeida <andrealmeid@xxxxxxxxxx>
> ---
... 
> -/*
> - * - Why not use task_lock()?
> - *   User space can randomly change their names anyway, so locking for readers
> - *   doesn't make sense. For writers, locking is probably necessary, as a race
> - *   condition could lead to long-term mixed results.
> - *   The logic inside __set_task_comm() ensures that the task comm is
> - *   always NUL-terminated and zero-padded. Therefore the race condition between
> - *   reader and writer is not an issue.
> - *
> - * - BUILD_BUG_ON() can help prevent the buf from being truncated.
> - *   Since the callers don't perform any return value checks, this safeguard is
> - *   necessary.
> - */
> -#define get_task_comm(buf, tsk) ({			\
> -	BUILD_BUG_ON(sizeof(buf) < TASK_COMM_LEN);	\
> -	strscpy_pad(buf, (tsk)->comm);			\
> -	buf;						\
> -})
> -

I don't think it is worth the churn of removing this wrapper.
The calls can be optimised based on the knowledge that tsk->com
is always '\0' terminated and can be assumed to be padded.
(A read mid-update might give an unpadded result, but that doesn't
matter because it can only 'leak' part of an old name.

-- David