aboutsummaryrefslogtreecommitdiff
path: root/arch/powerpc/kernel/vdso64/datapage.S
diff options
context:
space:
mode:
authorPaul Mackerras <paulus@samba.org>2007-04-03 21:24:02 +1000
committerPaul Mackerras <paulus@samba.org>2007-04-13 03:55:18 +1000
commit721151d004dcf01a71b12bb6b893f9160284cf6e (patch)
tree16105646cae11ad6f785a5756d526b01922bcd7c /arch/powerpc/kernel/vdso64/datapage.S
parent1a38147ed0737a9c01dbf5f2ca47fd2a0aa5cb55 (diff)
[POWERPC] Allow drivers to map individual 4k pages to userspace
Some drivers have resources that they want to be able to map into userspace that are 4k in size. On a kernel configured with 64k pages we currently end up mapping the 4k we want plus another 60k of physical address space, which could contain anything. This can introduce security problems, for example in the case of an infiniband adaptor where the other 60k could contain registers that some other program is using for its communications. This patch adds a new function, remap_4k_pfn, which drivers can use to map a single 4k page to userspace regardless of whether the kernel is using a 4k or a 64k page size. Like remap_pfn_range, it would typically be called in a driver's mmap function. It only maps a single 4k page, which on a 64k page kernel appears replicated 16 times throughout a 64k page. On a 4k page kernel it reduces to a call to remap_pfn_range. The way this works on a 64k kernel is that a new bit, _PAGE_4K_PFN, gets set on the linux PTE. This alters the way that __hash_page_4K computes the real address to put in the HPTE. The RPN field of the linux PTE becomes the 4k RPN directly rather than being interpreted as a 64k RPN. Since the RPN field is 32 bits, this means that physical addresses being mapped with remap_4k_pfn have to be below 2^44, i.e. 0x100000000000. The patch also factors out the code in arch/powerpc/mm/hash_utils_64.c that deals with demoting a process to use 4k pages into one function that gets called in the various different places where we need to do that. There were some discrepancies between exactly what was done in the various places, such as a call to spu_flush_all_slbs in one case but not in others. Signed-off-by: Paul Mackerras <paulus@samba.org>
Diffstat (limited to 'arch/powerpc/kernel/vdso64/datapage.S')
0 files changed, 0 insertions, 0 deletions