Re: 6.18.13 iwlwifi deadlock allocating cma while work-item is active.

[Johannes Berg <johannes@sipsolutions.net>]

On Mon, 2026-03-02 at 07:26 -0800, Ben Greear wrote:
> 
> > 
> > Was this with lockdep? If so, it complain about anything?
> > 
> > I'm having a hard time seeing why it would deadlock at all when wifi
> > uses  schedule_work() and therefore the system_percpu_wq, and
> > __lru_add_drain_all() flushes lru_add_drain_work on mm_percpu_wq, and
> > lru_add_and_bh_lrus_drain() doesn't really _seem_ to do anything related
> > to RTNL etc.?
> > 
> > I think we need a real explanation here rather than "if I randomly
> > change this, it no longer appears".
> 
> The path where iwlwifi acquires CMA holds rtnl and/or wiphy locks before
> allocating CMA memory, as expected.
> 
> And the CMA allocation path attempts to flush the work queues in
> at least some cases.
> 
> If there is a work item queued that is trying to grab rtnl and/or wiphy lock
> when CMA attempts to flush, then the flush work cannot complete, so it deadlocks.
> 
> Lockdep doesn't warn about this.

It really should, in cases where it can actually happen, I wrote the
code myself for that... Though things have changed since, and the checks
were lost at least once (and re-added), so I suppose it's possible that
they were lost _again_, but the flushing system is far more flexible now
and it's not flushing the same workqueue anyway, so it shouldn't happen.

I stand by what I said before, need to show more precisely what depends
on what, and I'm not going to accept a random kthread into this.

johannes