On Fri, Aug 25, 2017 at 06:00:11AM -0700, Christoph Hellwig wrote:
> On Thu, Aug 24, 2017 at 10:36:02AM -0700, Dan Williams wrote:
> > I'll let Andy and Kirill restate their concerns, but one of the
> > arguments that swayed me is that any new mmap flag with this hack must
> > be documented to only work with MAP_SHARED and that MAP_PRIVATE is
> > silently ignored. I agree with the mess and delays it causes for other
> > archs and libc, but at the same time this is for new applications and
> > libraries that know to look for the new flag, so they need to do the
> > extra work to check for the new syscall.
>
> True. That is for the original hack, but I spent some more time
> looking at the mmap code, and there is one thing I noticed:
>
> include/uapi/asm-generic/mman-common.h:
>
> #define MAP_SHARED 0x01 /* Share changes */
> #define MAP_PRIVATE 0x02 /* Changes are private */
> #define MAP_TYPE 0x0f /* Mask for type of mapping */
>
> mm/mmap.c:
>
> if (file) {
> struct inode *inode = file_inode(file);
>
> switch (flags & MAP_TYPE) {
> case MAP_SHARED:
> ...
> case MAP_PRIVATE:
> ...
> default:
> return -EINVAL;
> }
>
> and very similar for the anonymous and nommu cases.
>
> So if we pick e.g. 0x4 as the valid bit we don't even need to overload
> the MAP_SHARED and MAP_PRIVATE meaning.
Not all archs are ready for this:
arch/parisc/include/uapi/asm/mman.h:#define MAP_TYPE 0x03 /* Mask
for type of mapping */
arch/parisc/include/uapi/asm/mman.h:#define MAP_FIXED 0x04 /*
Interpret addr exactly */
--
Kirill A. Shutemov
