]> git.karo-electronics.de Git - karo-tx-linux.git/commit
hugetlb: ensure hugepage access is denied if hugepages are not supported
authorNishanth Aravamudan <nacc@linux.vnet.ibm.com>
Thu, 24 Apr 2014 22:55:24 +0000 (08:55 +1000)
committerStephen Rothwell <sfr@canb.auug.org.au>
Thu, 24 Apr 2014 22:55:24 +0000 (08:55 +1000)
commitc5741d94d4f3ffc1570afb2bfcd210d7032ed3ab
tree56ac00a7799a65eea13f8d822b95f4acd1d017f9
parent0b17d56b5840bb596c5be7fdccc366feddbc4f8a
hugetlb: ensure hugepage access is denied if hugepages are not supported

Currently, I am seeing the following when I `mount -t hugetlbfs /none
/dev/hugetlbfs`, and then simply do a `ls /dev/hugetlbfs`.  I think it's
related to the fact that hugetlbfs is properly not correctly setting
itself up in this state?:

Unable to handle kernel paging request for data at address 0x00000031
Faulting instruction address: 0xc000000000245710
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=2048 NUMA pSeries
....

In KVM guests on Power, in a guest not backed by hugepages, we see the
following:

AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:         64 kB

HPAGE_SHIFT == 0 in this configuration, which indicates that hugepages
are not supported at boot-time, but this is only checked in
hugetlb_init(). Extract the check to a helper function, and use it in a
few relevant places.

This does make hugetlbfs not supported (not registered at all) in this
environment. I believe this is fine, as there are no valid hugepages and
that won't change at runtime.

Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
fs/hugetlbfs/inode.c
include/linux/hugetlb.h
mm/hugetlb.c