linux-kernel - HugePages

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-next>] [day] [month] [year] [list]

Message-ID: <20150408161539.GA29546@sbohrermbp13-local.rgmadvisors.com>
Date:	Wed, 8 Apr 2015 11:15:39 -0500
From:	Shawn Bohrer <shawn.bohrer@...il.com>
To:	linux-mm@...ck.org
Cc:	linux-kernel@...r.kernel.org
Subject: HugePages_Rsvd leak

I've noticed on a number of my systems that after shutting down my
application that uses huge pages that I'm left with some pages still
in HugePages_Rsvd.  It is possible that I still have something using
huge pages that I'm not aware of but so far my attempts to find
anything using huge pages have failed.  I've run some simple tests
using map_hugetlb.c from the kernel source and can see that pages that
have been reserved but not allocated still show up in
/proc/<pid>/smaps and /proc/<pid>/numa_maps.  Are there any cases
where this is not true?

[root@...106 ~]# grep HugePages /proc/meminfo
AnonHugePages:    241664 kB
HugePages_Total:     512
HugePages_Free:      512
HugePages_Rsvd:      384
HugePages_Surp:        0
Hugepagesize:       2048 kB
[root@...106 ~]# grep "KernelPageSize:.*2048" /proc/*/smaps
[root@...106 ~]# grep "VmFlags:.*ht" /proc/*/smaps
[root@...106 ~]# grep huge /proc/*/numa_maps
[root@...106 ~]# grep Huge /proc/meminfo
AnonHugePages:    241664 kB
HugePages_Total:     512
HugePages_Free:      512
HugePages_Rsvd:      384
HugePages_Surp:        0
Hugepagesize:       2048 kB

So here I have 384 pages reserved and I can't find anything that is
using them.  This is on a machine running 3.14.33.  I can possibly try
running a newer kernel if there is a belief that this has been fixed.
I'm also happy to provide more information or try some debug patches
if there are ideas on how to track this down.  I'm not entirely sure
how hard this is to reproduce but nearly every machine I've looked at
is in this state so it must not be too hard.

Thanks,
Shawn
--
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/