From: Ingo Molnar <mingo@elte.hu>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: John Stultz <john.stultz@linaro.org>,
LKML <linux-kernel@vger.kernel.org>,
Joe Perches <joe@perches.com>,
Michal Nazarewicz <mina86@mina86.com>,
Andy Whitcroft <apw@canonical.com>,
Jiri Slaby <jirislaby@gmail.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
David Rientjes <rientjes@google.com>,
Dave Hansen <dave@linux.vnet.ibm.com>,
linux-mm@kvack.org, Thomas Gleixner <tglx@linutronix.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [PATCH 0/4] v6 Improve task->comm locking situation
Date: Wed, 18 May 2011 21:48:11 +0200 [thread overview]
Message-ID: <20110518194811.GD6225@elte.hu> (raw)
In-Reply-To: <20110518123335.62785884.akpm@linux-foundation.org>
(Linus Cc:-ed)
* Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed, 18 May 2011 12:03:29 -0700
> John Stultz <john.stultz@linaro.org> 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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. 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@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-05-18 19:48 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-18 1:41 [PATCH 0/4] v6 Improve task->comm locking situation John Stultz
2011-05-18 1:41 ` [PATCH 1/4] comm: Introduce comm_lock spinlock to protect task->comm access John Stultz
2011-05-18 2:01 ` KOSAKI Motohiro
2011-05-18 4:11 ` John Stultz
2011-05-18 5:06 ` KOSAKI Motohiro
2011-05-18 1:41 ` [PATCH 2/4] comm: Add lock-free task->comm accessor John Stultz
2011-05-18 1:41 ` [PATCH 3/4] printk: Add %ptc to safely print a task's comm John Stultz
2011-05-18 1:41 ` [PATCH 4/4] checkpatch.pl: Add check for task comm references John Stultz
2011-05-18 6:25 ` [PATCH 0/4] v6 Improve task->comm locking situation Ingo Molnar
2011-05-18 7:05 ` Andrew Morton
2011-05-18 7:58 ` Ingo Molnar
2011-05-18 19:03 ` John Stultz
2011-05-18 19:33 ` Andrew Morton
2011-05-18 19:48 ` Ingo Molnar [this message]
2011-05-18 19:56 ` Andrew Morton
2011-05-18 20:48 ` Ingo Molnar
2011-05-18 19:58 ` Linus Torvalds
2011-05-20 10:41 ` KOSAKI Motohiro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110518194811.GD6225@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=apw@canonical.com \
--cc=dave@linux.vnet.ibm.com \
--cc=jirislaby@gmail.com \
--cc=joe@perches.com \
--cc=john.stultz@linaro.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mina86@mina86.com \
--cc=rientjes@google.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).