netdev - Re: [PATCH 2/3] xfrm: Increase the garbage collector threshold

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]

Message-ID: <20131216115145.GH31491@secunet.com>
Date:	Mon, 16 Dec 2013 12:51:45 +0100
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	Maxime Bizon <mbizon@...ebox.fr>
Cc:	David Miller <davem@...emloft.net>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	netdev@...r.kernel.org
Subject: Re: [PATCH 2/3] xfrm: Increase the garbage collector threshold

On Fri, Dec 13, 2013 at 05:13:29PM +0100, Maxime Bizon wrote:
> 
> On Fri, 2013-12-13 at 11:12 +0100, Steffen Klassert wrote:
> 
> > Can you please be a bit more precise with your problem description?
> 
> yes sorry I wasn't clear.
> 
> I have a problem with an even simpler workload that the one using apache
> bench in the original bug report.
> 
> I am using ipsec transport mode between two hosts and just run this on
> one side:
> 
>   while :; do wget -O /dev/null http://remote_host/; done
> 
> I was surprised to see it fails after only 1024 requests (ENOBUF on
> connect), and how long I had to wait to be able to do new requests.
> 
> After debugging I saw that the xfrm gc was called but was not able to
> release anything.
> 
> after running "ip route flush cache", which forces all ipv4 dst entries
> to be released, suddenly the xfrm gc had something to free, and xfrm
> entry count went to zero.

Well, "ip route flush cache" bumps the rt_genid what marks all
routes as invalid. The xfrm garbage collector will notice this
on the next run and deletes all invalid cached routes.

Garbage collecting is different from flushing, it only removes
stale routes and keeps everything that was used recently. That's
the whole point of this caching, we cache recently used IPsec
routes to avoid a slow path lookup.

> 
> So if it is correct that once a ipv4 dst entry exists, the xfrm entry
> cannot be gc-ed, then we need to make sure we allow more xfrm entries to
> be allocated than ipv4 dst.

No, we don't cache plain ipv4 routes, we cache only IPsec routes.
The original ipv4 dst_entry is cached together with the xfrm dst_entry
as a xfrm bundle at the IPsec flow cache, so it does not make sense to
ensure something like that.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html