Re: [PATCH 0/4] v6 Improve task->comm locking situation

From: Ingo Molnar
Date: Wed May 18 2011 - 02:26:26 EST

* John Stultz <john.stultz@xxxxxxxxxx> wrote:

> v6 tries to address the latest round of issues. Again, hopefully this is
> getting close to something that can be queued for 2.6.40.

We are far away from thinking about upstreaming any of this ...

> Since my commit 4614a696bd1c3a9af3a08f0e5874830a85b889d4, the current->comm
> value could be changed by other threads.
> This changed the comm locking rules, which previously allowed for unlocked
> current->comm access, since only the thread itself could change its comm.
> While this was brought up at the time, it was not considered problematic, as
> the comm writing was done in such a way that only null or incomplete comms
> could be read. However, recently folks have made it clear they want to see
> this issue resolved.

The commit is from 2.5 years ago:

Author: john stultz <johnstul@xxxxxxxxxx>
Date: Mon Dec 14 18:00:05 2009 -0800

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

So we are *way* beyond the time frame where this could be declared urgent.

So is there any actual motivation beyond:

" Hey, this looks a bit racy and 'top' very rarely, on rare workloads that
play with ->comm[], might display a weird reading task name for a second,
amongst the many other temporarily nonsensical statistical things it
already prints every now and then. "


> So fair enough, as I opened this can of worms, I should work
> to resolve it and this patchset is my initial attempt.

This patch set does not address the many places that deal with ->comm so it
does not even approximate the true scope of the change!

I.e. you are doing *another* change without fully seeing/showing the
consequences ...


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at