linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: mst@redhat.com (Michael S. Tsirkin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 00/10] uaccess: better might_sleep/might_fault behavior
Date: Wed, 22 May 2013 14:07:29 +0300	[thread overview]
Message-ID: <20130522110729.GB5643@redhat.com> (raw)
In-Reply-To: <20130522101916.GM18810@twins.programming.kicks-ass.net>

On Wed, May 22, 2013 at 12:19:16PM +0200, Peter Zijlstra wrote:
> On Wed, May 22, 2013 at 11:25:36AM +0200, Arnd Bergmann wrote:
> > 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.
> 
> We could hide it all behind CONFIG_DEBUG_ATOMIC_SLEEP just like
> might_sleep() is. I'm not sure there's a point to might_fault() when
> might_sleep() is a NOP.

The patch that you posted gets pretty close.
E.g. I'm testing this now:
+#define might_fault() do { \
+       if (_might_fault()) \
+               __might_sleep(__FILE__, __LINE__, 0); \
+       might_resched(); \
+} while(0)

So if might_sleep is a NOP, __might_sleep and might_resched are NOPs
so compiler will optimize this all out.

However, in a related thread, you pointed out that might_sleep is not a NOP if
CONFIG_PREEMPT_VOLUNTARY is set, even without CONFIG_DEBUG_ATOMIC_SLEEP.

Do you think we should drop the preemption point in might_fault?
Only copy_XX_user?
Only __copy_XXX_user ?

-- 
MST

  reply	other threads:[~2013-05-22 11:07 UTC|newest]

Thread overview: 42+ 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:10 ` [PATCH v2 01/10] asm-generic: uaccess s/might_sleep/might_fault/ Michael S. Tsirkin
2013-05-16 11:10 ` [PATCH v2 02/10] arm64: " Michael S. Tsirkin
2013-05-16 13:29   ` Catalin Marinas
2013-05-16 11:10 ` [PATCH v2 03/10] frv: " Michael S. Tsirkin
2013-05-16 11:11 ` [PATCH v2 04/10] m32r: " Michael S. Tsirkin
2013-05-16 11:11 ` [PATCH v2 05/10] microblaze: " Michael S. Tsirkin
2013-05-16 11:12 ` [PATCH v2 06/10] mn10300: " Michael S. Tsirkin
2013-05-16 11:15 ` [PATCH v2 07/10] powerpc: " Michael S. Tsirkin
2013-05-22 13:59   ` Arnd Bergmann
2013-05-22 14:30     ` Michael S. Tsirkin
2013-05-24 13:00     ` Michael S. Tsirkin
2013-05-24 13:11       ` Michael S. Tsirkin
2013-05-24 13:30         ` Arnd Bergmann
2013-05-16 11:15 ` [PATCH v2 08/10] tile: " Michael S. Tsirkin
2013-05-16 13:33   ` Chris Metcalf
2013-05-16 11:15 ` [PATCH v2 09/10] x86: " 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 18:40   ` Peter Zijlstra
2013-05-19  9:35     ` Michael S. Tsirkin
2013-05-19 12:34       ` Steven Rostedt
2013-05-19 13:34         ` Michael S. Tsirkin
2013-05-19 16:06           ` Steven Rostedt
2013-05-19 16:40             ` Michael S. Tsirkin
2013-05-19 20:23               ` Steven Rostedt
2013-05-19 20:35                 ` Michael S. Tsirkin
2013-05-21 11:18               ` Peter Zijlstra
2013-05-21 11:21       ` Peter Zijlstra
2013-05-21 11:57       ` Peter Zijlstra
2013-05-22  9:47         ` Michael S. Tsirkin
2013-05-22 10:16           ` Peter Zijlstra
2013-05-22 20:38         ` 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:58   ` Michael S. Tsirkin
2013-05-22 10:19   ` Peter Zijlstra
2013-05-22 11:07     ` Michael S. Tsirkin [this message]
2013-05-22 11:27       ` Peter Zijlstra
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-24 14:17 ` [PATCH v3 02/11] arm64: 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=20130522110729.GB5643@redhat.com \
    --to=mst@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.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).