Re: RFC: remove set_fs for m68k

Michael Schmitz
2021-07-13T08:16:35Z

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