linux-kernel - Re: Memory leaks on atom-based boards?

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]

Date:	Sun, 09 Nov 2014 23:07:23 +0100
From:	Vlastimil Babka <vbabka@...e.cz>
To:	AL13N <alien@...il.be>, linux-kernel@...r.kernel.org
Subject: Re: Memory leaks on atom-based boards?

On 11/09/2014 05:38 PM, AL13N wrote:
>> On 10/27/2014 07:44 PM, AL13N wrote:
>>
>> Hi, this does look like a kernel memory leak. There was recently a known
>> one fixed by patch from https://lkml.org/lkml/2014/10/15/447 which made
>> it to 3.18-rc3 and should be backported to stable kernels 3.8+ soon.
>> You would recognize if this is the fix for you by checking the
>> thp_zero_page_alloc value in /proc/vmstat. Value X > 1 basically means
>> that X*2 MB memory is leaked.
>> You say in the serverfault post that 3.17.2 helped, but the fix is not
>> in 3.17.2... but it could be just that the circumstances changed and THP
>> zero pages are no longer freed and realocated.
>> So if you want to be sure, I would suggest trying again a version where
>> the problem appeared on your system, and checking the
>> thp_zero_page_alloc. Perhaps you'll see a >1 value even on 3.17.2, which
>> means some leak did occur there as well, but maybe not so severe.
> 
> 
> i was gonna tell you guys, but i was waiting until i was sure, but indeed
> 3.17.2 fixed, it, where i had OOM after 3, maybe 4 days (for at least 2
> months), now i'm up more than 4 days and the MemAvailable is still high
> enough... at about 3.5GB whereas otherwise it would dwindle until 0. (at
> about 1GB/day)
> 
> Well, it results to 0 on 3.17.2 ... so... i guess not? i'll keep this
> value under observation...

Hm, 0 sounds like nobody was allocating transparent huge pages at all. What
about the other thp_* stats?

>>>  - How can i find out what is allocating all this memory?
>>
>> There's no simple way, unfortunately. Checking the kpageflags /proc file
>> might help. IIRC there used to be a patch in -mm tree to store who
>> allocated what page, but it might be bitrotten.
> 
> 
> i checked what was in kpageflags (or kpagecount) but it's all some kind of
> binary stuff...
> 
> do i need some tool to interprete these values?

There's tools/vm/page-types.c in kernel sources which can read kpageflags, but
not the kpagecount...

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