lkml.org 
[lkml]   [2012]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/2] treewide: fix memory corruptions when TASK_COMM_LEN != 16

On Wednesday 2012-02-01 02:23, Andrew Morton wrote:
>>
>> If there is a piece of kernel code that
>> assumes/requests that userspace use a 16-byte buffer (such as
>> cn_proc as mentioned), then it should use a file-level define or
>> something with a comment above it that this is a fixed user value.
>>
>> I would therefore say that changing TASK_COMM_LEN is possible without
>> breaking any userprogram.
>>
>> (In other words, TASK_COMM_LEN can just remain what it is, and
>> comm[TASK_COMM_LEN] in struct task_struct could be changed to
>> e.g. comm[32]. Using sizeof(x.comm) also seems more proof in general.)
>
>Well yes, we could increase the size and provide new and better APIs
>for accessing it, while teaching the old APIs to truncate. That might
>cause some problems for old-API-using userspace during the transition
>period, but I doubt if they would be large problems.

Did my patch not change the existing code sites using ->comm
to always copy at most min(userbufsize aka 16, sizeof(t->comm)) bytes,
thereby keeping the promise to userspace while at the same time
making TASK_COMM_LEN's value freely choosable?


\
 
 \ /
  Last update: 2012-02-01 02:37    [W:0.281 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site