All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Schmitz <schmitzmic@gmail.com>
To: linux-m68k@vger.kernel.org
Cc: geert@linux-m68k.org, uli@fpond.eu, fthain@linux-m68k.org,
	viro@zeniv.linux.org.uk, Michael Schmitz <schmitzmic@gmail.com>
Subject: [PATCH v3 2/8] m68k: Only force 030 bus error if PC not in exception table
Date: Wed,  7 Feb 2024 10:10:58 +1300	[thread overview]
Message-ID: <20240206211104.26421-3-schmitzmic@gmail.com> (raw)
In-Reply-To: <20240206211104.26421-1-schmitzmic@gmail.com>

commit 513138a14063760ef611f18ba76c5c7915ff8cdd upstream.

__get_kernel_nofault() does copy data in supervisor mode when
forcing a task backtrace log through /proc/sysrq_trigger.
This is expected cause a bus error exception on e.g. NULL
pointer dereferencing when logging a kernel task has no
workqueue associated. This bus error ought to be ignored.

Our 030 bus error handler is ill equipped to deal with this:

Whenever ssw indicates a kernel mode access on a data fault,
we don't even attempt to handle the fault and instead always
send a SEGV signal (or panic). As a result, the check
for exception handling at the fault PC (buried in
send_sig_fault() which gets called from do_page_fault()
eventually) is never used.

In contrast, both 040 and 060 access error handlers do not
care whether a fault happened on supervisor mode access,
and will call do_page_fault() on those, ultimately honoring
the exception table.

Add a check in bus_error030 to call do_page_fault() in case
we do have an entry for the fault PC in our exception table.

I had attempted a fix for this earlier in 2019 that did rely
on testing pagefault_disabled() (see link below) to achieve
the same thing, but this patch should be more generic.

Tested on 030 Atari Falcon.

Reported-by: Eero Tamminen <oak@helsinkinet.fi>
Link: https://lore.kernel.org/r/alpine.LNX.2.21.1904091023540.25@nippy.intranet
Link: https://lore.kernel.org/r/63130691-1984-c423-c1f2-73bfd8d3dcd3@gmail.com
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://lore.kernel.org/r/20230301021107.26307-1-schmitzmic@gmail.com
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
 arch/m68k/kernel/traps.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/m68k/kernel/traps.c b/arch/m68k/kernel/traps.c
index 6c9ca24830e9..c547140b8325 100644
--- a/arch/m68k/kernel/traps.c
+++ b/arch/m68k/kernel/traps.c
@@ -29,6 +29,7 @@
 #include <linux/init.h>
 #include <linux/ptrace.h>
 #include <linux/kallsyms.h>
+#include <linux/extable.h>
 
 #include <asm/setup.h>
 #include <asm/fpu.h>
@@ -549,7 +550,8 @@ static inline void bus_error030 (struct frame *fp)
 			errorcode |= 2;
 
 		if (mmusr & (MMU_I | MMU_WP)) {
-			if (ssw & 4) {
+			/* We might have an exception table for this PC */
+			if (ssw & 4 && !search_exception_tables(fp->ptregs.pc)) {
 				pr_err("Data %s fault at %#010lx in %s (pc=%#lx)\n",
 				       ssw & RW ? "read" : "write",
 				       fp->un.fmtb.daddr,
-- 
2.17.1


  parent reply	other threads:[~2024-02-06 21:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-06 21:10 [PATCH v3 0/8] m68k v4.4 backport fixes Michael Schmitz
2024-02-06 21:10 ` [PATCH v3 1/8] m68k/mm: Adjust VM area to be unmapped by gap size for __iounmap() Michael Schmitz
2024-02-06 21:10 ` Michael Schmitz [this message]
2024-02-06 21:10 ` [PATCH v3 3/8] m68k: include module.h to make use of exception handling in traps.c Michael Schmitz
2024-02-06 21:11 ` [PATCH v3 4/8] m68k: Handle arrivals of multiple signals correctly Michael Schmitz
2024-02-06 21:11 ` [PATCH v3 5/8] m68k: Update ->thread.esp0 before calling syscall_trace() in ret_from_signal Michael Schmitz
2024-02-06 21:11 ` [PATCH v3 6/8] m68k: Leave stack mangling to asm wrapper of sigreturn() Michael Schmitz
2024-02-06 21:11 ` [PATCH v3 7/8] m68k: fix livelock in uaccess Michael Schmitz
2024-02-06 21:11 ` [PATCH v3 8/8] m68k: Move signal frame following exception on 68020/030 Michael Schmitz
2024-02-06 21:15 ` [PATCH v3 0/8] m68k v4.4 backport fixes John Paul Adrian Glaubitz
2024-02-06 21:37   ` Michael Schmitz

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=20240206211104.26421-3-schmitzmic@gmail.com \
    --to=schmitzmic@gmail.com \
    --cc=fthain@linux-m68k.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-m68k@vger.kernel.org \
    --cc=uli@fpond.eu \
    --cc=viro@zeniv.linux.org.uk \
    /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.