Hi Michael, On 2/5/23 3:19 PM, Michael Schmitz wrote: > ... > > Seeing Finn's report that Al Viro's VM_FAULT_RETRY fix may have solved > his task corruption troubles on 040, I just noticed that I probably > misunderstood how Al's patch works. > > Botching up a fault retry and carrying on may well leave the page tables > in a state where some later access could go to the wrong page and > manifest as user space corruption. Could you try Al's patch 4 (m68k: fix > livelock in uaccess) to see if this helps? > ...
ok, this appears to be the patch:
Signed-off-by: Al Viro <v...@zeniv.linux.org.uk>
---
arch/m68k/mm/fault.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/m68k/mm/fault.c b/arch/m68k/mm/fault.c
index 4d2837eb3e2a..228128e45c67 100644
--- a/arch/m68k/mm/fault.c
+++ b/arch/m68k/mm/fault.c
@@ -138,8 +138,11 @@ int do_page_fault(struct pt_regs *regs, unsigned
long address,
fault = handle_mm_fault(vma, address, flags, regs);
pr_debug("handle_mm_fault returns %x\n", fault);
- if (fault_signal_pending(fault, regs))
+ if (fault_signal_pending(fault, regs)) {
+ if (!user_mode(regs))
+ goto no_context;
return 0;
+ }
/* The fault is fully completed (including releasing mmap lock) */
if (fault & VM_FAULT_COMPLETED)
--
2.30.2
Applying the above patch to mainline v6.2-rc7, I see the following
results on the IIci (3 tests per kernel):
Kernel Stack-Smashing
6.2.0-rc7 (no patch) 4, 3, 3
6.2.0-rc7 (patched) 2, 1, 0
So the patch seems to reduce the stack smashing, but it doesn't
eliminate it entirely, so there might be something else (or additional)
going on. The serial console logs are attached, as well as the config
file I'm using in case there's something obvious that I'm missing.
Next, I'll investigate whether a git bisect might be helpful in
isolating the original cause of the bug.
-Stan
maciici_6.2-rc7.txt.xz
Description: Binary data
maciici_6.3-rc7-patched.txt.xz
Description: Binary data
config-6.1.8-mac.xz
Description: Binary data
