linux-kernel - Re: mm: pages are not freed from lru_add

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: <20160607111946.GJ12305@dhcp22.suse.cz>
Date:	Tue, 7 Jun 2016 13:19:46 +0200
From:	Michal Hocko <mhocko@...nel.org>
To:	"Odzioba, Lukasz" <lukasz.odzioba@...el.com>
Cc:	"Hansen, Dave" <dave.hansen@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"Shutemov, Kirill" <kirill.shutemov@...el.com>,
	"Anaczkowski, Lukasz" <lukasz.anaczkowski@...el.com>
Subject: Re: mm: pages are not freed from lru_add_pvecs after process
 termination

On Tue 07-06-16 09:02:02, Odzioba, Lukasz wrote:
[...]
> //compile with: gcc bench.c -o bench_2M -fopenmp
> //compile with: gcc -D SMALL_PAGES bench.c -o bench_4K -fopenmp
> #include <stdio.h>
> #include <sys/mman.h>
> #include <omp.h>
> 
> #define MAP_HUGE_SHIFT  26
> #define MAP_HUGE_2MB    (21 << MAP_HUGE_SHIFT)
> 
> #ifndef SMALL_PAGES
> #define PAGE_SIZE (1024*1024*2)
> #define MAP_PARAM (MAP_HUGE_2MB)

Isn't MAP_HUGE_2MB ignored for !hugetlb pages?

> #else
> #define PAGE_SIZE (1024*4)
> #define MAP_PARAM (0)
> #endif
> 
> void main() {
>         size_t size = ((60 * 1000 * 1000) / 288) * 1000; // 60GBs of memory 288 CPUs
>         #pragma omp parallel
>         {
>         unsigned int k;
>         for (k = 0; k < 10; k++) {
>                 void *p = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON | MAP_PARAM, -1, 0);

I guess you want something like posix_memalign or start faulting in from
an aligned address to guarantee you will fault 2MB pages. Also note that
the default behavior for THP during the fault has changed recently (see
444eb2a449ef ("mm: thp: set THP defrag by default to madvise and add a
stall-free defrag option") so you might need MADV_HUGEPAGE.

Besides that I am really suspicious that this will be measurable at all.
I would just go and spin a patch assuming you are still able to trigger
OOM with the vanilla kernel. The bug fix is more important...
-- 
Michal Hocko
SUSE Labs