linux-kernel - Re: anon_vma accumulating for certain load still not addressed

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: <54661A8C.5050806@redhat.com>
Date:	Fri, 14 Nov 2014 10:06:52 -0500
From:	Rik van Riel <riel@...hat.com>
To:	Michal Hocko <mhocko@...e.cz>, linux-mm@...ck.org
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Hugh Dickins <hughd@...gle.com>,
	Michel Lespinasse <walken@...gle.com>,
	Andrea Argangeli <andrea@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Vlastimil Babka <vbabka@...e.cz>,
	Daniel Forrest <dan.forrest@...c.wisc.edu>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: anon_vma accumulating for certain load still not addressed

On 11/14/2014 08:08 AM, Michal Hocko wrote:
> Hi,
> back in 2012 [1] there was a discussion about a forking load which
> accumulates anon_vmas. There was a trivial test case which triggers this
> and can potentially deplete the memory by local user.
>
> We have a report for an older enterprise distribution where nsd is
> suffering from this issue most probably (I haven't debugged it throughly
> but accumulating anon_vma structs over time sounds like a good enough
> fit) and has to be restarted after some time to release the accumulated
> anon_vma objects.
>
> There was a patch which tried to work around the issue [2] but I do not
> see any follow ups nor any indication that the issue would be addressed
> in other way.
>
> The test program from [1] was running for around 39 mins on my laptop
> and here is the result:
>
> $ date +%s; grep anon_vma /proc/slabinfo
> 1415960225
> anon_vma           11664  11900    160   25    1 : tunables    0    0    0 : slabdata    476    476      0
>
> $ ./a # The reproducer
>
> $ date +%s; grep anon_vma /proc/slabinfo
> 1415962592
> anon_vma           34875  34875    160   25    1 : tunables    0    0    0 : slabdata   1395   1395      0
>
> $ killall a
> $ date +%s; grep anon_vma /proc/slabinfo
> 1415962607
> anon_vma           11277  12175    160   25    1 : tunables    0    0    0 : slabdata    487    487      0
>
> So we have accumulated 23211 objects over that time period before the
> offender was killed which released all of them.
>
> The proposed workaround is kind of ugly but do people have a better idea
> than reference counting? If not should we merge it?

I believe we should just merge that patch.

I have not seen any better ideas come by.

The comment should probably be fixed to reflect the
chain length of 5 though :)

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