linux-kernel - Re: [BUG] -next lockdep invalid wait context

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZyV2DfuIPsISds-1@Boquns-Mac-mini.local>
Date: Fri, 1 Nov 2024 17:45:01 -0700
From: Boqun Feng <boqun.feng@...il.com>
To: Hillf Danton <hdanton@...a.com>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	"Paul E. McKenney" <paulmck@...nel.org>,
	Marco Elver <elver@...gle.com>, linux-kernel@...r.kernel.org,
	tj@...nel.org, gregkh@...uxfoundation.org
Subject: Re: [BUG] -next lockdep invalid wait context

On Sat, Nov 02, 2024 at 08:12:24AM +0800, Hillf Danton wrote:
> On Thu, 31 Oct 2024 08:21:36 +0100 Sebastian Andrzej Siewior <bigeasy@...utronix.de>
> > On 2024-10-30 16:10:58 [-0700], Paul E. McKenney wrote:
> > > 
> > > So I need to avoid calling kfree() within an smp_call_function() handler?
> > 
> > Yes. No kmalloc()/ kfree() in IRQ context.
> > 
> Another splat [1] with no link to kmalloc()/ kfree(). 
> 

Because it's a different bug.

	schedule():
	  __schedule():
	    rq_lock(); // <- rq lock is a raw spin lock, so no sleep inside
	    switch_mm_irqs_off():
	      trace_tlb_flush():
	        bpf_trace_run2():
		  stack_map_get_build_id_offset():
		    mmap_read_trylock(): // this is actually ok, because
		    			 // trylock() on rwsem won't
					 // sleep.
		      __mmap_lock_trace_acquire_returned():
		        get_mm_memcg_path():
			  cgroup_path():
			    kernfs_path_from_node():
			      read_lock_irqsave(); // on RT, read_lock()
			      			   // is a rwsem IIUC,
						   // so might sleep.
						   // hence the issue.

Maybe kernfs can use RCU instead of read_lock here? I don't know...

Regards,
Boqun

> [ BUG: Invalid wait context ]
> 6.12.0-rc5-next-20241031-syzkaller #0 Not tainted
> -----------------------------
> strace-static-x/5846 is trying to lock:
> ffffffff8eac8698 (kernfs_rename_lock){....}-{3:3}, at: kernfs_path_from_node+0x92/0xb00 fs/kernfs/dir.c:229
> other info that might help us debug this:
> context-{5:5}
> 3 locks held by strace-static-x/5846:
>  #0: ffff8880b873e598 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2a/0x140 kernel/sched/core.c:598
>  #1: ffffffff8e939f20 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:337 [inline]
>  #1: ffffffff8e939f20 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:849 [inline]
>  #1: ffffffff8e939f20 (rcu_read_lock){....}-{1:3}, at: __bpf_trace_run kernel/trace/bpf_trace.c:2339 [inline]
>  #1: ffffffff8e939f20 (rcu_read_lock){....}-{1:3}, at: bpf_trace_run2+0x1fc/0x540 kernel/trace/bpf_trace.c:2381
>  #2: ffff88802f7129e0 (&mm->mmap_lock){++++}-{4:4}, at: mmap_read_trylock include/linux/mmap_lock.h:208 [inline]
>  #2: ffff88802f7129e0 (&mm->mmap_lock){++++}-{4:4}, at: stack_map_get_build_id_offset+0x431/0x870 kernel/bpf/stackmap.c:157
> 
> [1] Subject: [syzbot] [kernfs?] WARNING: locking bug in kernfs_path_from_node
> https://lore.kernel.org/lkml/67251dc6.050a0220.529b6.015e.GAE@google.com/