netdev - Re: [PATCH] xfrm: export xfrm garbage collector thresholds via sysctl

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20090727.124011.05728493.davem@davemloft.net>
Date:	Mon, 27 Jul 2009 12:40:11 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	nhorman@...driver.com
Cc:	netdev@...r.kernel.org, joe@...l.com, herbert@...dor.apana.org.au,
	kuznet@....inr.ac.ru, pekkas@...core.fi, jmorris@...ei.org,
	yoshfuji@...ux-ipv6.org, kaber@...sh.net
Subject: Re: [PATCH] xfrm: export xfrm garbage collector thresholds via
 sysctl

From: Neil Horman <nhorman@...driver.com>
Date: Mon, 27 Jul 2009 15:36:25 -0400

> I think that makes sense, since it means we only keep cache entries
> for active connections, and clean them up as soon as they close
> (e.g. I don't really see the advantage to unhashing a xfrm cache
> entry only to recreate it on the next packet sent).

How is this related to the user's problem?

My impression was that they were forwarding IPSEC traffic when
running up against these limits, and that has no socket based
assosciation at all.

Making the XFRM GC limits get computed similarly to how the
ipv4/ipv6 one's do probably makes sense.


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