[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20230320005732.1429533-4-sashal@kernel.org>
Date: Sun, 19 Mar 2023 20:57:27 -0400
From: Sasha Levin <sashal@...nel.org>
To: linux-kernel@...r.kernel.org, stable@...r.kernel.org
Cc: Michael Schmitz <schmitzmic@...il.com>,
Eero Tamminen <oak@...sinkinet.fi>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Sasha Levin <sashal@...nel.org>, laurent@...ier.eu,
linux-m68k@...ts.linux-m68k.org
Subject: [PATCH AUTOSEL 4.14 4/9] m68k: Only force 030 bus error if PC not in exception table
From: Michael Schmitz <schmitzmic@...il.com>
[ Upstream commit e36a82bebbf7da814530d5a179bef9df5934b717 ]
__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@...sinkinet.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@...il.com>
Reviewed-by: Geert Uytterhoeven <geert@...ux-m68k.org>
Link: https://lore.kernel.org/r/20230301021107.26307-1-schmitzmic@gmail.com
Signed-off-by: Geert Uytterhoeven <geert@...ux-m68k.org>
Signed-off-by: Sasha Levin <sashal@...nel.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 5c72deb117a8e..d75c143d99d0f 100644
--- a/arch/m68k/kernel/traps.c
+++ b/arch/m68k/kernel/traps.c
@@ -30,6 +30,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>
@@ -550,7 +551,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.39.2
Powered by blists - more mailing lists