From: Eyal Birger <eyal.birger@gmail.com>
To: Florian Westphal <fw@strlen.de>
Cc: Steffen Klassert <steffen.klassert@secunet.com>,
netdev@vger.kernel.org, herbert@gondor.apana.org.au,
davem@davemloft.net, shmulik@metanetworks.com
Subject: Re: xfrm, ip tunnel: non released device reference upon device unregistration
Date: Tue, 6 Feb 2018 21:19:46 +0200 [thread overview]
Message-ID: <20180206211946.217783da@jimi> (raw)
In-Reply-To: <20180206131509.GA14261@breakpoint.cc>
On Tue, 6 Feb 2018 14:15:09 +0100
Florian Westphal <fw@strlen.de> wrote:
> Steffen Klassert <steffen.klassert@secunet.com> wrote:
> > I gave the patch a quick try, but still I get this:
> >
> > unregister_netdevice: waiting for dummy1 to become free. Usage
> > count = 2
>
> Was that with Eyals setup or the bridge one I posted?
>
> If it was Eyals setup, its possible the patch missed hookup
> to whatever tunnel infra is used (the setup I used has ipip tunnel,
> everything is ipv4).
>
Thanks!
Indeed the setup I'm testing uses ip6_tunnel.
I have tested a fix in the spirit of the patch and it looks valid
for ip6_tunnel as well.
It looks though that this change would need to be added to any tunnel
device using dst_cache (vxlan, geneve, gre, ...).
> Also, perhaps it would be best to not bother with checking the
> device in question at all and unconditionally put device reference
> of all the dst_caches. With setups that have e.g. 1k devices going
> down per second (ppp dialin and the like) doing the full search for
> every notify event would be rather expensive.
>
I'm wondering - non-xfrm dsts are already correctly invalidated,
so do you think it makes sense to invalidate caches for devices that
have no xfrm dsts? or maybe I didn't understand the suggestion?
Eyal.
next prev parent reply other threads:[~2018-02-06 19:19 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-04 11:21 xfrm, ip tunnel: non released device reference upon device unregistration Eyal Birger
2018-02-04 13:32 ` Eyal Birger
2018-02-06 8:53 ` Steffen Klassert
2018-02-06 10:32 ` Florian Westphal
2018-02-06 10:42 ` Eyal Birger
2018-02-06 12:56 ` Florian Westphal
2018-02-06 13:09 ` Steffen Klassert
2018-02-06 13:15 ` Florian Westphal
2018-02-06 13:21 ` Steffen Klassert
2018-02-06 19:19 ` Eyal Birger [this message]
2018-02-11 15:46 ` Florian Westphal
2018-02-12 11:54 ` Eyal Birger
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=20180206211946.217783da@jimi \
--to=eyal.birger@gmail.com \
--cc=davem@davemloft.net \
--cc=fw@strlen.de \
--cc=herbert@gondor.apana.org.au \
--cc=netdev@vger.kernel.org \
--cc=shmulik@metanetworks.com \
--cc=steffen.klassert@secunet.com \
/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.