linux-kernel - Re: [PATCH 16/17] RISC-V: User-facing API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170711140132.GP6973@jhogan-linux.le.imgtec.org>
Date:   Tue, 11 Jul 2017 15:01:32 +0100
From:   James Hogan <james.hogan@...tec.com>
To:     Christoph Hellwig <hch@...radead.org>
CC:     Palmer Dabbelt <palmer@...belt.com>,
        <yamada.masahiro@...ionext.com>, <mmarek@...e.com>,
        <will.deacon@....com>, <peterz@...radead.org>,
        <boqun.feng@...il.com>, <mingo@...hat.com>,
        <daniel.lezcano@...aro.org>, <tglx@...utronix.de>,
        <jason@...edaemon.net>, <marc.zyngier@....com>,
        <gregkh@...uxfoundation.org>, <jslaby@...e.com>,
        <davem@...emloft.net>, <mchehab@...nel.org>,
        <sfr@...b.auug.org.au>, <fweisbec@...il.com>,
        <viro@...iv.linux.org.uk>, <mcgrof@...nel.org>,
        <dledford@...hat.com>, <bart.vanassche@...disk.com>,
        <sstabellini@...nel.org>, <daniel.vetter@...ll.ch>,
        <mpe@...erman.id.au>, <msalter@...hat.com>,
        <nicolas.dichtel@...nd.com>, <paul.gortmaker@...driver.com>,
        <linux@...ck-us.net>, <heiko.carstens@...ibm.com>,
        <schwidefsky@...ibm.com>, <linux-kernel@...r.kernel.org>,
        <patches@...ups.riscv.org>, <akpm@...ux-foundation.org>,
        <albert@...ive.com>
Subject: Re: [PATCH 16/17] RISC-V: User-facing API

Hi Christoph,

On Tue, Jul 11, 2017 at 06:39:48AM -0700, Christoph Hellwig wrote:
> > +#ifdef CONFIG_64BIT
> > +SYSCALL_DEFINE6(mmap, unsigned long, addr, unsigned long, len,
> > +	unsigned long, prot, unsigned long, flags,
> > +	unsigned long, fd, off_t, offset)
> > +{
> > +	if (unlikely(offset & (~PAGE_MASK)))
> > +		return -EINVAL;
> > +	return sys_mmap_pgoff(addr, len, prot, flags, fd, offset >> PAGE_SHIFT);
> > +}
> > +#else
> > +SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
> > +	unsigned long, prot, unsigned long, flags,
> > +	unsigned long, fd, off_t, offset)
> > +{
> > +	/*
> > +	 * Note that the shift for mmap2 is constant (12),
> > +	 * regardless of PAGE_SIZE
> > +	 */
> > +	if (unlikely(offset & (~PAGE_MASK >> 12)))
> > +		return -EINVAL;
> > +	return sys_mmap_pgoff(addr, len, prot, flags, fd,
> > +		offset >> (PAGE_SHIFT - 12));
> > +}
> > +#endif /* !CONFIG_64BIT */
> 
> Most modern ports seem to expose sys_mmap_pgoff as the
> syscall directly.  Any reason you're doing this differently?

I think Palmer's patch is probably correct here. Exposing sys_mmap_pgoff
is only really correct on 32-bit arches where the only page size is 4k.
If other page sizes are supported then this is the correct way to handle
it as the page offset from 32-bit userland is supposed to be in 4k
units.

64-bit doesn't need to worry about squeezing big file offsets into the
off_t offset so don't need to do the shift at all.

See the mmap2 man page. It says "the final argument specifies the offset
into the file in 4096-byte units", and it points out ia64 as an
exception where it depends on the page size of the system.

> 
> But even the code for the older ones should probably be consolidated..

Quite probably, yes.

Cheers
James

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)