From: Wang Zhan <wang.zhan@smartx.com>
To: netdev@vger.kernel.org, Eva Kurchatova <eva.kurchatova@virtuozzo.com>
Cc: Wang Zhan <wang.zhan@smartx.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Sabrina Dubroca <sd@queasysnail.net>,
Cosmin Ratiu <cratiu@nvidia.com>,
Stanislav Fomichev <sdf@fomichev.me>,
linux-kernel@vger.kernel.org,
syzbot+c6c86a1c56b5131f2d97@syzkaller.appspotmail.com
Subject: Re: [PATCH net v2] net: fix self-deadlock when an upper disables a feature of its lower
Date: Wed, 28 Oct 2026 17:27:20 +0800 [thread overview]
Message-ID: <20261028092720.1062867-1-wang.zhan@smartx.com> (raw)
In-Reply-To: <20261027140121.1192299-1-eva.kurchatova@virtuozzo.com>
Hi,
On Tue, 27 Oct 2026 16:00:49 +0200, Eva Kurchatova wrote:
> There is no way to tell whether the current task owns the lower instance
> lock. Try to take it, and otherwise leave the job to netdev_work, which
> disables the features the uppers lack under the lower's instance lock.
We may not need to tell whether the current task owns the lower instance
lock. Instead, we can check whether the device is already in the current
notification chain. netdev_features_change() is always called with RTNL
held, so we can track it with a global feature-change stack, like this:
/* RTNL serialized */
static stack netdev_feature_change_stack;
netdev_features_change(dev):
push(netdev_feature_change_stack, dev)
call_netdevice_notifiers(NETDEV_FEAT_CHANGE, dev)
pop(netdev_feature_change_stack)
netdev_sync_lower_features(upper, lower, ...):
take_ops_lock = !in_stack(netdev_feature_change_stack, lower)
if (take_ops_lock)
netdev_lock_ops(lower)
...
if (take_ops_lock)
netdev_unlock_ops(lower)
> In the deadlock case above, the lock holder is the context that sent
> NETDEV_FEAT_CHANGE, so steal the pending work at the end of
> netdev_features_change() and run it inline, like netif_rx_mode_sync()
> does for rx_mode.
The "otherwise" path takes only the instance lock for ops-locked devices:
netdev_work_proc()
netdev_lock_ops_compat(dev)
but then reaches:
netif_sync_upper_disables()
__netdev_update_features()
ASSERT_RTNL()
ndo_*_features callbacks also require RTNL, so the deferred path cannot
run feature synchronization.
prev parent reply other threads:[~2026-10-28 9:27 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-27 14:00 Eva Kurchatova
2026-10-28 9:27 ` Wang Zhan [this message]
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=20261028092720.1062867-1-wang.zhan@smartx.com \
--to=wang.zhan@smartx.com \
--cc=cratiu@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=eva.kurchatova@virtuozzo.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sd@queasysnail.net \
--cc=sdf@fomichev.me \
--cc=syzbot+c6c86a1c56b5131f2d97@syzkaller.appspotmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®