linux-kernel - Re: dst cache overflow

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]

Date:	Sat, 15 Dec 2007 14:29:37 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	ranma+kernel@...edrich.de (Tobias Diedrich)
Cc:	linux-net@...r.kernel.org, linux-kernel@...r.kernel.org,
	dada1@...mosbay.com
Subject: Re: dst cache overflow

Tobias Diedrich <ranma+kernel@...edrich.de> wrote:
>
> Meanwhile I added a slab statistic rrd script. Nothing obvious to
> see on ari or yumi yet, but on oni (which after all is the most
> affected by this) I can see 'size_2048' and 'TCPv6' growing
> steadily along with the route cache size (Presumably 'ip_dst_cache',
> which is also growing larger at a more or less constant rate).

OK that almost certainly means that we have a leak of TCPv6
objects which would then cause a leak of dst objects.

So you need to track down why TCPv6 isn't getting cleaned up.
First check the obvious, do you have any process(es) that are
hoarding TCPv6 sockets?

If not do you see a growing list of dead sockets in netstat?

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/