[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180216094655.ril7k3nmbfbxs7le@gauss3.secunet.de>
Date: Fri, 16 Feb 2018 10:46:55 +0100
From: Steffen Klassert <steffen.klassert@...unet.com>
To: David Miller <davem@...emloft.net>
CC: <lucien.xin@...il.com>, <netdev@...r.kernel.org>, <fw@...len.de>,
<eyal.birger@...il.com>, <herbert@...dor.apana.org.au>,
<weiwan@...gle.com>, <shannon.nelson@...cle.com>,
<shmulik@...anetworks.com>
Subject: Re: [PATCH net] xfrm: reuse uncached_list to track xdsts
On Thu, Feb 15, 2018 at 03:31:45PM -0500, David Miller wrote:
> From: Xin Long <lucien.xin@...il.com>
> Date: Wed, 14 Feb 2018 19:06:02 +0800
>
> > In early time, when freeing a xdst, it would be inserted into
> > dst_garbage.list first. Then if it's refcnt was still held
> > somewhere, later it would be put into dst_busy_list in
> > dst_gc_task().
> >
> > When one dev was being unregistered, the dev of these dsts in
> > dst_busy_list would be set with loopback_dev and put this dev.
> > So that this dev's removal wouldn't get blocked, and avoid the
> > kmsg warning:
> >
> > kernel:unregister_netdevice: waiting for veth0 to become \
> > free. Usage count = 2
> >
> > However after Commit 52df157f17e5 ("xfrm: take refcnt of dst
> > when creating struct xfrm_dst bundle"), the xdst will not be
> > freed with dst gc, and this warning happens.
> >
> > To fix it, we need to find these xdsts that are still held by
> > others when removing the dev, and free xdst's dev and set it
> > with loopback_dev.
> >
> > But unfortunately after flow_cache for xfrm was deleted, no
> > list tracks them anymore. So we need to save these xdsts
> > somewhere to release the xdst's dev later.
> >
> > To make this easier, this patch is to reuse uncached_list to
> > track xdsts, so that the dev refcnt can be released in the
> > event NETDEV_UNREGISTER process of fib_netdev_notifier.
> >
> > Thanks to Florian, we could move forward this fix quickly.
> >
> > Fixes: 52df157f17e5 ("xfrm: take refcnt of dst when creating struct xfrm_dst bundle")
> > Reported-by: Jianlin Shi <jishi@...hat.com>
> > Reported-by: Hangbin Liu <liuhangbin@...il.com>
> > Tested-by: Eyal Birger <eyal.birger@...il.com>
> > Signed-off-by: Xin Long <lucien.xin@...il.com>
>
> Steffen, I assume you will take this via your ipsec tree?
Yes, this is applied to the ipsec tree now.
Thanks a lot everyone!
Powered by blists - more mailing lists