Messages in this thread |  | | Date | Fri, 25 Aug 2017 06:00:11 -0700 | From | Christoph Hellwig <> | Subject | Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags |
| |
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.
> > However, if the fcntl lease approach works for the DMA cases then we > only have the one mmap flag to add for now, so maybe the weird > MAP_{SHARED|PRIVATE} semantics are tolerable. ---end quoted text---
|  |