* 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:
4614a696bd1c3a9af3a08f0e5874830a85b889d4
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 ...
Thanks,
Ingo
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>