linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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>

  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).