Re: [PATCH 1/3] comm: Introduce comm_lock spinlock to protecttask->comm access
From: John Stultz
Date: Tue May 17 2011 - 18:27:25 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.
I'll defer to KOSAKI Motohiro and David on this bit. :)
> 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
Could we use this where cmpxchg16b is available and fall back to locking
if not? Or does that put too much of a penalty on arches that don't have
Alternatively, we can have locked accessors that are safe in the
majority of slow-path warning printks, and provide unlocked accessors
for cases where the performance is critical and the code can properly
handle possibly incomplete comms.
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/