From: bugzilla-daemon@kernel.org
To: linuxppc-dev@lists.ozlabs.org
Subject: [Bug 216183] [bisected] Kernel 5.19-rc4 boots ok with CONFIG_PPC_RADIX_MMU=y but fails to boot with CONFIG_PPC_HASH_MMU_NATIVE=y
Date: Thu, 14 Jul 2022 12:57:21 +0000 [thread overview]
Message-ID: <bug-216183-206035-7VD7cQX48R@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-216183-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=216183
--- Comment #8 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 301425
--> https://bugzilla.kernel.org/attachment.cgi?id=301425&action=edit
bisect.log
Successfully did a bisect which revealed this commit:
# git bisect good
a008f8f9fd67ffb13d906ef4ea6235a3d62dfdb6 is the first bad commit
commit a008f8f9fd67ffb13d906ef4ea6235a3d62dfdb6
Author: Nicholas Piggin <npiggin@gmail.com>
Date: Sat Jan 30 23:08:41 2021 +1000
powerpc/64s/hash: improve context tracking of hash faults
This moves the 64s/hash context tracking from hash_page_mm() to
__do_hash_fault(), so it's no longer called by OCXL / SPU
accelerators, which was certainly the wrong thing to be doing,
because those callers are not low level interrupt handlers, so
should have entered a kernel context tracking already.
Then remain in kernel context for the duration of the fault,
rather than enter/exit for the hash fault then enter/exit for
the page fault, which is pointless.
Even still, calling exception_enter/exit in __do_hash_fault seems
questionable because that's touching per-cpu variables, tracing,
etc., which might have been interrupted by this hash fault or
themselves cause hash faults. But maybe I miss something because
hash_page_mm very deliberately calls trace_hash_fault too, for
example. So for now go with it, it's no worse than before, in this
regard.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210130130852.2952424-32-npiggin@gmail.com
arch/powerpc/include/asm/bug.h | 1 +
arch/powerpc/mm/book3s64/hash_utils.c | 7 ++++---
arch/powerpc/mm/fault.c | 39 +++++++++++++++++++++++++----------
3 files changed, 33 insertions(+), 14 deletions(-)
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
next prev parent reply other threads:[~2022-07-14 12:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-27 22:54 [Bug 216183] New: Kernel 5.19-rc4 boots ok with CONFIG_PPC_RADIX_MMU=y but fails to boot with CONFIG_PPC_HASH_MMU_NATIVE=y bugzilla-daemon
2022-06-27 22:56 ` [Bug 216183] " bugzilla-daemon
2022-06-29 6:35 ` bugzilla-daemon
2022-06-29 10:28 ` bugzilla-daemon
2022-07-10 10:29 ` bugzilla-daemon
2022-07-10 11:01 ` bugzilla-daemon
2022-07-11 18:07 ` bugzilla-daemon
2022-07-11 18:08 ` bugzilla-daemon
2022-07-14 12:57 ` bugzilla-daemon [this message]
2022-07-29 7:13 ` [Bug 216183] [bisected] " bugzilla-daemon
2022-07-30 13:15 ` bugzilla-daemon
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=bug-216183-206035-7VD7cQX48R@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.