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

[Ingo Molnar]

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