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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 22 Feb 2019 13:20:23 -0800
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     davem@...emloft.net, jiri@...nulli.us, mkubecek@...e.cz,
        andrew@...n.ch, netdev@...r.kernel.org, oss-drivers@...ronome.com
Subject: Re: [PATCH net-next v2 2/5] ethtool: hold a reference to the
 netdevice around devlink compat

On Fri, 22 Feb 2019 12:09:32 -0800, Florian Fainelli wrote:
> On 2/22/19 11:54 AM, Jakub Kicinski wrote:
> > 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 <jakub.kicinski@...ronome.com>
> > ---
> >  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.