From: Ben Greear <greearb@candelatech.com>
To: Johannes Berg <johannes@sipsolutions.net>,
linux-wireless <linux-wireless@vger.kernel.org>
Cc: "Korenblit, Miriam Rachel" <miriam.rachel.korenblit@intel.com>,
linux-mm@kvack.org
Subject: Re: 6.18.13 iwlwifi deadlock allocating cma while work-item is active.
Date: Mon, 2 Mar 2026 07:26:06 -0800 [thread overview]
Message-ID: <0de6c8d1-d2fa-44ac-8025-cfcfecd87b02@candelatech.com> (raw)
In-Reply-To: <3456b2c89f057900b39ce79ea8ca1154c5014e43.camel@sipsolutions.net>
On 3/2/26 00:07, Johannes Berg wrote:
> 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".
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.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2026-03-02 15:26 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-23 22:36 6.18.13 iwlwifi deadlock allocating cma while work-item is active Ben Greear
2026-02-27 16:31 ` Ben Greear
2026-03-01 15:38 ` Ben Greear
2026-03-02 8:07 ` Johannes Berg
2026-03-02 15:26 ` Ben Greear [this message]
2026-03-02 15:38 ` Johannes Berg
2026-03-02 15:50 ` Ben Greear
2026-03-03 11:49 ` Johannes Berg
2026-03-03 20:52 ` Tejun Heo
2026-03-03 21:03 ` Johannes Berg
2026-03-03 21:12 ` Johannes Berg
2026-03-03 21:40 ` Ben Greear
2026-03-03 21:54 ` Tejun Heo
2026-03-04 0:02 ` Ben Greear
2026-03-04 17:14 ` Tejun Heo
2026-03-04 17:14 ` Tejun Heo
2026-03-10 16:10 ` Ben Greear
2026-03-10 18:06 ` Tejun Heo
2026-03-10 19:18 ` Ben Greear
2026-03-10 19:47 ` Tejun Heo
2026-03-10 19:48 ` Tejun Heo
2026-03-04 3:08 ` Hillf Danton
2026-03-04 6:57 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0de6c8d1-d2fa-44ac-8025-cfcfecd87b02@candelatech.com \
--to=greearb@candelatech.com \
--cc=johannes@sipsolutions.net \
--cc=linux-mm@kvack.org \
--cc=linux-wireless@vger.kernel.org \
--cc=miriam.rachel.korenblit@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.