netdev - Re: Memory leak in ip_dst

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: <1315798710.96027.YahooMailNeo@web113913.mail.gq1.yahoo.com>
Date:	Sun, 11 Sep 2011 20:38:30 -0700 (PDT)
From:	Kumar S <ps2kumar@...oo.com>
To:	Neil Horman <nhorman@...driver.com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	netdev <netdev@...r.kernel.org>
Subject: Re: Memory leak in ip_dst_cache

Thanks Neil. I did try with prink(). I do see entries getting aged out, but they are not getting deallocated. This seems to be happening because of "ref_cnt". When the route entries are added the ref_cnt is set to 1. Looks this is causing trouble clearing the entries completely. If I set the ref_cnt to 0, I can see it working. Now I'm trying to understand whether this is right. Please let me know if you have any thoughts on it.

----- Original Message -----
From: Neil Horman <nhorman@...driver.com>
To: Kumar S <ps2kumar@...oo.com>
Cc: Eric Dumazet <eric.dumazet@...il.com>; netdev <netdev@...r.kernel.org>
Sent: Saturday, September 10, 2011 6:04 AM
Subject: Re: Memory leak in ip_dst_cache

On Fri, Sep 09, 2011 at 03:53:45PM -0700, Kumar S wrote:
> Yes Eric, this command doesn't work on 2.6.24. Which timer are you suspecting?
> 
He means that the timer that starts the the workqueue which calls dst_gc_task is
either delayed indefinately, or otherwise not run, which means that the route
cache will never be scanned for old entries.  The implication being that, while
the dst entries aren't leaked per-se, but never expired, so they just sit
around.  You can check this by instrumenting gc_dst_task with a printk or two
and watch to see if it ever pops up.

If you only have 512Mb of ram and want to really restrict you're cache size, you
should definately consider backporting the route cache rebuild patch to disable
the route cache usage entirely.  It shouldn't be too hard to do.
Neil

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

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