On Wed, Nov 22, 2017 at 08:52:37AM -0800, Dan Williams wrote: > On Wed, Nov 22, 2017 at 4:02 AM, Vlastimil Babka <vbabka@xxxxxxx> wrote: > > On 11/01/2017 04:36 PM, Jan Kara wrote: > >> From: Dan Williams <dan.j.williams@xxxxxxxxx> > >> > >> 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. But I don't have an HPUX machine around to check that HP didn't use that bit for something else. It'd probably help to cc the linux-parisc mailing list when asking questions about PARISC, eh? -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
