(2011/05/18 6:54), Peter Zijlstra wrote:
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
desired.
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.
I'm not sure it's silly or not. But the fact is, comm override was introduced
following patch. Personally I'd like to mark it to "depend on EXPERT". but John
seems to dislike the idea.
commit 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
--
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>