On 22.11.2017 20:53, Matthew Wilcox wrote: > On Wed, Nov 22, 2017 at 08:52:37AM -0800, Dan Williams wrote: >> On Wed, Nov 22, 2017 at 4:02 AM, Vlastimil Babka <[email protected]> wrote: >>> On 11/01/2017 04:36 PM, Jan Kara wrote: >>>> From: Dan Williams <[email protected]> >>>> >>>> The mmap(2) syscall suffers from the ABI anti-pattern of not validating >>>> unknown flags. However, proposals like MAP_SYNC need a mechanism to >>>> define new behavior that is known to fail on older kernels without the >>>> support. Define a new MAP_SHARED_VALIDATE flag pattern that is >>>> guaranteed to fail on all legacy mmap implementations. >>> >>> So I'm trying to make sense of this together with Michal's attempt for >>> MAP_FIXED_SAFE [1] where he has to introduce a completely new flag >>> instead of flag modifier exactly for the reason of not validating >>> unknown flags. And my conclusion is that because MAP_SHARED_VALIDATE >>> implies MAP_SHARED and excludes MAP_PRIVATE, MAP_FIXED_SAFE as a >>> modifier cannot build on top of this. Wouldn't thus it be really better >>> long-term to introduce mmap3 at this point? ... >> >> We have room to define MAP_PRIVATE_VALIDATE in MAP_TYPE on every arch >> except parisc. Can we steal an extra bit for MAP_TYPE from somewhere >> else on parisc? > > It looks like 0x08 should work.
I posted an RFC to the parisc mailing list for that: https://patchwork.kernel.org/patch/9970553/ Basically this is (for parisc only): -#define MAP_TYPE 0x03 /* Mask for type of mapping */ +#define MAP_TYPE (MAP_SHARED|MAP_PRIVATE|MAP_RESRVD1|MAP_RESRVD2) /* Mask for type of mapping */ #define MAP_FIXED 0x04 /* Interpret addr exactly */ +#define MAP_RESRVD1 0x08 /* reserved for 3rd bit of MAP_TYPE */ #define MAP_ANONYMOUS 0x10 /* don't use a file */ +#define MAP_RESRVD2 0x20 /* reserved for 4th bit of MAP_TYPE */ > But I don't have an HPUX machine around > to check that HP didn't use that bit for something else. We completely dropped support for HPUX binaries, so it's not relvant any longer. > It'd probably help to cc the linux-parisc mailing list when asking > questions about PARISC, eh? Yes, please. Helge _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
