netdev - Re: xfrm, ip tunnel: non released device reference upon device unregistration

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]

Date:   Tue, 6 Feb 2018 21:19:46 +0200
From:   Eyal Birger <eyal.birger@...il.com>
To:     Florian Westphal <fw@...len.de>
Cc:     Steffen Klassert <steffen.klassert@...unet.com>,
        netdev@...r.kernel.org, herbert@...dor.apana.org.au,
        davem@...emloft.net, shmulik@...anetworks.com
Subject: Re: xfrm, ip tunnel: non released device reference upon device
 unregistration

On Tue, 6 Feb 2018 14:15:09 +0100
Florian Westphal <fw@...len.de> wrote:

> Steffen Klassert <steffen.klassert@...unet.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.