Re: [BUG] mac80211: lockdep warning from key debugfs creation

[Johannes Berg <johannes@sipsolutions.net>]

On Sun, 2026-04-19 at 08:48 +0200, Greg KH wrote:
> > The warning becomes possible because there is already an existing
> > dependency from relay_open_buf()/relay_create_buf_file(): that path
> > holds relay_channels_mutex and then enters the same debugfs/VFS
> > creation flow, which reaches the directory inode lock.

For the record, I have no idea what code path you're talking about here,
perhaps that's hidden away in some driver?

> > With both chains present, lockdep reports the cycle:
> > 
> >   fs_reclaim -> relay_channels_mutex -> inode rwsem -> fs_reclaim
> > 
> > This looks more like a real locking problem than a pure fuzzing
> > artifact. The trigger is a syzkaller-style key creation workload, but
> > the questionable part is that mac80211 performs non-essential debugfs
> > creation inside the locked key installation path.
> > 
> > A possible fix direction would be to avoid creating per-key debugfs
> > entries while still in the locked add-key path, for example by
> > deferring the debugfs population until after the critical section or by
> > moving it to a safer asynchronous context.
> > 
> > Relevant source locations in current trees are:
> > 
> >   net/wireless/nl80211.c: nl80211_pre_doit(), nl80211_new_key()
> >   net/mac80211/key.c: ieee80211_key_link()
> >   net/mac80211/debugfs_key.c: ieee80211_debugfs_key_add()
> >   fs/namei.c: start_dirop()
> > 
> > If useful, I can also send the full report/log pair.
> 
> Why not send a fix for this so you get full credit for it?

Agree, that'd be nice, especially since you can actually reproduce and
therefore test it.

Note though that trying to fix this on the mac80211 side as you suggest
above ("A possible fix direction ...") is not going to work, you'll need
to address this on the other side (that relay thing.)

johannes