[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250507110444.963779-2-bhupesh@igalia.com>
Date: Wed, 7 May 2025 16:34:42 +0530
From: Bhupesh <bhupesh@...lia.com>
To: akpm@...ux-foundation.org
Cc: bhupesh@...lia.com,
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,
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
Subject: [PATCH v3 1/3] exec: Remove obsolete comments
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>
---
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 f96ac1982893..cb219c6db179 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1159,10 +1159,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
Powered by blists - more mailing lists