aboutsummaryrefslogtreecommitdiff
path: root/lib/timerqueue.c
diff options
context:
space:
mode:
authorMichael Schmitz <[email protected]>2023-03-01 15:11:07 +1300
committerGeert Uytterhoeven <[email protected]>2023-03-06 14:09:42 +0100
commite36a82bebbf7da814530d5a179bef9df5934b717 (patch)
treefce5898ccbfd0e534a829ffef949efb90f7446f4 /lib/timerqueue.c
parentd4b97925e87eb133e400fe4a482d750c74ce392f (diff)
m68k: Only force 030 bus error if PC not in exception table
__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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michael Schmitz <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
Diffstat (limited to 'lib/timerqueue.c')
0 files changed, 0 insertions, 0 deletions