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

[Johannes Berg <johannes@sipsolutions.net>]

On Sun, 2026-03-01 at 07:38 -0800, Ben Greear wrote:
> On 2/27/26 08:31, Ben Greear wrote:
> > On 2/23/26 14:36, Ben Greear wrote:
> > > Hello,
> > > 
> > > I hit a deadlock related to CMA mem allocation attempting to flush all work
> > > while holding some wifi related mutex, and with a work-queue attempting to process a wifi regdomain
> > > work item.  I really don't see any good way to fix this,
> > > it would seem that any code that was holding a mutex that could block a work-queue
> > > cannot safely allocate CMA memory?  Hopefully someone else has a better idea.
> > 
> > I tried using a kthread to do the regulatory domain processing instead of worker item,
> > and that seems to have solved the problem.  If that seems reasonable approach to
> > wifi stack folks, I can post a patch.
> 
> The other net/wireless work-item 'disconnect_work' also needs to be moved to the kthread
> for the same reason....

I don't think we want to use a kthread for this, it doesn't really make
sense.

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".

johannes