diff options
author | Andrea Arcangeli <aarcange@redhat.com> | 2013-07-25 03:04:38 +0200 |
---|---|---|
committer | Gleb Natapov <gleb@redhat.com> | 2013-08-27 11:01:10 +0300 |
commit | 11feeb498086a3a5907b8148bdf1786a9b18fc55 (patch) | |
tree | 9dcef9a577fd410f84f42b972e2fd4e1ff46f68c /net/sysctl_net.c | |
parent | 0bd50dc971aad3c29043de4fb7bce45c351d1b67 (diff) | |
download | op-kernel-dev-11feeb498086a3a5907b8148bdf1786a9b18fc55.zip op-kernel-dev-11feeb498086a3a5907b8148bdf1786a9b18fc55.tar.gz |
kvm: optimize away THP checks in kvm_is_mmio_pfn()
The checks on PG_reserved in the page structure on head and tail pages
aren't necessary because split_huge_page wouldn't transfer the
PG_reserved bit from head to tail anyway.
This was a forward-thinking check done in the case PageReserved was
set by a driver-owned page mapped in userland with something like
remap_pfn_range in a VM_PFNMAP region, but using hugepmds (not
possible right now). It was meant to be very safe, but it's overkill
as it's unlikely split_huge_page could ever run without the driver
noticing and tearing down the hugepage itself.
And if a driver in the future will really want to map a reserved
hugepage in userland using an huge pmd it should simply take care of
marking all subpages reserved too to keep KVM safe. This of course
would require such a hypothetical driver to tear down the huge pmd
itself and splitting the hugepage itself, instead of relaying on
split_huge_page, but that sounds very reasonable, especially
considering split_huge_page wouldn't currently transfer the reserved
bit anyway.
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Diffstat (limited to 'net/sysctl_net.c')
0 files changed, 0 insertions, 0 deletions