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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 May 2011 21:48:11 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	John Stultz <john.stultz@...aro.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Joe Perches <joe@...ches.com>,
	Michal Nazarewicz <mina86@...a86.com>,
	Andy Whitcroft <apw@...onical.com>,
	Jiri Slaby <jirislaby@...il.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	David Rientjes <rientjes@...gle.com>,
	Dave Hansen <dave@...ux.vnet.ibm.com>, linux-mm@...ck.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH 0/4] v6 Improve task->comm locking situation

(Linus Cc:-ed)

* Andrew Morton <akpm@...ux-foundation.org> wrote:

> On Wed, 18 May 2011 12:03:29 -0700
> John Stultz <john.stultz@...aro.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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/