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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190225103127.4f17f900@cakuba.netronome.com>
Date:   Mon, 25 Feb 2019 10:31:27 -0800
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     davem@...emloft.net, mkubecek@...e.cz, andrew@...n.ch,
        f.fainelli@...il.com, netdev@...r.kernel.org,
        oss-drivers@...ronome.com
Subject: Re: [PATCH net-next v3 5/6] devlink: hold a reference to the
 netdevice around ethtool compat

On Sun, 24 Feb 2019 12:00:03 +0100, Jiri Pirko wrote:
> Fri, Feb 22, 2019 at 11:07:56PM CET, jakub.kicinski@...ronome.com wrote:
> >When ethtool is calling into devlink compat code make sure we have
> >a reference on the netdevice on which the operation was invoked.
> >
> >v3: move the hold/lock logic into devlink_compat_* functions (Florian)
> >
> >Signed-off-by: Jakub Kicinski <jakub.kicinski@...ronome.com>
> >---
> > net/core/devlink.c | 34 +++++++++++++++++++++++-----------
> > net/core/ethtool.c | 13 ++-----------
> > 2 files changed, 25 insertions(+), 22 deletions(-)
> >
> >diff --git a/net/core/devlink.c b/net/core/devlink.c
> >index a13055160be0..78c6ea1870ca 100644
> >--- a/net/core/devlink.c
> >+++ b/net/core/devlink.c
> >@@ -6430,27 +6430,39 @@ void devlink_compat_running_version(struct net_device *dev,
> > {
> > 	struct devlink *devlink;
> > 
> >+	dev_hold(dev);
> >+	rtnl_unlock();  
> 
> Ha, I got it now. You rely on dev_hold to make sure the
> devlink instance does not dissappear. But until this patch, that is not
> guaranteed (or I'm missing it).

Yup, I think the expectation that drivers should free netdevs before
unregistering devlink holds today. But it may be a source of bugs :S

I can add take devlink_mutex, and check the devlink instance is
registered. Do you prefer an explicit ->registered field like port has,
or can I do this:

diff --git a/net/core/devlink.c b/net/core/devlink.c
index cefcc0f45d44..be39ad6a4e2e 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -5275,6 +5275,7 @@ struct devlink *devlink_alloc(const struct devlink_ops *ops, size_t priv_size)
                return NULL;
        devlink->ops = ops;
        devlink_net_set(devlink, &init_net);
+       INIT_LIST_HEAD(&devlink->list);
        INIT_LIST_HEAD(&devlink->port_list);
        INIT_LIST_HEAD(&devlink->sb_list);
        INIT_LIST_HEAD_RCU(&devlink->dpipe_table_list);
@@ -5303,6 +5304,11 @@ int devlink_register(struct devlink *devlink, struct device *dev)
 }
 EXPORT_SYMBOL_GPL(devlink_register);
 
+static bool devlink_is_registered(struct devlink *devlink)
+{
+       return list_empty(&devlink->list);
+}
+
 /**
  *     devlink_unregister - Unregister devlink instance
  *
@@ -5312,7 +5318,7 @@ void devlink_unregister(struct devlink *devlink)
 {
        mutex_lock(&devlink_mutex);
        devlink_notify(devlink, DEVLINK_CMD_DEL);
-       list_del(&devlink->list);
+       list_del_init(&devlink->list);
        mutex_unlock(&devlink_mutex);
 }
 EXPORT_SYMBOL_GPL(devlink_unregister);

?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ