From: David Hildenbrand <dahi@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
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 16:40:50 +0100 [thread overview]
Message-ID: <20150327164050.04693bff@thinkpad-w530> (raw)
In-Reply-To: <20150219150723.GF21418@twins.programming.kicks-ass.net>
> On Thu, Feb 19, 2015 at 03:48:05PM +0100, David Hildenbrand wrote:
> > Downside is that now that I have to touch all fault handlers, I have to go
> > through all archs again.
>
> You should be able to borrow from the -rt patches there. They have all
> that.
>
Hi Peter,
I hadn't much time to work on this lately, and it seems like this will be much
bigger that I expected.
We have various places in the code that rely on pagefault_disable() to also
disable preemtpion. Most of these places were ignored on -rt, because not
supported.
One of these places is e.g. powerpc's vmx based usercopy. While these places
are easy to handle, I was struggeling e.g. with asm-generic futex functions.
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();
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.
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.
3. We could move the pagefault_ calls into the implementation and add
the preempt_ calls to the calling code. Once again, functions that don't rely
on preemption have it disabled.
The "inatomic" part is now somewhat wrong. Because they can't be called from
atomic context. They have to be called from a pagefault-disabled
environment.The preemption part is implementation specific.
So I wonder if what we really want is something like
/* can be called from atomic context, but it's not required */
int futex_atomic_cmpxchg_nopfault(...) {
int ret;
pagefault_disable();
ret = futex_atomic_cmpxchg_disabled_pfault(...)
pagefault_enable();
return ret;
}
/* has to be called with disabled pagefaults */
int futex_atomic_cmpxchg_disabled_pfault(...) {
int ret;
/* do architecture specific stuff */
return ret;
}
/* has to be called with disabled pagefaults */
int futex_atomic_cmpxchg_disabled_pfault(...) {
int ret;
preempt_disable()
/* do architecture common stuff as default */
preempt_enable()
return ret;
}
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?
Thanks!
David
next prev parent reply other threads:[~2015-03-27 15:40 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-10 14:23 [PATCH v2 0/5] Reenable might_sleep() checks for might_fault() David Hildenbrand
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-10 14:23 ` 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 ` 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 ` David Hildenbrand
2014-12-10 14:23 ` [PATCH v2 5/5] uaccess: CONFIG_DEBUG_PAGEFAULT_COUNT to debug pagefault_count David Hildenbrand
2014-12-10 14:23 ` 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 [this message]
2015-03-27 15:40 ` David Hildenbrand
2015-03-27 16:15 ` Peter Zijlstra
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=20150327164050.04693bff@thinkpad-w530 \
--to=dahi@linux.vnet.ibm.com \
--cc=David.Laight@ACULAB.COM \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=borntraeger@de.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=peterz@infradead.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;
as well as URLs for NNTP newsgroup(s).