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
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/