3.16.50-rc1 review patch. If anyone has any objections, please let me know.
------------------
From: stephen hemminger <stephen@xxxxxxxxxxxxxxxxxx>
commit 9b4e946ce14e20d7addbfb7d9139e604f9fda107 upstream.
There is a deadlock possible when canceling the link status
delayed work queue. The removal process is run with RTNL held,
and the link status callback is acquring RTNL.
Resolve the issue by using trylock and rescheduling.
If cancel is in process, that block it from happening.
Fixes: 122a5f6410f4 ("staging: hv: use delayed_work for netvsc_send_garp()")
Signed-off-by: Stephen Hemminger <sthemmin@xxxxxxxxxxxxx>
Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
[bwh: Backported to 3.16:
- Move assignment of ndev_ctx before this new use
- LINKCHANGE_INT is not defined; substitute its upstream definition]
Signed-off-by: Ben Hutchings <ben@xxxxxxxxxxxxxxx>
---
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -777,9 +777,14 @@ static void netvsc_link_change(struct wo
struct rndis_device *rdev;
bool notify;
- rtnl_lock();
-
ndev_ctx = container_of(w, struct net_device_context, dwork.work);
+
+ /* if changes are happening, comeback later */
+ if (!rtnl_trylock()) {
+ schedule_delayed_work(&ndev_ctx->dwork, 2 * HZ);
+ return;
+ }
+
net_device = hv_get_drvdata(ndev_ctx->device_ctx);
rdev = net_device->extension;
net = net_device->ndev;