linux-kernel - Re: [PATCH -v5][RFC]: mutex: implement adaptive spinning

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, 7 Jan 2009 13:39:10 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Matthew Wilcox <matthew@....cx>
cc:	Steven Rostedt <rostedt@...dmis.org>,
	Peter Zijlstra <peterz@...radead.org>,
	paulmck@...ux.vnet.ibm.com, Gregory Haskins <ghaskins@...ell.com>,
	Ingo Molnar <mingo@...e.hu>, Andi Kleen <andi@...stfloor.org>,
	Chris Mason <chris.mason@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-btrfs <linux-btrfs@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Nick Piggin <npiggin@...e.de>,
	Peter Morreale <pmorreale@...ell.com>,
	Sven Dietrich <SDietrich@...ell.com>
Subject: Re: [PATCH -v5][RFC]: mutex: implement adaptive spinning

On Wed, 7 Jan 2009, Linus Torvalds wrote:
> 
> We've needed that before (and yes, we've simply mis-used __get_user() on 
> x86 before rather than add it).

Ahh, yeah, we have a really broken form of this in probe_kernel_address(), 
but it's disgustingly slow. And it actually does a whole lot more, since 
it is designed for addresses that we can't trust.

The thing about "thread->cpu" is that we can actually _trust_ the address, 
so we know it's not a user address or anything like that. So we don't need 
the whole pagefault_disable/enable around it. At least the x86 page fault 
handler knows that it absolutely must not take the mm semaphore for these 
things, for example (because it would be an insta-deadlock for the vmalloc 
space and thus any mm fault handlers in filesystems that are modules).

So we would be better off without that, but we could certainly also 
improve probe_kernel_address() if we had a better model. IOW, we *could* 
do something like

	#define get_kernel_mode(val, addr) __get_user(val, addr)

on the simple platforms, and then in the generic <linux/uaccess.h> code we 
can just do

	#ifndef get_kernel_mode
	 #define get_kernel_mode(val, addr) ({  \
		long _err;			\
		mm_segment_t old_fs = get_fs(); \
		set_fs(KERNEL_DS);		\
		_err = __get_user(val, addr);	\
		set_fs(old_fs);			\
		_err; })
	#endif

and then probe_kernel_address becomes

	#define probe_kernel_address(addr, val) ({	\
		long _err;				\
		pagefault_disable();			\
		_err = get_kernel_mode(val, addr);	\
		pagefault_enable();			\
		_err; })

which leaves all architectures with the trivial option to just define 
their own 'get_kernel_mode()' thing that _often_ is exactly the same as
__get_user().

Hmm? Anybody want to test it? 

				Linus
--
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/