Re: [PATCH v2] mips: mm: Call rcutree_report_cpu_starting() even earlier

[Stefan Wiehler]

Hi Maciej,

> I was able to reproduce this splat on latest mainline with the attached
> defconfig on QEMU, which I invoked as follows:
> 
> $ qemu-system-mips64 -cpu I6400 -smp 2 -kernel vmlinux -nographic
> 
>   =============================
>   WARNING: suspicious RCU usage
>   7.0.0-rc7-dirty #13 Not tainted
>   -----------------------------
>   kernel/locking/lockdep.c:3801 RCU-list traversed in non-reader section!!
>   
>   other info that might help us debug this:
>   
>   
>   RCU used illegally from offline CPU!
>   rcu_scheduler_active = 1, debug_locks = 1
>   no locks held by swapper/1/0.
>   
>   stack backtrace:
>   CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 7.0.0-rc7-dirty #13 VOLUNTARY 
>   Hardware name: mti,malta
>   Stack : a8000000021fb938 0000000000000000 0000000000000018 a8000000021fb888
>           a8000000021fb888 a8000000021fb9b8 0000000000000000 0000000000000000
>           00f87412b0603bdf 0000000000000001 0000000000000000 0000000000000000
>           ffffffff80f9e5b0 0000000000000000 ffffffff80abb824 000000000000001b
>           ffffffffffffffff 0000000000000000 0000000000000000 ffffffff80d2ea28
>           ffffffff80e10000 ffffffff80ccf9e0 0000000000000001 0000000000000000
>           0000000000000003 0000000000000000 a8000000021fb680 0000000030400080
>           0000000000000000 a8000000021f8000 a8000000021fb880 ffffffff80f00000
>           ffffffff801190dc 0000000000000000 0000000000000000 0000000000000000
>           0000000000000000 0000000000000000 ffffffff801190f4 00f87412b0603bdf
>           ...
>   Call Trace:
>   [<ffffffff801190f4>] show_stack+0x5c/0x150
>   [<ffffffff8010eeac>] dump_stack_lvl+0xa4/0xe8
>   [<ffffffff801bd250>] lockdep_rcu_suspicious+0x180/0x228
>   [<ffffffff801c2020>] __lock_acquire+0x15b0/0x2b00
>   [<ffffffff801c421c>] lock_acquire+0x144/0x490
>   [<ffffffff80ac9e9c>] _raw_spin_lock_irqsave+0x54/0x88
>   [<ffffffff8031ec90>] ___slab_alloc+0x190/0x950
>   [<ffffffff8032282c>] __kmalloc_noprof+0x344/0x520
>   [<ffffffff80323d88>] __alloc_empty_sheaf+0x48/0x78
>   [<ffffffff80321904>] __pcs_replace_empty_main+0x4ec/0x680
>   [<ffffffff80322944>] __kmalloc_noprof+0x45c/0x520
>   [<ffffffff80abe770>] r4k_tlb_uniquify+0x58/0x2c8
>   [<ffffffff8013af6c>] r4k_tlb_configure+0xb4/0xd0
>   [<ffffffff8013c5fc>] tlb_init+0xc/0x80
>   [<ffffffff8011b054>] per_cpu_trap_init+0xfc/0x168
>   [<ffffffff80123a68>] start_secondary+0x28/0x118
>   [<ffffffff80125864>] mips_cps_core_boot+0x74/0x88
> 
> However, on that platform even before that you will see various Lockdep RCU
> splats complaining about taking the console lock from an offline CPU
> originating from c-r4k.c; one more reason to call rcutree_report_cpu_starting()
> earlier.

Have you been able to reproduce the issue with above hints?

Kind regards,

Stefan