On Fri, Sep 30, 2022, at 3:19 PM, Michael Ellerman wrote:
"Arnd Bergmann" [off-list ref] writes:
quoted
While sys_mmap_pgoff() was meant to replace the various sys_mmap2()
implementations, I think it was ultimately a mistake, and we later
converged on the sys_mmap2() calling conventions with 12 bits
offset for almost all 32-bit architectures.
I only see 3 compat mmap2s:
$ gg "COMPAT_SYSCALL.*mmap2"
arch/arm64/kernel/sys32.c:COMPAT_SYSCALL_DEFINE6(aarch32_mmap2,
unsigned long, addr, unsigned long, len,
arch/powerpc/kernel/syscalls.c:COMPAT_SYSCALL_DEFINE6(mmap2, unsigned
long, addr, size_t, len,
arch/s390/kernel/compat_linux.c:COMPAT_SYSCALL_DEFINE1(s390_mmap2,
struct mmap_arg_struct_emu31 __user *, arg)
They are all inconsistently named, and some are shared with the 64-bit
implementation on architectures that provide mmap2 for both 32-bit
and 64-bit mode, rather than only for 32-bit.
arch/mips/kernel/syscall.c:SYSCALL_DEFINE6(mips_mmap2, unsigned long, addr, unsigned long, len,
arch/sparc/kernel/sys32.S: .globl sys32_mmap2
arch/parisc/kernel/sys_parisc.c:asmlinkage unsigned long sys_mmap2(unsigned long addr, unsigned long len,
s390 is weird.
Right, they used to be limited to 5 register arguments
The arm64 one and ours are similar, but we have the additional call to
arch_validate_prot(prot, addr). arm64 does implement arch_validate_prot().
Similar with mmap2, we call arch_validate_prot() but no one else does
(why not?).
This looks like it was added in ef3d3246a0d0 ("powerpc/mm: Add Strong
Access Ordering support"), which is powerpc specific. It looks like
this should correspond to a custom arch_calc_vm_prot_bits()
implementation, which exists on arm64, powerpc, sparc and x86.
I suppose it should be there for those four.
Arnd