Re: RFC: remove set_fs for m68k

[Michael Schmitz <schmitzmic@gmail.com>]

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