Hi Christoph,
Am 13.07.2021 um 17:41 schrieb Christoph Hellwig:
On Tue, Jul 13, 2021 at 07:12:45AM +1200, Michael Schmitz wrote:
That confirms my guess - can we rely on the call trace in that case? And
how does overwriting kernel code at that address tee up with the kernel
still happily chugging along?
So if you remove the WARN_ON everything keeps running just fine? I
I'll try that next. It certainly ran fine when I tried your earlier
version which still had the __constant_copy_from_user() (but modified to
use __get_user_asm() for the 1, 2 and 4 byte cases). That doesn't prove
much though - I may not have hit the exact same memory pressure (not
sure how often savelogs runs on that system, and I haven't checked how
much the kernel size differs between the two versions).
Anyway, I'll try my previous version again, and I'll try with the
WARN_ON removed, but that'll take a few days (did I mention this 030 is
clocked at 16 MHz only?).
wonder if in_interrupt somehow is not exact in m68k. Or we actually
call it from an interrupt. Let me try to unwind the various call
chains.
I suspect it may get called from an interrupt - not sure what interrupt
handler would call vm_map_ram(), or if that even is allowed though.
Might happen during a softirq, which is covered by in_interrupt as well ...
Cheers,
Michael
