Thread (15 messages) flat view 15 messages, 2 authors, 2017-08-16

Re: [PATCH v5 3/5] mm: introduce mmap3 for safely defining new mmap flags

From: Dan Williams <hidden>
Date: 2017-08-16 16:52:16
Also in: linux-fsdevel, linux-mm, linux-xfs, lkml, nvdimm

On Wed, Aug 16, 2017 at 9:47 AM, Kirill A. Shutemov
[off-list ref] wrote:
On Wed, Aug 16, 2017 at 09:35:11AM -0700, Dan Williams wrote:
quoted
On Wed, Aug 16, 2017 at 4:15 AM, Kirill A. Shutemov
[off-list ref] wrote:
quoted
On Wed, Aug 16, 2017 at 12:44:22AM -0700, Dan Williams wrote:
quoted
diff --git a/include/linux/mman.h b/include/linux/mman.h
index c8367041fafd..0e1de42c836f 100644
--- a/include/linux/mman.h
+++ b/include/linux/mman.h
@@ -7,6 +7,40 @@
 #include <linux/atomic.h>
 #include <uapi/linux/mman.h>

+#ifndef MAP_32BIT
+#define MAP_32BIT 0
+#endif
+#ifndef MAP_HUGE_2MB
+#define MAP_HUGE_2MB 0
+#endif
+#ifndef MAP_HUGE_1GB
+#define MAP_HUGE_1GB 0
+#endif
+
+/*
+ * The historical set of flags that all mmap implementations implicitly
+ * support when file_operations.mmap_supported_mask is zero.
+ */
+#define LEGACY_MAP_SUPPORTED_MASK (MAP_SHARED \
+             | MAP_PRIVATE \
+             | MAP_FIXED \
+             | MAP_ANONYMOUS \
+             | MAP_UNINITIALIZED \
+             | MAP_GROWSDOWN \
+             | MAP_DENYWRITE \
+             | MAP_EXECUTABLE \
+             | MAP_LOCKED \
+             | MAP_NORESERVE \
+             | MAP_POPULATE \
+             | MAP_NONBLOCK \
+             | MAP_STACK \
+             | MAP_HUGETLB \
+             | MAP_32BIT \
+             | MAP_HUGE_2MB \
+             | MAP_HUGE_1GB)
+
+#define      MAP_SUPPORTED_MASK (LEGACY_MAP_SUPPORTED_MASK)
+
 extern int sysctl_overcommit_memory;
 extern int sysctl_overcommit_ratio;
 extern unsigned long sysctl_overcommit_kbytes;
Since we looking into mmap(2) ABI, maybe we should consider re-defining
MAP_DENYWRITE and MAP_EXECUTABLE as 0 in hope that we would be able to
re-use these bits in the future? These flags are ignored now anyway.
Yes, we can make these -EOPNOTSUPP in the new syscall.
You cannot detect them, if we would redefine them as 0. :)
Yes, we can, there will now be missing bits in
LEGACY_MAP_SUPPORTED_MASK that will fail those bit values until we
re-define them. Everything else is a an exercise for libc about what
it wants to do when it sees those values.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help