On Fri, Sep 30, 2022, at 3:19 PM, Michael Ellerman wrote:
> "Arnd Bergmann" <a...@arndb.de> writes:
>>
>> 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
