linux-kernel - Re: [PATCH v4 1/3] exec: Remove obsolete comments

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALOAHbA9P0af7oVg+QTfFfn5TAyV0+vu+jeNG3DVHcO-OEsVVg@mail.gmail.com>
Date: Thu, 22 May 2025 14:18:08 +0800
From: Yafang Shao <laoar.shao@...il.com>
To: Bhupesh <bhupesh@...lia.com>
Cc: 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, pmladek@...e.com, 
	rostedt@...dmis.org, mathieu.desnoyers@...icios.com, arnaldo.melo@...il.com, 
	alexei.starovoitov@...il.com, andrii.nakryiko@...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
Subject: Re: [PATCH v4 1/3] exec: Remove obsolete comments

On Wed, May 21, 2025 at 2:24 PM Bhupesh <bhupesh@...lia.com> wrote:
>
> Patch 3a3f61ce5e0b ("exec: Make sure task->comm is always NUL-terminated"),
> replaced 'strscpy_pad()' with 'memcpy()' implementations inside
> '__set_task_comm()'.
>
> However a few left-over comments are still there, which mention
> the usage of 'strscpy_pad()' inside '__set_task_comm()'.
>
> Remove those obsolete comments.
>
> While at it, also remove an obsolete comment regarding 'task_lock()'
> usage while handing 'task->comm'.
>
> Signed-off-by: Bhupesh <bhupesh@...lia.com>

Acked-by: Yafang Shao <laoar.shao@...il.com>

> ---
>  include/linux/sched.h | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 8c60a42f9d00..704222114dcc 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1162,10 +1162,8 @@ struct task_struct {
>          *
>          * - normally initialized begin_new_exec()
>          * - set it with set_task_comm()
> -        *   - strscpy_pad() to ensure it is always NUL-terminated and
> +        *   - logic inside set_task_comm() will ensure it is always NUL-terminated and
>          *     zero-padded
> -        *   - task_lock() to ensure the operation is atomic and the name is
> -        *     fully updated.
>          */
>         char                            comm[TASK_COMM_LEN];
>
> @@ -1997,7 +1995,7 @@ extern void __set_task_comm(struct task_struct *tsk, const char *from, bool exec
>   *   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 strscpy_pad() in __set_task_comm() can ensure that the task comm is
> + *   The logic inside __set_task_comm() should ensure that the task comm is
>   *   always NUL-terminated and zero-padded. Therefore the race condition between
>   *   reader and writer is not an issue.
>   *
> --
> 2.38.1
>


-- 
Regards
Yafang