From: Paolo Abeni <pabeni@redhat.com>
To: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: netdev@vger.kernel.org, Pravin Shelar <pshelar@nicira.com>,
Thomas Graf <tgraf@suug.ch>
Subject: Re: [PATCH net v2] openvswitch: properly refcount vport-vxlan module
Date: Tue, 01 Dec 2015 14:19:15 +0100 [thread overview]
Message-ID: <1448975955.4459.4.camel@redhat.com> (raw)
In-Reply-To: <1448971437.3330290.454583417.56E794A4@webmail.messagingengine.com>
On Tue, 2015-12-01 at 13:03 +0100, Hannes Frederic Sowa wrote:
> Hello Paolo,
>
> On Mon, Nov 30, 2015, at 12:31, Paolo Abeni wrote:
> > After 614732eaa12d, no refcount is maintained for the vport-vxlan module.
> > This allows the userspace to remove such module while vport-vxlan
> > devices still exist, which leads to later oops.
> >
> > v1 -> v2:
> > - move vport 'owner' initialization in ovs_vport_ops_register()
> > and make such function a macro
> >
> > Fixes: 614732eaa12d ("openvswitch: Use regular VXLAN net_device device")
> > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> > ---
> > net/openvswitch/vport-geneve.c | 1 -
> > net/openvswitch/vport-gre.c | 1 -
> > net/openvswitch/vport.c | 4 ++--
> > net/openvswitch/vport.h | 8 +++++++-
> > 4 files changed, 9 insertions(+), 5 deletions(-)
> >
> > diff --git a/net/openvswitch/vport-geneve.c
> > b/net/openvswitch/vport-geneve.c
> > index efb736b..e41cd12 100644
> > --- a/net/openvswitch/vport-geneve.c
> > +++ b/net/openvswitch/vport-geneve.c
> > @@ -117,7 +117,6 @@ static struct vport_ops ovs_geneve_vport_ops = {
> > .destroy = ovs_netdev_tunnel_destroy,
> > .get_options = geneve_get_options,
> > .send = dev_queue_xmit,
> > - .owner = THIS_MODULE,
> > };
> >
> > static int __init ovs_geneve_tnl_init(void)
> > diff --git a/net/openvswitch/vport-gre.c b/net/openvswitch/vport-gre.c
> > index c3257d7..7f8897f 100644
> > --- a/net/openvswitch/vport-gre.c
> > +++ b/net/openvswitch/vport-gre.c
> > @@ -89,7 +89,6 @@ static struct vport_ops ovs_gre_vport_ops = {
> > .create = gre_create,
> > .send = dev_queue_xmit,
> > .destroy = ovs_netdev_tunnel_destroy,
> > - .owner = THIS_MODULE,
> > };
> >
> > static int __init ovs_gre_tnl_init(void)
> > diff --git a/net/openvswitch/vport.c b/net/openvswitch/vport.c
> > index e194c10a..31cbc8c 100644
> > --- a/net/openvswitch/vport.c
> > +++ b/net/openvswitch/vport.c
> > @@ -71,7 +71,7 @@ static struct hlist_head *hash_bucket(const struct net
> > *net, const char *name)
> > return &dev_table[hash & (VPORT_HASH_BUCKETS - 1)];
> > }
> >
> > -int ovs_vport_ops_register(struct vport_ops *ops)
> > +int __ovs_vport_ops_register(struct vport_ops *ops)
> > {
> > int err = -EEXIST;
> > struct vport_ops *o;
> > @@ -87,7 +87,7 @@ errout:
> > ovs_unlock();
> > return err;
> > }
> > -EXPORT_SYMBOL_GPL(ovs_vport_ops_register);
> > +EXPORT_SYMBOL_GPL(__ovs_vport_ops_register);
> >
> > void ovs_vport_ops_unregister(struct vport_ops *ops)
> > {
> > diff --git a/net/openvswitch/vport.h b/net/openvswitch/vport.h
> > index bdfd82a..8ea3a96 100644
> > --- a/net/openvswitch/vport.h
> > +++ b/net/openvswitch/vport.h
> > @@ -196,7 +196,13 @@ static inline const char *ovs_vport_name(struct
> > vport *vport)
> > return vport->dev->name;
> > }
> >
> > -int ovs_vport_ops_register(struct vport_ops *ops);
> > +int __ovs_vport_ops_register(struct vport_ops *ops);
> > +#define ovs_vport_ops_register(ops) \
> > + ({ \
> > + (ops)->owner = THIS_MODULE; \
> > + __ovs_vport_ops_register(ops); \
> > + })
> > +
> > void ovs_vport_ops_unregister(struct vport_ops *ops);
>
> This doesn't look correct (the fault is not your patch).
>
> The register function adds the list_head of the ops struct on a list
> without increasing the module reference counter. Thus the module could
> be removed and the list walk would walk across the unloaded data section
> left over by the module. Does a kmemdup make sense here and a later free
> in the unregister function? We test type first and then only touch
> functions after getting module refcnt, so it would appear safe to me
> then.
Currently all the vport_ops list manipulation functions are protected by
the ovs_lock (even the lookup): the scenario described above should not
be possible.
Paolo
next prev parent reply other threads:[~2015-12-01 13:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-30 11:31 [PATCH net v2] openvswitch: properly refcount vport-vxlan module Paolo Abeni
2015-12-01 12:03 ` Hannes Frederic Sowa
2015-12-01 13:19 ` Paolo Abeni [this message]
2015-12-01 15:41 ` Hannes Frederic Sowa
2015-12-01 19:26 ` David Miller
2015-12-01 21:10 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1448975955.4459.4.camel@redhat.com \
--to=pabeni@redhat.com \
--cc=hannes@stressinduktion.org \
--cc=netdev@vger.kernel.org \
--cc=pshelar@nicira.com \
--cc=tgraf@suug.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.