From: will.deacon@arm•com (Will Deacon)
To: linux-arm-kernel@lists•infradead.org
Subject: Page fault while link_path_walk for path_len > 4060 bytes
Date: Tue, 7 Nov 2017 01:19:03 +0000 [thread overview]
Message-ID: <20171107011902.GB13514@arm.com> (raw)
In-Reply-To: <20171104001757.GM21978@ZenIV.linux.org.uk>
On Sat, Nov 04, 2017 at 12:17:57AM +0000, Al Viro wrote:
> [looking through the old mail]
>
> On Tue, Sep 12, 2017 at 09:26:16PM +0100, Will Deacon wrote:
> > > - { do_page_fault, SIGSEGV, SEGV_MAPERR, "level 3 translation
> > > fault" },
> > > + { do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 3
> > > translation fault" },
> > > we will try with above changes and get back to you.
> >
> > Did you test with this change?
>
> FWIW, while that went in as commit 760bfb47c36a ("arm64: fault: Route pte
> translation faults via do_translation_fault"), I wonder if the same issue
> exists on arm. It looks like the pagefault handler there is fairly
> similar to arm64 one and the same shortcut is present there.
So we never actually nailed this one down on arm64 (the problem mysteriously
disappeared iirc, and I failed to reproduce it on my systems) but I fixed it
anyway because it looked at least theoretically possible. In that case, yes,
I think ARM needs the same sort of fixes for both 2 and 3 level tables where
the handler branch directly to do_page_fault.
> The more I'm looking at that, the more it looks like we *really* need
> a comment in all instances of load_unaligned_zeropad() warning about
> that pitfall. Something like
> /*
> * Load an unaligned word from kernel space.
> *
> * In the (very unlikely) case of the word being a page-crosser
> * and the next page not being mapped, take the exception and
> * return zeroes in the non-existing part.
> *
> * NOTE: this relies upon the pagefault handler *NOT* blocking
> * in such situation (fault in kernel mode on kernel address with
> * exception fixup present). Verify that for your architecture
> * before using an equivalent of this approach. Note that
> * you can't count upon faulthandler_disabled() saving you;
> * this function can be called e.g. under a spinlock on non-preempt
> * kernels without pagefault_disable() done by caller.
> */
> perhaps. That property holds on x86, ppc and (now) arm64, but as
> arm64 case shows, it might not be true for other architectures.
> As the matter of fact, e.g. sparc64 (which will not use that
> thing for obvious reasons anyway) it is *not* true, etc.
I wonder if there's any mileage in a test module for this? That code rarely
(if ever) gets run in practice.
Will
prev parent reply other threads:[~2017-11-07 1:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <08e7e3332dc86c535dd2961ac1cde0b5@codeaurora.org>
[not found] ` <54083a824d6705a93d972ca5ef3a7b35@codeaurora.org>
[not found] ` <3958983ccec4aca494bf72c397f34bfa@codeaurora.org>
[not found] ` <953068e79da559bfd4f13e46e31c5a4e@codeaurora.org>
2017-08-22 12:57 ` Page fault while link_path_walk for path_len > 4060 bytes Will Deacon
[not found] ` <b13b3a27e92c5413d168ad775163ea91@codeaurora.org>
2017-08-28 6:20 ` Al Viro
[not found] ` <c4256a77288fd5f275a45bc73c9c78f0@codeaurora.org>
2017-09-11 3:14 ` ankijain at codeaurora.org
2017-09-12 20:26 ` Will Deacon
2017-09-13 17:05 ` ankijain at codeaurora.org
2017-09-26 17:36 ` ankijain at codeaurora.org
2017-11-04 0:17 ` Al Viro
2017-11-07 1:19 ` Will Deacon [this message]
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=20171107011902.GB13514@arm.com \
--to=will.deacon@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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