Re: [PATCH 1/3] comm: Introduce comm_lock spinlock to protect task->comm access

[KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>]

(2011/05/18 6:54), Peter Zijlstra wrote:
> On Tue, 2011-05-17 at 23:27 +0200, Ingo Molnar wrote:
>> * John Stultz<john.stultz@linaro.org>  wrote:
>>
>>> The implicit rules for current->comm access being safe without locking are no
>>> longer true. Accessing current->comm without holding the task lock may result
>>> in null or incomplete strings (however, access won't run off the end of the
>>> string).
>>
>> This is rather unfortunate - task->comm is used in a number of performance
>> critical codepaths such as tracing.
>>
>> Why does this matter so much? A NULL string is not a big deal.
>>
>> Note, since task->comm is 16 bytes there's the CMPXCHG16B instruction on x86
>> which could be used to update it atomically, should atomicity really be
>> desired.
>
> The changelog also fails to mention _WHY_ this is no longer true. Nor
> does it treat why making it true again isn't an option.
>
> Who is changing another task's comm? That's just silly.

I'm not sure it's silly or not. But the fact is, comm override was introduced
following patch. Personally I'd like to mark it to "depend on EXPERT". but John
seems to dislike the idea.



commit 4614a696bd1c3a9af3a08f0e5874830a85b889d4
Author: john stultz <johnstul@us.ibm.com>
Date:   Mon Dec 14 18:00:05 2009 -0800

     procfs: allow threads to rename siblings via /proc/pid/tasks/tid/comm