Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761825AbZAGVkI (ORCPT ); Wed, 7 Jan 2009 16:40:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752092AbZAGVjx (ORCPT ); Wed, 7 Jan 2009 16:39:53 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:46346 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752075AbZAGVjv (ORCPT ); Wed, 7 Jan 2009 16:39:51 -0500 Date: Wed, 7 Jan 2009 13:39:10 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Matthew Wilcox cc: Steven Rostedt , Peter Zijlstra , paulmck@linux.vnet.ibm.com, Gregory Haskins , Ingo Molnar , Andi Kleen , Chris Mason , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel , linux-btrfs , Thomas Gleixner , Nick Piggin , Peter Morreale , Sven Dietrich Subject: Re: [PATCH -v5][RFC]: mutex: implement adaptive spinning In-Reply-To: Message-ID: References: <1231279660.11687.121.camel@twins> <1231281801.11687.125.camel@twins> <1231283778.11687.136.camel@twins> <1231329783.11687.287.camel@twins> <1231347442.11687.344.camel@twins> <20090107210923.GV2002@parisc-linux.org> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1992 Lines: 58 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 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/