Re: [PATCH 0/4] v6 Improve task->comm locking situation
From: Ingo Molnar
Date: Wed May 18 2011 - 15:48:42 EST
(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/