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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ