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

[Ingo Molnar]

(Linus Cc:-ed)

* Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:

> On Wed, 18 May 2011 12:03:29 -0700
> John Stultz <john.stultz@xxxxxxxxxx> wrote:
> 
> > But, the net of this is that it seems everyone else is way more passionate 
> > about this issue then I am, so I'm starting to wonder if it would be better 
> > for someone who has more of a dog in the fight to be pushing these?
> 
> I like the %p thingy - it's neat and is an overall improvement.
> [...]
>
> Providing an unlocked accessor for super-special applications which know what 
> they're doing seems an adequate compromise.

Dunno, %ptc ties into lowlevel sprintf() and takes a spinlock! We are 
unrobustizing an important lowlevel function that until today could always be 
used lockless for debugging, in any context, under any circumstance.

We do that just to solve something that occurs rather rarely and has no 
functional effect just some temporarily confusing looking string descriptor 
output.

The *last* place i'd put this into is vsprintf(), really. Make the procfs 
output methods atomic against ->comm update, sure. But put a lock like that 
into kernel debug output? No way!

(Btw, i find %ptc OK if it comes with no lock. %pt would be nicer as a name?)

I'm uneasy about it if i think how many hairy places handle task->comm[].

Anyway, vsprintf() is Linus code, so i can take the easy road, chicken out and 
punt this to Linus - instead of risking a needle from Andrew! :)

If Linus likes this approach we should do it with a lock.

> [...]  If it dies I shall stick another pin in my Ingo doll.

Oh, out of morbid curiosity, mind providing a log of bigger past incidents 
where you had to stick pins into a doll of me? (In private mail, if the list is 
too long ;-)

(Does every lockdep report that catches a real bug unpull a needle? ;-)

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/