Thread (11 messages) 11 messages, 2 authors, 2019-02-22

Re: [PATCH net-next v2 2/5] ethtool: hold a reference to the netdevice around devlink compat

From: Jakub Kicinski <hidden>
Date: 2019-02-22 21:20:31

On Fri, 22 Feb 2019 12:09:32 -0800, Florian Fainelli wrote:
On 2/22/19 11:54 AM, Jakub Kicinski wrote:
quoted
When calling into devlink compat code make sure we have a reference
on the netdevice on which the operation was invoked.

Signed-off-by: Jakub Kicinski <redacted>
---
 net/core/ethtool.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 1320e8dce559..6832476dfcaf 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -805,11 +805,14 @@ static noinline_for_stack int ethtool_get_drvinfo(struct net_device *dev,
 	if (ops->get_eeprom_len)
 		info.eedump_len = ops->get_eeprom_len(dev);
 
-	rtnl_unlock();
-	if (!info.fw_version[0])
+	if (!info.fw_version[0]) {
+		dev_hold(dev);
+		rtnl_unlock();
 		devlink_compat_running_version(dev, info.fw_version,
 					       sizeof(info.fw_version));
-	rtnl_lock();
+		rtnl_lock();
+		dev_put(dev);
+	}  
Would it make sense to make the locking and reference holding implicit
within the compat versions of devlink_* because they use a net_device ->
devlink object manipulation as opposed to doing in the caller. We are
more or less guaranteed that the compatibility layer is used from within
ethtool.
I guess we can, in general it feels wrong to call some devlink_
function with rtnl_lock held, but I guess devlink_compat_ can be
special in this regard.  v3 coming up.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help