From: ALOK TIWARI <alok.a.tiwari@oracle.com>
To: Saurabh Sengar <ssengar@linux.microsoft.com>,
kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, andrew+netdev@lunn.ch, davem@davemloft.net,
edumazet@google.com, pabeni@redhat.com, horms@kernel.org,
ast@kernel.org, daniel@iogearbox.net, hawk@kernel.org,
john.fastabend@gmail.com, sdf@fomichev.me, kuniyu@amazon.com,
ahmed.zaki@intel.com, aleksander.lobakin@intel.com,
linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, bpf@vger.kernel.org
Cc: ssengar@microsoft.com, stable@vger.kernel.org
Subject: Re: [PATCH net] hv_netvsc: fix potential deadlock in netvsc_vf_setxdp()
Date: Mon, 19 May 2025 02:40:23 +0530 [thread overview]
Message-ID: <7549d1fa-dc76-477a-95b4-edfc09085fd2@oracle.com> (raw)
In-Reply-To: <1747540070-11086-1-git-send-email-ssengar@linux.microsoft.com>
On 18-05-2025 09:17, Saurabh Sengar wrote:
> The MANA driver's probe registers netdevice via the following call chain:
>
> mana_probe()
> register_netdev()
> register_netdevice()
>
> register_netdevice() calls notifier callback for netvsc driver,
> holding the netdev mutex via netdev_lock_ops().
>
> Further this netvsc notifier callback end up attempting to acquire the
> same lock again in dev_xdp_propagate() leading to deadlock.
>
> netvsc_netdev_event()
> netvsc_vf_setxdp()
> dev_xdp_propagate()
>
> This deadlock was not observed so far because net_shaper_ops was never
> set and this lock in noop in this case. Fix this by using
> netif_xdp_propagate instead of dev_xdp_propagate to avoid recursive
> locking in this path.
>
> This issue has not observed so far because net_shaper_ops was unset,
> making the lock path effectively a no-op. To prevent recursive locking
> and avoid this deadlock, replace dev_xdp_propagate() with
> netif_xdp_propagate(), which does not acquire the lock again.
avoid noop and repetition (because the paragraph about net_shaper_ops is
repeated):
"This deadlock was not observed so far because net_shaper_ops was never
set, and thus the lock was effectively a no-op in this case. Fix this by
using netif_xdp_propagate() instead of dev_xdp_propagate() to avoid
recursive locking in this path.
Also, clean up the unregistration path by removing the unnecessary call
to netvsc_vf_setxdp(), since unregister_netdevice_many_notify() already
performs this cleanup via dev_xdp_uninstall()."
>
> Also, clean up the unregistration path by removing unnecessary call to
> netvsc_vf_setxdp(), since unregister_netdevice_many_notify() already
> performs this cleanup via dev_xdp_uninstall.
>
> Fixes: 97246d6d21c2 ("net: hold netdev instance lock during ndo_bpf")
> Cc: stable@vger.kernel.org
> Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com>
> ---
> drivers/net/hyperv/netvsc_bpf.c | 2 +-
> drivers/net/hyperv/netvsc_drv.c | 2 --
> net/core/dev.c | 1 +
> 3 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/hyperv/netvsc_bpf.c b/drivers/net/hyperv/netvsc_bpf.c
> index e01c5997a551..1dd3755d9e6d 100644
> --- a/drivers/net/hyperv/netvsc_bpf.c
> +++ b/drivers/net/hyperv/netvsc_bpf.c
> @@ -183,7 +183,7 @@ int netvsc_vf_setxdp(struct net_device *vf_netdev, struct bpf_prog *prog)
Thanks,
Alok
next prev parent reply other threads:[~2025-05-18 21:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-18 3:47 [PATCH net] hv_netvsc: fix potential deadlock in netvsc_vf_setxdp() Saurabh Sengar
2025-05-18 16:23 ` Haiyang Zhang
2025-05-18 21:10 ` ALOK TIWARI [this message]
2025-05-21 8:41 ` Erni Sri Satya Vennela
-- strict thread matches above, loose matches on Subject: below --
2025-05-18 3:46 Saurabh Sengar
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=7549d1fa-dc76-477a-95b4-edfc09085fd2@oracle.com \
--to=alok.a.tiwari@oracle.com \
--cc=ahmed.zaki@intel.com \
--cc=aleksander.lobakin@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=decui@microsoft.com \
--cc=edumazet@google.com \
--cc=haiyangz@microsoft.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=kuniyu@amazon.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=ssengar@linux.microsoft.com \
--cc=ssengar@microsoft.com \
--cc=stable@vger.kernel.org \
--cc=wei.liu@kernel.org \
/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.