From: Jakub Kicinski <kuba@kernel.org>
To: Cosmin Ratiu <cratiu@nvidia.com>
Cc: <linux-wireless@vger.kernel.org>,
Johannes Berg <johannes@sipsolutions.net>,
Tariq Toukan <tariqt@nvidia.com>,
Carolina Jubran <cjubran@nvidia.com>,
Dragos Tatulea <dtatulea@nvidia.com>, <netdev@vger.kernel.org>
Subject: Re: [PATCH wireless v2] wifi: wext: Limit notifier event flushes to the device's netns
Date: Tue, 27 Oct 2026 16:27:10 -0700 [thread overview]
Message-ID: <20261027162710.34e0e17c@kernel.org> (raw)
In-Reply-To: <20261023081044.728500-1-cratiu@nvidia.com>
On Fri, 23 Oct 2026 11:10:44 +0300 Cosmin Ratiu wrote:
> With mlx5 netdev instance locking enabled, registering an IPoIB netdev
> calls the WEXT notifier while holding the instance mutex. Its call to
> wireless_nlevent_flush() takes net_rwsem to walk every namespace,
> completing the following lockdep dependency cycle:
>
> netdev instance mutex -> net_rwsem (read) -> GID table mutex
> -> event_handler_rwsem (read) -> netdev instance mutex
>
> RoCE GID enumeration takes the GID table mutex under net_rwsem. GID
> updates dispatch events under the table mutex, taking event_handler_rwsem.
> The IPoIB event handler takes the netdev instance mutex in
> ipoib_queue_work() to traverse child interfaces.
>
> The all-namespace walk originated in the single global worker servicing
> per-namespace WEXT queues. The ordering fixes later reused that routine
> in netdevice notifiers to prevent delayed WEXT RTM_NEWLINK messages from
> following RTM_DELLINK or reporting stale interface flags. A notifier only
> needs to drain the affected device's namespace; there is no reason for it
> to walk and flush all namespaces.
>
> Pass dev_net(dev) from both notifier callers and make the flush helper
> operate on that namespace. Keep the all-namespace walk and net_rwsem in
> the existing worker. This removes the instance-mutex -> net_rwsem
> dependency while retaining synchronous flushing from the notifiers.
>
> It may seem strange that the fix for a lock cycle across multiple
> subsystems lies in a completely unrelated part of the code, but this
> seemed the most justified lock cycle edge to break.
If Johannes thinks this scoping is good for other reasons - SGTM.
But my knee jerk fix would be to skip all the wifi processing
for ops-locked devices since no wifi device is ops locked.
next prev parent reply other threads:[~2026-10-27 23:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-23 8:10 [PATCH wireless v2] wifi: wext: Limit notifier event flushes to the device's netns Cosmin Ratiu
2026-10-27 23:27 ` Jakub Kicinski [this message]
2026-10-29 7:01 ` 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=20261027162710.34e0e17c@kernel.org \
--to=kuba@kernel.org \
--cc=cjubran@nvidia.com \
--cc=cratiu@nvidia.com \
--cc=dtatulea@nvidia.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=tariqt@nvidia.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.