From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Peter Rosin <peda@axentia.se>
Cc: "nico@fluxnic.net" <nico@fluxnic.net>,
"'linux-arm-kernel@lists.infradead.org'"
<linux-arm-kernel@lists.infradead.org>,
"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: Domain faults when CONFIG_CPU_SW_DOMAIN_PAN is enabled
Date: Thu, 3 Dec 2015 16:41:18 +0000 [thread overview]
Message-ID: <20151203164118.GR8644@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <94580382ca344ae2b64f66fb778c6ff7@EMAIL.axentia.se>
On Thu, Dec 03, 2015 at 04:12:06PM +0000, Peter Rosin wrote:
> Since it seems like a race is at the bottom of the observed problems, I'm
> going to look for things that look racy. The things that stand out to me
> are:
>
> * uaccess.h:modify_domain() does a read-modify-write on DACR using
> get_domain and set_domain, and I don't see any locking. Is that
> safe? Why?
It's safe:
* the DACR is per-CPU
* all exceptions preserve the original DACR value when they return.
This is done by storing the DACR value at entry onto the stack, along
with the register set, and restoring it along with the register set
on exit from exception processing, as if "nothing ever happened".
This includes if the exception processing caused a switch to another
thread.
> * uaccess_with_memcpy.c:__copy_to_user() has a mode in which it copies
> "non-atomically" (if faulthandler_disabled() returns 0). If a fault
> happens during __copy_to_user, what prevents some other thread from
> clobbering DACR?
See the second point above. Moreover, if we sleep in down_read(),
then __switch_to() reads the current DACR value and saves it in the
thread information, and will restore that value when resuming the
thread - even if the thread has been migrated to a different CPU.
> * In uaccess.h:uaccess_save_and_enable(), what prevents a context
> switch between the get_domain and set_domain calls?
Nothing, but it doesn't matter, because the DACR register is saved
and restored to preserve its value across all exceptions and thread
switches.
I suspect the only way to nail this down is to litter the uaccess
code (virtually every alternate line) with:
BUG_ON(get_domain() & domain_mask(DOMAIN_USER) ==
domain_val(DOMAIN_USER, DOMAIN_NOACCESS));
to narrow down the exact point where the domain register seemingly
gets reset. Maybe it'll provide some hint.
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
next prev parent reply other threads:[~2015-12-03 16:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-03 8:33 Peter Rosin
2015-12-03 11:00 ` Russell King - ARM Linux
2015-12-03 11:38 ` Peter Rosin
2015-12-03 11:51 ` Russell King - ARM Linux
2015-12-03 12:08 ` Peter Rosin
2015-12-03 13:37 ` Russell King - ARM Linux
2015-12-03 16:12 ` Peter Rosin
2015-12-03 16:41 ` Russell King - ARM Linux [this message]
2015-12-03 17:27 ` Russell King - ARM Linux
2015-12-03 18:28 ` Nicolas Pitre
2015-12-05 13:41 ` Russell King - ARM Linux
2015-12-03 21:37 ` Peter Rosin
2015-12-10 0:22 ` Russell King - ARM Linux
2015-12-10 15:29 ` Peter Rosin
2015-12-10 16:20 ` Russell King - ARM Linux
2015-12-10 18:32 ` Peter Rosin
2015-12-30 16:51 ` Peter Rosin
2015-12-30 16:57 ` Peter Rosin
-- strict thread matches above, loose matches on Subject: below --
2015-12-03 7:43 Peter Rosin
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=20151203164118.GR8644@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nico@fluxnic.net \
--cc=peda@axentia.se \
/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
all inboxes | Powered by JetHome®