Skip to content

RFC mm, x86: New special mapping ops

Andy Lutomirski linux-mm lkml 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 RFC Latest6 patches 1 replyIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/6mm: Add a mechanism to track the current address of a special mappinginclude/linux/mm.h include/linux/mm_types.h mm/mmap.c +1 more+34 -30 replies
2/6x86,vdso: Use special mapping tracking for the vdsoarch/x86/ia32/ia32_signal.c arch/x86/include/asm/elf.h arch/x86/include/asm/mmu.h +3 more+74 -390 replies
3/6mm: Add a vm_special_mapping .fault methodinclude/linux/mm_types.h mm/mmap.c+27 -50 replies
4/6mm: Add vm_insert_pfn_protinclude/linux/mm.h mm/memory.c+25 -20 replies
5/6x86,vdso: Use .fault instead of remap_pfn_range for the vvar mappingarch/x86/vdso/vma.c+42 -260 replies
6/6x86,vdso: Use .fault for the vdso text mappingarch/x86/include/asm/vdso.h arch/x86/vdso/vdso2c.h arch/x86/vdso/vma.c+19 -170 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [RFC 0/6] mm, x86: New special mapping ops

This is an attempt to make the core special mapping infrastructure track what arch vdso code needs better than it currently does. It adds:

.start_addr_set: A callback to notify arch code that a special mapping was mremapped. (CRIU does this. Without something like this, it's somewhat broken for 64-bit userspace and completely broken for 32-bit userspace on Intel hardware. Apparently no one has noticed the 64-bit breakage, and no one ever ported CRIU to 32-bit in the first place.)

.fault: Directly fault handling on the vdso. Imagine that! It turns out that storing a list of struct page pointers in the special mapping data is awkward for pretty much everyone and completely precludes mapping things that aren't pages without dirty hacks. (x86 uses dirty hacks for the HPET mapping. See below.)

vm_insert_pfn_prot: The only way to support VMAs with different protections on different pages right now is to either use (io_)remap_pfn_range or to twiddle the ptes directly. This is annoying.

One might ask why anyone would ever want different prot values in the same VMA. It turns out that x86 maps the HPET into the vvar area, and the HPET needs to be uncached.

I think that this kind of trick makes no sense on a COW-able mapping or on any mapping that isn't a pure PFN mapping. The new interface enforces this.

The x86 parts are in here mainly as examples for how the new core interfaces would be used. I don't know of anything wrong with them, but I would not go so far as to pretend that I've tested them adequately.

Andy Lutomirski (6):
mm: Add a mechanism to track the current address of a special mapping x86,vdso: Use special mapping tracking for the vdso
mm: Add a vm_special_mapping .fault method
mm: Add vm_insert_pfn_prot
x86,vdso: Use .fault instead of remap_pfn_range for the vvar mapping x86,vdso: Use .fault for the vdso text mapping

 arch/x86/ia32/ia32_signal.c |  11 ++--
 arch/x86/include/asm/elf.h  |  26 +++-----
 arch/x86/include/asm/mmu.h  |   4 +-
 arch/x86/include/asm/vdso.h |  19 +++++-
 arch/x86/kernel/signal.c    |   9 +--
 arch/x86/vdso/vdso2c.h      |   7 ---
 arch/x86/vdso/vma.c         | 141 +++++++++++++++++++++++++++++++-------------
 include/linux/mm.h          |   5 ++
 include/linux/mm_types.h    |  26 +++++++-
 mm/memory.c                 |  25 +++++++-
 mm/mmap.c                   |  38 +++++++++---
 mm/mremap.c                 |   2 +
 12 files changed, 221 insertions(+), 92 deletions(-)
Signature · 7 lines
1.9.3

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>