From: Julien Thierry <julien.thierry@arm.com>
To: Russell King - ARM Linux <linux@armlinux.org.uk>, hpa@zytor.com
Cc: Ingo Molnar <mingo@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
James Morse <james.morse@arm.com>
Subject: Re: Sleeping in user_access section
Date: Fri, 23 Nov 2018 11:57:31 +0000 [thread overview]
Message-ID: <44297716-74aa-1f14-67be-3594b5244b74@arm.com> (raw)
In-Reply-To: <20181123105034.GQ30658@n2100.armlinux.org.uk>
On 23/11/18 10:50, Russell King - ARM Linux wrote:
> On Fri, Nov 23, 2018 at 01:57:12AM -0800, hpa@zytor.com wrote:
>> You should never call a sleeping function from a user_access section.
>> It is intended for very limited regions.
>
> So, what happens if the "unsafe" user access causes a page fault that
> ends up sleeping?
>
Thanks for pointing that out.
On the arm64 side, PAN state is saved in spsr and (if PAN feature is
enabled in SCTLR) PAN bit gets set (disabling the user accesses). For
software PAN we follow the same behaviour on exception entry. So upon
exception we implicitly exit user_access mode and then re-enter it when
returning from the exception.
On x86, the EFLAGS.AC bit is also saved upon exception and I think it is
cleared upon exception entry so there is implicit exit from the
user_access mode when taking exception/interrupt.
This however is just how those two architectures happen to behave and
doesn't seem to be specified as part of the user_access API...
Which is why I'd like to clarify the semantics of user_access region wrt
sleeping functions.
Thanks,
--
Julien Thierry
next prev parent reply other threads:[~2018-11-23 11:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-23 9:27 Sleeping in user_access section Julien Thierry
2018-11-23 9:57 ` hpa
2018-11-23 10:16 ` Julien Thierry
2018-11-23 10:50 ` Russell King - ARM Linux
2018-11-23 11:57 ` Julien Thierry [this message]
2018-11-23 13:04 ` Russell King - ARM Linux
2018-11-27 19:05 ` H. Peter Anvin
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=44297716-74aa-1f14-67be-3594b5244b74@arm.com \
--to=julien.thierry@arm.com \
--cc=catalin.marinas@arm.com \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mingo@redhat.com \
--cc=will.deacon@arm.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: 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).