[PATCH v7 2/4] include: Set tsk->comm length to 64 bytes

Bhupesh posted 4 patches 1 month, 3 weeks ago
There is a newer version of this series
[PATCH v7 2/4] include: Set tsk->comm length to 64 bytes
Posted by Bhupesh 1 month, 3 weeks ago
Historically due to the 16-byte length of TASK_COMM_LEN, the
users of 'tsk->comm' are restricted to use a fixed-size target
buffer also of TASK_COMM_LEN for 'memcpy()' like use-cases.

To fix the same, we now use a 64-byte TASK_COMM_EXT_LEN and
set the comm element inside 'task_struct' to the same length:
       struct task_struct {
	       .....
               char    comm[TASK_COMM_EXT_LEN];
	       .....
       };

       where TASK_COMM_EXT_LEN is 64-bytes.

Note, that the existing users have not been modified to migrate to
'TASK_COMM_EXT_LEN', in case they have hard-coded expectations of
dealing with only a 'TASK_COMM_LEN' long 'tsk->comm'.

Signed-off-by: Bhupesh <bhupesh@igalia.com>
---
 include/linux/sched.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 35f1ef06eb6c..87e9dfaf61ac 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -318,6 +318,7 @@ struct user_event_mm;
  */
 enum {
 	TASK_COMM_LEN = 16,
+	TASK_COMM_EXT_LEN = 64,
 };
 
 extern void sched_tick(void);
@@ -1162,7 +1163,7 @@ struct task_struct {
 	 *   - logic inside set_task_comm() will ensure it is always NUL-terminated and
 	 *     zero-padded
 	 */
-	char				comm[TASK_COMM_LEN];
+	char				comm[TASK_COMM_EXT_LEN];
 
 	struct nameidata		*nameidata;
 
@@ -1961,7 +1962,7 @@ extern void kick_process(struct task_struct *tsk);
 
 extern void __set_task_comm(struct task_struct *tsk, const char *from, bool exec);
 #define set_task_comm(tsk, from) ({			\
-	BUILD_BUG_ON(sizeof(from) != TASK_COMM_LEN);	\
+	BUILD_BUG_ON(sizeof(from) < TASK_COMM_LEN);	\
 	__set_task_comm(tsk, from, false);		\
 })
 
-- 
2.38.1
Re: [PATCH v7 2/4] include: Set tsk->comm length to 64 bytes
Posted by Andy Shevchenko 1 month, 3 weeks ago
On Mon, Aug 11, 2025 at 12:16:07PM +0530, Bhupesh wrote:
> Historically due to the 16-byte length of TASK_COMM_LEN, the
> users of 'tsk->comm' are restricted to use a fixed-size target
> buffer also of TASK_COMM_LEN for 'memcpy()' like use-cases.
> 
> To fix the same, we now use a 64-byte TASK_COMM_EXT_LEN and
> set the comm element inside 'task_struct' to the same length:
>        struct task_struct {
> 	       .....
>                char    comm[TASK_COMM_EXT_LEN];
> 	       .....
>        };
> 
>        where TASK_COMM_EXT_LEN is 64-bytes.
> 
> Note, that the existing users have not been modified to migrate to
> 'TASK_COMM_EXT_LEN', in case they have hard-coded expectations of
> dealing with only a 'TASK_COMM_LEN' long 'tsk->comm'.

...

> -	BUILD_BUG_ON(sizeof(from) != TASK_COMM_LEN);	\
> +	BUILD_BUG_ON(sizeof(from) < TASK_COMM_LEN);	\

Wondering if we may convert this to static_assert().
(rather in a separate patch)

-- 
With Best Regards,
Andy Shevchenko
Re: [PATCH v7 2/4] include: Set tsk->comm length to 64 bytes
Posted by Bhupesh Sharma 1 month, 3 weeks ago

On 8/11/25 8:40 PM, Andy Shevchenko wrote:
> On Mon, Aug 11, 2025 at 12:16:07PM +0530, Bhupesh wrote:
>> Historically due to the 16-byte length of TASK_COMM_LEN, the
>> users of 'tsk->comm' are restricted to use a fixed-size target
>> buffer also of TASK_COMM_LEN for 'memcpy()' like use-cases.
>>
>> To fix the same, we now use a 64-byte TASK_COMM_EXT_LEN and
>> set the comm element inside 'task_struct' to the same length:
>>         struct task_struct {
>> 	       .....
>>                 char    comm[TASK_COMM_EXT_LEN];
>> 	       .....
>>         };
>>
>>         where TASK_COMM_EXT_LEN is 64-bytes.
>>
>> Note, that the existing users have not been modified to migrate to
>> 'TASK_COMM_EXT_LEN', in case they have hard-coded expectations of
>> dealing with only a 'TASK_COMM_LEN' long 'tsk->comm'.
> ...
>
>> -	BUILD_BUG_ON(sizeof(from) != TASK_COMM_LEN);	\
>> +	BUILD_BUG_ON(sizeof(from) < TASK_COMM_LEN);	\
> Wondering if we may convert this to static_assert().
> (rather in a separate patch)

That's a fair suggestion. If others don't have an objection to the 
suggested change, I can club it in v8 along with any other requested 
changes.

Thanks.