Re: [PATCH 1/3] comm: Introduce comm_lock spinlock to protecttask->comm access
From: Peter Zijlstra
Date: Tue May 17 2011 - 17:55:15 EST
On Tue, 2011-05-17 at 23:27 +0200, Ingo Molnar wrote:
> * John Stultz <john.stultz@xxxxxxxxxx> 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
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/