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: <1386951209.25449.61.camel@sakura.staff.proxad.net>
Date:	Fri, 13 Dec 2013 17:13:29 +0100
From:	Maxime Bizon <mbizon@...ebox.fr>
To:	Steffen Klassert <steffen.klassert@...unet.com>
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, 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.

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.

> This patch changes only the number of cache entries before
> we start garbage collecting. It does not change anything
> on the garbage collector itself.

Yes my point was that it just hides another underlying problem.

-- 
Maxime

--
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