All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
To: Pravin Shelar <pshelar@ovn.org>
Cc: Greg Rose <gvrose8192@gmail.com>,
	Linux Kernel Network Developers <netdev@vger.kernel.org>,
	ovs dev <dev@openvswitch.org>
Subject: Re: [PATCH net-next v4 08/10] net: openvswitch: fix possible memleak on destroy flow-table
Date: Fri, 18 Oct 2019 11:16:17 +0800	[thread overview]
Message-ID: <CAMDZJNWD=a+EBneEU-qs3pzXSBoOdzidn5cgOKs-y8G0UWvbnA@mail.gmail.com> (raw)
In-Reply-To: <CAOrHB_B5dLuvoTxGpmaMiX9deEk9KjQHacqNKEpzHA2m5YS7jw@mail.gmail.com>

On Fri, Oct 18, 2019 at 6:38 AM Pravin Shelar <pshelar@ovn.org> wrote:
>
> On Wed, Oct 16, 2019 at 5:50 AM <xiangxia.m.yue@gmail.com> wrote:
> >
> > From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> >
> > When we destroy the flow tables which may contain the flow_mask,
> > so release the flow mask struct.
> >
> > Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> > Tested-by: Greg Rose <gvrose8192@gmail.com>
> > ---
> >  net/openvswitch/flow_table.c | 14 +++++++++++++-
> >  1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
> > index 5df5182..d5d768e 100644
> > --- a/net/openvswitch/flow_table.c
> > +++ b/net/openvswitch/flow_table.c
> > @@ -295,6 +295,18 @@ static void table_instance_destroy(struct table_instance *ti,
> >         }
> >  }
> >
> > +static void tbl_mask_array_destroy(struct flow_table *tbl)
> > +{
> > +       struct mask_array *ma = ovsl_dereference(tbl->mask_array);
> > +       int i;
> > +
> > +       /* Free the flow-mask and kfree_rcu the NULL is allowed. */
> > +       for (i = 0; i < ma->max; i++)
> > +               kfree_rcu(rcu_dereference_raw(ma->masks[i]), rcu);
> > +
> > +       kfree_rcu(rcu_dereference_raw(tbl->mask_array), rcu);
> > +}
> > +
> >  /* No need for locking this function is called from RCU callback or
> >   * error path.
> >   */
> > @@ -304,7 +316,7 @@ void ovs_flow_tbl_destroy(struct flow_table *table)
> >         struct table_instance *ufid_ti = rcu_dereference_raw(table->ufid_ti);
> >
> >         free_percpu(table->mask_cache);
> > -       kfree_rcu(rcu_dereference_raw(table->mask_array), rcu);
> > +       tbl_mask_array_destroy(table);
> >         table_instance_destroy(ti, ufid_ti, false);
> >  }
>
> This should not be required. mask is linked to a flow and gets
> released when flow is removed.
> Does the memory leak occur when OVS module is abruptly unloaded and
> userspace does not cleanup flow table?
When we destroy the ovs datapath or net namespace is destroyed , the
mask memory will be happened. The call tree:
ovs_exit_net/ovs_dp_cmd_del
-->__dp_destroy
-->destroy_dp_rcu
-->ovs_flow_tbl_destroy
-->table_instance_destroy (which don't release the mask memory because
don't call the ovs_flow_tbl_remove /flow_mask_remove directly or
indirectly).

but one thing, when we flush the flow, we don't flush the mask flow.(
If necessary, one patch should be sent)

> In that case better fix could be calling ovs_flow_tbl_remove()
> equivalent from table_instance_destroy when it is iterating flow
> table.
I think operation of  the flow mask and flow table should use
different API, for example:
for flow mask, we use the:
-tbl_mask_array_add_mask
-tbl_mask_array_del_mask
-tbl_mask_array_alloc
-tbl_mask_array_realloc
-tbl_mask_array_destroy(this patch introduce.)

table instance:
-table_instance_alloc
-table_instance_destroy
....

  reply	other threads:[~2019-10-18  5:17 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-15 10:30 [PATCH net-next v4 00/10] optimize openvswitch flow looking up xiangxia.m.yue
2019-10-15 10:30 ` [PATCH net-next v4 01/10] net: openvswitch: add flow-mask cache for performance xiangxia.m.yue
2019-10-18 23:29   ` [ovs-dev] " William Tu
2019-10-15 10:30 ` [PATCH net-next v4 02/10] net: openvswitch: convert mask list in mask array xiangxia.m.yue
2019-10-18 23:30   ` [ovs-dev] " William Tu
2019-10-15 10:30 ` [PATCH net-next v4 03/10] net: openvswitch: shrink the mask array if necessary xiangxia.m.yue
2019-10-18 23:33   ` [ovs-dev] " William Tu
2019-10-15 10:30 ` [PATCH net-next v4 04/10] net: openvswitch: optimize flow mask cache hash collision xiangxia.m.yue
2019-10-15 10:30 ` [PATCH net-next v4 05/10] net: openvswitch: optimize flow-mask looking up xiangxia.m.yue
2019-10-18 23:26   ` [ovs-dev] " William Tu
2019-10-21  4:51     ` Tonghao Zhang
2019-10-21 17:58       ` William Tu
2019-10-15 10:30 ` [PATCH net-next v4 06/10] net: openvswitch: simplify the flow_hash xiangxia.m.yue
2019-10-18 23:27   ` [ovs-dev] " William Tu
2019-10-15 10:30 ` [PATCH net-next v4 07/10] net: openvswitch: add likely in flow_lookup xiangxia.m.yue
2019-10-18 23:27   ` [ovs-dev] " William Tu
2019-10-15 10:30 ` [PATCH net-next v4 08/10] net: openvswitch: fix possible memleak on destroy flow-table xiangxia.m.yue
2019-10-17 22:38   ` Pravin Shelar
2019-10-18  3:16     ` Tonghao Zhang [this message]
2019-10-18 18:12       ` Pravin Shelar
2019-10-21  5:01         ` Tonghao Zhang
2019-10-22  6:57           ` Pravin Shelar
2019-10-23  2:35             ` Tonghao Zhang
2019-10-24  7:14               ` Pravin Shelar
2019-10-28  6:49                 ` Tonghao Zhang
2019-10-29  7:37                   ` Pravin Shelar
2019-10-29 11:30                     ` Tonghao Zhang
2019-10-29 20:27                       ` Pravin Shelar
2019-10-15 10:30 ` [PATCH net-next v4 09/10] net: openvswitch: don't unlock mutex when changing the user_features fails xiangxia.m.yue
2019-10-18 23:27   ` [ovs-dev] " William Tu
2019-10-15 10:30 ` [PATCH net-next v4 10/10] net: openvswitch: simplify the ovs_dp_cmd_new xiangxia.m.yue
2019-10-18 23:29   ` [ovs-dev] " William Tu
2019-10-17 19:22 ` [PATCH net-next v4 00/10] optimize openvswitch flow looking up David Miller
2019-10-17 20:29   ` Gregory Rose
2019-10-21 17:14 ` [ovs-dev] " William Tu
2019-10-22  1:16   ` Tonghao Zhang
2019-10-22 15:44     ` William Tu

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='CAMDZJNWD=a+EBneEU-qs3pzXSBoOdzidn5cgOKs-y8G0UWvbnA@mail.gmail.com' \
    --to=xiangxia.m.yue@gmail.com \
    --cc=dev@openvswitch.org \
    --cc=gvrose8192@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pshelar@ovn.org \
    /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.