From: "Michael S. Tsirkin" <mst@redhat.com> To: Arnd Bergmann <arnd@arndb.de> Cc: linux-kernel@vger.kernel.org, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will.deacon@arm.com>, David Howells <dhowells@redhat.com>, Hirokazu Takata <takata@linux-m32r.org>, Michal Simek <monstr@monstr.eu>, Koichi Yasutake <yasutake.koichi@jp.panasonic.com>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Paul Mackerras <paulus@samba.org>, Chris Metcalf <cmetcalf@tilera.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Peter Zijlstra <peterz@infradead.org>, "H. Peter Anvin" <hpa@zytor.com>, x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-m32r@ml.linux-m32r.org, linux-m32r-ja@ml.linux-m32r.org, microblaze-uclinux@itee.uq.edu.au, linux-am33-list@redhat.com, linuxppc-dev@lists.ozlabs.org, linux-arch@vger.kernel.org, linux-mm@kvack.o Subject: Re: [PATCH v2 00/10] uaccess: better might_sleep/might_fault behavior Date: Wed, 22 May 2013 12:58:18 +0300 [thread overview] Message-ID: <20130522095818.GB24931@redhat.com> (raw) In-Reply-To: <201305221125.36284.arnd@arndb.de> On Wed, May 22, 2013 at 11:25:36AM +0200, Arnd Bergmann wrote: > On Thursday 16 May 2013, Michael S. Tsirkin wrote: > > This improves the might_fault annotations used > > by uaccess routines: > > > > 1. The only reason uaccess routines might sleep > > is if they fault. Make this explicit for > > all architectures. > > 2. Accesses (e.g through socket ops) to kernel memory > > with KERNEL_DS like net/sunrpc does will never sleep. > > Remove an unconditinal might_sleep in the inline > > might_fault in kernel.h > > (used when PROVE_LOCKING is not set). > > 3. Accesses with pagefault_disable return EFAULT > > but won't cause caller to sleep. > > Check for that and avoid might_sleep when > > PROVE_LOCKING is set. > > > > I'd like these changes to go in for the benefit of > > the vhost driver where we want to call socket ops > > under a spinlock, and fall back on slower thread handler > > on error. > > Hi Michael, > > I have recently stumbled over a related topic, which is the highly > inconsistent placement of might_fault() or might_sleep() in certain > classes of uaccess functions. Your patches seem completely reasonable, > but it would be good to also fix the other problem, at least on > the architectures we most care about. > > Given the most commonly used functions and a couple of architectures > I'm familiar with, these are the ones that currently call might_fault() > > x86-32 x86-64 arm arm64 powerpc s390 generic > copy_to_user - x - - - x x > copy_from_user - x - - - x x > put_user x x x x x x x > get_user x x x x x x x > __copy_to_user x x - - x - - > __copy_from_user x x - - x - - > __put_user - - x - x - - > __get_user - - x - x - - > > WTF? Yea. > Calling might_fault() for every __get_user/__put_user is rather expensive > because it turns what should be a single instruction (plus fixup) into an > external function call. You mean _cond_resched with CONFIG_PREEMPT_VOLUNTARY? Or do you mean when we build with PROVE_LOCKING? > My feeling is that we should do might_fault() only in access_ok() to get > the right balance. > > Arnd Well access_ok is currently non-blocking I think - we'd have to audit all callers. There are some 200 of these in drivers and some 1000 total so ... a bit risky. -- MST -- 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/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com> To: Arnd Bergmann <arnd@arndb.de> Cc: linux-kernel@vger.kernel.org, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will.deacon@arm.com>, David Howells <dhowells@redhat.com>, Hirokazu Takata <takata@linux-m32r.org>, Michal Simek <monstr@monstr.eu>, Koichi Yasutake <yasutake.koichi@jp.panasonic.com>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Paul Mackerras <paulus@samba.org>, Chris Metcalf <cmetcalf@tilera.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Peter Zijlstra <peterz@infradead.org>, "H. Peter Anvin" <hpa@zytor.com>, x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-m32r@ml.linux-m32r.org, linux-m32r-ja@ml.linux-m32r.org, microblaze-uclinux@itee.uq.edu.au, linux-am33-list@redhat.com, linuxppc-dev@lists.ozlabs.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, kvm@vger.kernel.org Subject: Re: [PATCH v2 00/10] uaccess: better might_sleep/might_fault behavior Date: Wed, 22 May 2013 12:58:18 +0300 [thread overview] Message-ID: <20130522095818.GB24931@redhat.com> (raw) Message-ID: <20130522095818.HSVZ3bfZSlL2t5J9So1Y_RiDSrQf2T86bj5n6Hp0WFA@z> (raw) In-Reply-To: <201305221125.36284.arnd@arndb.de> On Wed, May 22, 2013 at 11:25:36AM +0200, Arnd Bergmann wrote: > On Thursday 16 May 2013, Michael S. Tsirkin wrote: > > This improves the might_fault annotations used > > by uaccess routines: > > > > 1. The only reason uaccess routines might sleep > > is if they fault. Make this explicit for > > all architectures. > > 2. Accesses (e.g through socket ops) to kernel memory > > with KERNEL_DS like net/sunrpc does will never sleep. > > Remove an unconditinal might_sleep in the inline > > might_fault in kernel.h > > (used when PROVE_LOCKING is not set). > > 3. Accesses with pagefault_disable return EFAULT > > but won't cause caller to sleep. > > Check for that and avoid might_sleep when > > PROVE_LOCKING is set. > > > > I'd like these changes to go in for the benefit of > > the vhost driver where we want to call socket ops > > under a spinlock, and fall back on slower thread handler > > on error. > > Hi Michael, > > I have recently stumbled over a related topic, which is the highly > inconsistent placement of might_fault() or might_sleep() in certain > classes of uaccess functions. Your patches seem completely reasonable, > but it would be good to also fix the other problem, at least on > the architectures we most care about. > > Given the most commonly used functions and a couple of architectures > I'm familiar with, these are the ones that currently call might_fault() > > x86-32 x86-64 arm arm64 powerpc s390 generic > copy_to_user - x - - - x x > copy_from_user - x - - - x x > put_user x x x x x x x > get_user x x x x x x x > __copy_to_user x x - - x - - > __copy_from_user x x - - x - - > __put_user - - x - x - - > __get_user - - x - x - - > > WTF? Yea. > Calling might_fault() for every __get_user/__put_user is rather expensive > because it turns what should be a single instruction (plus fixup) into an > external function call. You mean _cond_resched with CONFIG_PREEMPT_VOLUNTARY? Or do you mean when we build with PROVE_LOCKING? > My feeling is that we should do might_fault() only in access_ok() to get > the right balance. > > Arnd Well access_ok is currently non-blocking I think - we'd have to audit all callers. There are some 200 of these in drivers and some 1000 total so ... a bit risky. -- MST
next prev parent reply other threads:[~2013-05-22 9:58 UTC|newest] Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-05-16 11:07 [PATCH v2 00/10] uaccess: better might_sleep/might_fault behavior Michael S. Tsirkin 2013-05-16 11:07 ` Michael S. Tsirkin 2013-05-16 11:10 ` [PATCH v2 01/10] asm-generic: uaccess s/might_sleep/might_fault/ Michael S. Tsirkin 2013-05-16 11:10 ` Michael S. Tsirkin 2013-05-16 11:10 ` [PATCH v2 02/10] arm64: " Michael S. Tsirkin 2013-05-16 11:10 ` Michael S. Tsirkin 2013-05-16 13:29 ` Catalin Marinas 2013-05-16 13:29 ` Catalin Marinas 2013-05-16 11:10 ` [PATCH v2 03/10] frv: " Michael S. Tsirkin 2013-05-16 11:10 ` Michael S. Tsirkin 2013-05-16 11:11 ` [PATCH v2 04/10] m32r: " Michael S. Tsirkin 2013-05-16 11:11 ` Michael S. Tsirkin 2013-05-16 11:11 ` [PATCH v2 05/10] microblaze: " Michael S. Tsirkin 2013-05-16 11:11 ` Michael S. Tsirkin 2013-05-16 11:12 ` [PATCH v2 06/10] mn10300: " Michael S. Tsirkin 2013-05-16 11:12 ` Michael S. Tsirkin 2013-05-16 11:15 ` [PATCH v2 07/10] powerpc: " Michael S. Tsirkin 2013-05-16 11:15 ` Michael S. Tsirkin 2013-05-22 13:59 ` Arnd Bergmann 2013-05-22 13:59 ` Arnd Bergmann 2013-05-22 14:30 ` Michael S. Tsirkin 2013-05-22 14:30 ` Michael S. Tsirkin 2013-05-24 13:00 ` Michael S. Tsirkin 2013-05-24 13:00 ` Michael S. Tsirkin 2013-05-24 13:11 ` Michael S. Tsirkin 2013-05-24 13:11 ` Michael S. Tsirkin 2013-05-24 13:30 ` Arnd Bergmann 2013-05-24 13:30 ` Arnd Bergmann 2013-05-16 11:15 ` [PATCH v2 08/10] tile: " Michael S. Tsirkin 2013-05-16 11:15 ` Michael S. Tsirkin 2013-05-16 13:33 ` Chris Metcalf 2013-05-16 13:33 ` Chris Metcalf 2013-05-16 11:15 ` [PATCH v2 09/10] x86: " Michael S. Tsirkin 2013-05-16 11:15 ` Michael S. Tsirkin 2013-05-16 11:16 ` [PATCH v2 10/10] kernel: might_fault does not imply might_sleep Michael S. Tsirkin 2013-05-16 11:16 ` Michael S. Tsirkin 2013-05-16 18:40 ` Peter Zijlstra 2013-05-16 18:40 ` Peter Zijlstra 2013-05-19 9:35 ` Michael S. Tsirkin 2013-05-19 9:35 ` Michael S. Tsirkin 2013-05-19 12:34 ` Steven Rostedt 2013-05-19 12:34 ` Steven Rostedt 2013-05-19 13:34 ` Michael S. Tsirkin 2013-05-19 13:34 ` Michael S. Tsirkin 2013-05-19 16:06 ` Steven Rostedt 2013-05-19 16:06 ` Steven Rostedt 2013-05-19 16:40 ` Michael S. Tsirkin 2013-05-19 16:40 ` Michael S. Tsirkin 2013-05-19 20:23 ` Steven Rostedt 2013-05-19 20:23 ` Steven Rostedt 2013-05-19 20:35 ` Michael S. Tsirkin 2013-05-19 20:35 ` Michael S. Tsirkin 2013-05-21 11:18 ` Peter Zijlstra 2013-05-21 11:18 ` Peter Zijlstra 2013-05-21 11:21 ` Peter Zijlstra 2013-05-21 11:21 ` Peter Zijlstra 2013-05-21 11:57 ` Peter Zijlstra 2013-05-21 11:57 ` Peter Zijlstra 2013-05-21 13:28 ` Michael S. Tsirkin 2013-05-22 9:47 ` Michael S. Tsirkin 2013-05-22 9:47 ` Michael S. Tsirkin 2013-05-22 10:16 ` Peter Zijlstra 2013-05-22 10:16 ` Peter Zijlstra 2013-05-22 20:38 ` Michael S. Tsirkin 2013-05-22 20:38 ` Michael S. Tsirkin 2013-05-22 20:36 ` Michael S. Tsirkin 2013-05-22 20:36 ` Michael S. Tsirkin 2013-05-22 9:25 ` [PATCH v2 00/10] uaccess: better might_sleep/might_fault behavior Arnd Bergmann 2013-05-22 9:25 ` Arnd Bergmann 2013-05-22 9:58 ` Michael S. Tsirkin [this message] 2013-05-22 9:58 ` Michael S. Tsirkin 2013-05-22 10:19 ` Peter Zijlstra 2013-05-22 10:19 ` Peter Zijlstra 2013-05-22 11:07 ` Michael S. Tsirkin 2013-05-22 11:07 ` Michael S. Tsirkin 2013-05-22 11:27 ` Peter Zijlstra 2013-05-22 11:27 ` Peter Zijlstra 2013-05-22 13:41 ` Russell King - ARM Linux 2013-05-22 13:41 ` Russell King - ARM Linux 2013-05-22 14:04 ` Arnd Bergmann 2013-05-22 14:44 ` Michael S. Tsirkin 2013-05-22 14:44 ` Michael S. Tsirkin 2013-05-24 14:17 ` [PATCH v3 01/11] asm-generic: uaccess s/might_sleep/might_fault/ Michael S. Tsirkin
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=20130522095818.GB24931@redhat.com \ --to=mst@redhat.com \ --cc=arnd@arndb.de \ --cc=benh@kernel.crashing.org \ --cc=catalin.marinas@arm.com \ --cc=cmetcalf@tilera.com \ --cc=dhowells@redhat.com \ --cc=hpa@zytor.com \ --cc=linux-am33-list@redhat.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-m32r-ja@ml.linux-m32r.org \ --cc=linux-m32r@ml.linux-m32r.org \ --cc=linux-mm@kvack.o \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=microblaze-uclinux@itee.uq.edu.au \ --cc=mingo@redhat.com \ --cc=monstr@monstr.eu \ --cc=paulus@samba.org \ --cc=peterz@infradead.org \ --cc=takata@linux-m32r.org \ --cc=tglx@linutronix.de \ --cc=will.deacon@arm.com \ --cc=x86@kernel.org \ --cc=yasutake.koichi@jp.panasonic.com \ /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: linkBe 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).