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
