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: <20190226065025.GA2338@nanopsycho.orion>
Date:   Tue, 26 Feb 2019 07:50:25 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
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

Mon, Feb 25, 2019 at 07:31:27PM CET, jakub.kicinski@...ronome.com wrote:
>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

Sure.

>
>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:

Yeah, let's add WARN_ON.


>
>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