Re: RFC: remove set_fs for m68k

[Michael Schmitz <schmitzmic@gmail.com>]

Am 13.07.2021 um 20:54 schrieb Christoph Hellwig:
> On Tue, Jul 13, 2021 at 08:16:25PM +1200, Michael Schmitz wrote:
>> 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

That one crashed even harder - again with the same odd repetitive 
pattern around the trap PC, but resulting in a kernel panic this time:

[25187.890000] Data read fault at 0x00000000 in CPU (pc=0x80050d06)
[25187.900000] *** LINE 1010 ***   FORMAT=0
[25187.900000] Current process id is 1409
[25187.900000] BAD KERNEL TRAP: 00000000
[25187.900000] Modules linked in: atari_scsi ne 8390p
[25187.900000] PC: [<0000f85c>] PITBL+0xc8/0x410
[25187.900000] SR: 2608  SP: e17e02dc  a2: 004a28ae
[25187.900000] d0: 00000000    d1: 00000800    d2: 00000000    d3: 00000040
[25187.900000] d4: 00000000    d5: 00049ef6    a0: 0000f858    a1: 003ee318
[25187.900000] Process savelog (pid: 1409, task=59e59dd6)
[25187.900000] Frame format=0
[25187.900000] Stack from 00593d24:
[25187.900000]         00049f6e 00000040 004b0800 00000001 00000040 0000000
0 00049ef6 002c7bb2
[25187.900000]         003ee318 003ec508 00593de8 00593d68 0004a01e 003ee31
8 00593d68 003ee318
[25187.900000]         000279fe 00000000 0004a06e 003ee318 003ee318 0004c47
8 003ee318 003ee318
[25187.900000]         000499b8 000499de 003ee318 00007a82 00000040 0000000
0 0000000c 00803100
[25187.900000]         00049f6e 0000000c 003b489c 00000000 00046a12 0000000
0 00000000 00000001
[25187.900000]         003ec508 00000000 00049802 00593de8 0004a01e 003ec50
8 00593de8 003ec508
[25187.900000] Call Trace: [<00049f6e>] __handle_irq_event_percpu+0x38/0xce
[25187.900000]  [<00049ef6>] __irq_wake_thread+0x0/0x40
[25187.900000]  [<002c7bb2>] printk+0x0/0x18
[25187.900000]  [<0004a01e>] handle_irq_event_percpu+0x1a/0x4c
[25187.900000]  [<000279fe>] warn_slowpath_fmt+0x0/0x62
[25187.900000]  [<0004a06e>] handle_irq_event+0x1e/0x30
[25187.900000]  [<0004c478>] handle_simple_irq+0x48/0x4e
[25187.900000]  [<000499b8>] generic_handle_irq+0x0/0x30
[25187.900000]  [<000499de>] generic_handle_irq+0x26/0x30
[25187.900000]  [<00007a82>] mfp_timer_d_handler+0x24/0x34
[25187.900000]  [<00049f6e>] __handle_irq_event_percpu+0x38/0xce
[25187.900000]  [<00046a12>] msg_print_ext_body+0x0/0x6a
[25187.900000]  [<00049802>] prb_read_valid+0x0/0x1e
[25187.900000]  [<0004a01e>] handle_irq_event_percpu+0x1a/0x4c
[25187.900000]  [<00046640>] info_print_ext_header.constprop.35+0x0/0x8a
[25187.900000]  [<0004a06e>] handle_irq_event+0x1e/0x30
[25187.900000]  [<0004c478>] handle_simple_irq+0x48/0x4e
[25187.900000]  [<000499de>] generic_handle_irq+0x26/0x30
[25187.900000]  [<00002c28>] do_IRQ+0x20/0x32
[25187.900000]  [<00002204>] do_one_initcall+0x90/0x150
[25187.900000]  [<00002b38>] user_irqvec_fixup+0xc/0x14
[25187.900000]  [<00002204>] do_one_initcall+0x90/0x150
[25187.900000]  [<00046a12>] msg_print_ext_body+0x0/0x6a
[25187.900000]  [<00048912>] __printk_safe_exit+0x0/0x10
[25187.900000]  [<000078de>] atari_scc_console_write+0x0/0x4a
[25187.900000]  [<00048912>] __printk_safe_exit+0x0/0x10
[25187.900000]  [<00048902>] __printk_safe_enter+0x0/0x10
[25187.900000]  [<000016e8>] kernel_pg_dir+0x6e8/0x1000
[25187.900000]  [<000484be>] vprintk_emit+0xe8/0xfa
[25187.900000]  [<0000376f>] show_cpuinfo+0x14f/0x19a
[25187.900000]  [<000484e6>] vprintk_default+0x16/0x1c
[25187.900000]  [<002c7bc4>] printk+0x12/0x18
[25187.900000]  [<00005786>] buserr_c+0x26a/0x4a8
[25187.900000]  [<00002934>] buserr+0x20/0x28
[25187.900000]  [<0000f85a>] PITBL+0xc6/0x410
[25187.900000]  [<000279fe>] warn_slowpath_fmt+0x0/0x62
[25187.900000]  [<0000f85a>] PITBL+0xc6/0x410
[25187.900000]  [<0000f31a>] WORK+0x88/0xca
[25187.900000]  [<00049f6e>] __handle_irq_event_percpu+0x38/0xce
[25187.900000]
[25187.900000] Code: 3cb8 3cb8 3cb8 3cb8 3cb8 3cb8 3cb8 3cb8 <3cb8> 3cb8 
3cb8 3cb8 3cb8 3cb8 3cb8 3cb8 3cb8 3cb8 3cb8 3cb8 3cb8 3cb8 3cb8 3cb8


I've got a vague recollection that I've seen weird crashes in the past 
related to temperature extremes (we've had a few unusually cold days in 
our parts just now), so I've gone back to a kernel from the switch stack 
/ refactoring exit tests (which ran the stress tests fine earlier) to 
rule that one out. Looking good so far, so I begin to wonder whether we 
need to introduce get_fc() and use that to restore the original sfc/dfc 
instead of assuming USER_DATA is always correct?

>> removed, but that'll take a few days (did I mention this 030 is clocked at
>> 16 MHz only?).
>
> No problem.
>
>> 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 ...
>
> vm_map_ram isn't allowed to be called from interrupts, just like all the
> vmalloc/vmap code.  But that doesn't mean it might not have crept in
> somewhere.

That's what I recalled, thanks.

Cheers,

	Michael