From: Peter Zijlstra <peterz@infradead.org>
To: David Hildenbrand <dahi@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
tglx@linutronix.de, benh@kernel.crashing.org, paulus@samba.org,
akpm@linux-foundation.org, heiko.carstens@de.ibm.com,
schwidefsky@de.ibm.com, borntraeger@de.ibm.com, mst@redhat.com,
David.Laight@ACULAB.COM, hughd@google.com, hocko@suse.cz
Subject: Re: [PATCH v2 0/5] Reenable might_sleep() checks for might_fault()
Date: Fri, 27 Mar 2015 17:15:36 +0100 [thread overview]
Message-ID: <20150327161536.GH23123@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20150327164050.04693bff@thinkpad-w530>
On Fri, Mar 27, 2015 at 04:40:50PM +0100, David Hildenbrand wrote:
> e.g. futex_atomic_op_inuser(): easy to fix, add preempt_enable/disable
> respectively.
>
> e.g. futex_atomic_cmpxchg_inatomic(): not so easy / nice to fix.
>
> The "inatomic" variants rely on the caller to make sure that preemption is
> disabled.
>
> pagefault_disable();
> ret = futex_atomic_cmpxchg_inatomic(curval, uaddr, uval, newval);
> pagefault_enable();
Typically the _inatomic() variants of functions have the exception
tables required for fixups and can return -EFAULT. In that regard the
futex_atomic_cmpxchg_inatomic() is consistently named.
In specific the above is taken from cmpxchg_futex_value_locked(), which
is private to futex.c, so we don't really need to worry about it.
Furthermore, the futex.c helpers that wrap them in pagefault_disable()
do so because they want to handle the fault themselves. I don't think we
need to worry about that.
> 1. We could simply add preempt_disable/enable to the calling code. However that
> results in _all_ futex_atomic_cmpxchg_inatomic() running with disabled
> preemption, although the implementation doesn't really need it. So there is not
> really a "decoupling", but to counters to set.
Not really needed, the few callsites where they are not already under a
lock is where we want to explicitly handle the -EFAULT case ourselves.
> 2. We could add the preempt_disable/enable to the implementations that only
> need it, leaving calling code as is. However, then the name
> "futex_atomic_cmpxchg_inatomic" is misleading, because it has nothing to do
> with "inatomic" anymore.
The _inatomic() naming is because it _can_ be called from atomic
context, like __copy_to_user_inatomic(). It doesn't mean it has to.
These functions work just fine outside of atomic regions.
And they still can be used in atomic regions, but now
pagefault_disable() will also trigger the exception fixup.
I don't think we should worry too much about this.
> The same applies to other "inatomic" functions. I think most of these functions
> rely on pagefaults to be disabled in order to work correctly, not disabled
> preemption.
>
> Any idea how to fix this or what would be the way to go?
I have the feeling you're over thinking this. _inatomic() has exception
fixups and will return -EFAULT when it cannot do the pagefault in place,
for whatever reason -- traditionally because of atomic context, now also
pagefault_disable().
And esp. things like futexes have been extensively used under -rt and
are known good.
next prev parent reply other threads:[~2015-03-27 16:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-10 14:23 David Hildenbrand
2014-12-10 14:23 ` [PATCH v2 1/5] uaccess: add pagefault_count to thread_info David Hildenbrand
2014-12-15 10:07 ` LF.Tan
2014-12-15 11:23 ` David Hildenbrand
2014-12-15 12:48 ` Peter Zijlstra
2014-12-10 14:23 ` [PATCH v2 2/5] uaccess: count pagefault_disable() levels in pagefault_count David Hildenbrand
2014-12-10 14:23 ` [PATCH v2 3/5] mm, uaccess: trigger might_sleep() in might_fault() when pagefaults are disabled David Hildenbrand
2014-12-10 14:23 ` [PATCH v2 4/5] uaccess: clarify that uaccess may only sleep if pagefaults are not disabled David Hildenbrand
2014-12-10 14:23 ` [PATCH v2 5/5] uaccess: CONFIG_DEBUG_PAGEFAULT_COUNT to debug pagefault_count David Hildenbrand
2014-12-15 10:45 ` [PATCH v2 0/5] Reenable might_sleep() checks for might_fault() Peter Zijlstra
2014-12-15 11:21 ` David Hildenbrand
2014-12-15 12:50 ` Peter Zijlstra
2014-12-15 13:08 ` David Hildenbrand
2015-01-12 14:19 ` David Hildenbrand
2015-01-30 15:52 ` Christian Borntraeger
2015-02-09 14:42 ` Peter Zijlstra
2015-02-19 14:48 ` David Hildenbrand
2015-02-19 15:07 ` Peter Zijlstra
2015-02-19 15:14 ` David Hildenbrand
2015-03-27 15:40 ` David Hildenbrand
2015-03-27 16:15 ` Peter Zijlstra [this message]
2015-03-27 19:05 ` David Hildenbrand
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=20150327161536.GH23123@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=David.Laight@ACULAB.COM \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=borntraeger@de.ibm.com \
--cc=dahi@linux.vnet.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=hocko@suse.cz \
--cc=hughd@google.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=paulus@samba.org \
--cc=schwidefsky@de.ibm.com \
--cc=tglx@linutronix.de \
/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
Powered by JetHome