Re: [mm] 408579cd62: WARNING:suspicious_RCU_usage

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 4140 bytes --]

Hey Linus,

On Sun, Jul 02, 2023 at 09:34:35PM -0700, Linus Torvalds wrote:
> On Sun, 2 Jul 2023 at 19:04, kernel test robot <oliver.sang@intel.com> wrote:
> >
> > commit: 408579cd627a15bd703fe3eeb8485fd02726e9d3 ("mm: Update do_vmi_align_munmap() return semantics")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> >
> > in testcase: boot
> >
> > on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
> >
> > caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
> >
> >
> >
> > If you fix the issue, kindly add following tag
> > Reported-by: kernel test robot <oliver.sang@intel.com>

I'm not entirely sure if it is related, as stuff in the guts of mm like
this is beyond me, but I've been seeing similar warnings on RISC-V. This
is the only hit on lore for "lib/maple_tree.c:{860,816} suspicious
rcu_dereference_check() usage!", so I figured it might be. Apologies if
not!

	Running RCU synchronous self tests
	Running RCU synchronous self tests
	RCU Tasks: Setting shift to 4 and lim to 1 rcu_task_cb_adjust=1.
	RCU Tasks Trace: Setting shift to 4 and lim to 1 rcu_task_cb_adjust=1.
	Running RCU-tasks wait API self tests
	riscv: ELF compat mode supported
	ASID allocator using 16 bits (65536 entries)
	rcu: Hierarchical SRCU implementation.
	rcu:     Max phase no-delay instances is 1000.
	EFI services will not be available.
	Callback from call_rcu_tasks_trace() invoked.
	smp: Bringing up secondary CPUs ...
	
	=============================
	WARNING: suspicious RCU usage
	6.4.0-10173-ga901a3568fd2 #1 Not tainted
	-----------------------------
	lib/maple_tree.c:860 suspicious rcu_dereference_check() usage!
	
	other info that might help us debug this:
	
	
	RCU used illegally from offline CPU!
	rcu_scheduler_active = 1, debug_locks = 1
	1 lock held by swapper/1/0:
	 #0: ffffffff8169ceb0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x0/0x32
	
	stack backtrace:
	CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.4.0-10173-ga901a3568fd2 #1
	Hardware name: riscv-virtio,qemu (DT)
	Call Trace:
	[<ffffffff80006a20>] show_stack+0x2c/0x38
	[<ffffffff80af3ee0>] dump_stack_lvl+0x5e/0x80
	[<ffffffff80af3f16>] dump_stack+0x14/0x1c
	[<ffffffff80083ff0>] lockdep_rcu_suspicious+0x19e/0x232
	[<ffffffff80ad4802>] mtree_load+0x18a/0x3b6
	[<ffffffff80091632>] __irq_get_desc_lock+0x2c/0x82
	[<ffffffff80094722>] enable_percpu_irq+0x36/0x9e
	[<ffffffff800087d4>] riscv_ipi_enable+0x32/0x4e
	[<ffffffff80008692>] smp_callin+0x24/0x66
	
	=============================
	WARNING: suspicious RCU usage
	6.4.0-10173-ga901a3568fd2 #1 Not tainted
	-----------------------------
	lib/maple_tree.c:816 suspicious rcu_dereference_check() usage!
	
	other info that might help us debug this:
	
	
	RCU used illegally from offline CPU!
	rcu_scheduler_active = 1, debug_locks = 1
	1 lock held by swapper/1/0:
	 #0: ffffffff8169ceb0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x0/0x32
	
	stack backtrace:
	CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.4.0-10173-ga901a3568fd2 #1
	Hardware name: riscv-virtio,qemu (DT)
	Call Trace:
	[<ffffffff80006a20>] show_stack+0x2c/0x38
	[<ffffffff80af3ee0>] dump_stack_lvl+0x5e/0x80
	[<ffffffff80af3f16>] dump_stack+0x14/0x1c
	[<ffffffff80083ff0>] lockdep_rcu_suspicious+0x19e/0x232
	[<ffffffff80ad4932>] mtree_load+0x2ba/0x3b6
	[<ffffffff80091632>] __irq_get_desc_lock+0x2c/0x82
	[<ffffffff80094722>] enable_percpu_irq+0x36/0x9e
	[<ffffffff800087d4>] riscv_ipi_enable+0x32/0x4e
	[<ffffffff80008692>] smp_callin+0x24/0x66
	smp: Brought up 1 node, 16 CPUs

> > [  215.088258][    T1] WARNING: suspicious RCU usage
> 
> I think the
> 
>         validate_mm(mm);
> 
> call (mm/mmap.c:2561) needs to be moved up to before the
> 
>         if (unlock)
>                 mmap_read_unlock(mm);
> 
> that is just a couple of lines earlier.
> 
> Can you verify that that fixes the warning?

I can't speak for Oliver & LKP, but that change didn't fix it for me,
although my issue could be different of course.

Cheers,
Conor.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]