On Thu 12-10-17 09:32:17, Linus Torvalds wrote: > On Thu, Oct 12, 2017 at 6:51 AM, Jan Kara <jack@xxxxxxx> wrote: > > > > When thinking a bit more about this I've realized one problem: Currently > > user can call mmap() with MAP_SHARED type and MAP_SYNC or MAP_DIRECT flags > > and he will get the new semantics (if the kernel happens to support it). I > > think that is undesirable [..] > > Why? > > If you have a performance preference for MAP_DIRECT or something like > that, but you don't want to *enforce* it, you'd use just plain > MAP_SHARED with it. > > Ie there may well be "I want this to work, possibly with downsides" issues. > > So it seems to be a reasonable model, and disallowing it seems to > limit people and not really help anything. I have two concerns: 1) IMHO it supports sloppy programming from userspace - if application asks e.g. for MAP_DIRECT and doesn't know whether it gets it or not, it would have to be very careful not to assume anything about that in its code. And frankly I think the most likely scenario is that a programmer will just use MAP_SHARED | MAP_DIRECT, *assume* he will get the MAP_DIRECT semantics if the call does not fail and then complain when his application breaks. 2) In theory there could be an application that inadvertedly sets some high flag bits and now it would get confused by getting different mmap(2) semantics. But I agree this is mostly theoretical. Overall I think the benefit of being able to say "do MAP_DIRECT if you can" does not outweight the risk of bugs in userspace applications. Especially since userspace can easily implement the same semantics by retrying the mmap(2) call without MAP_SHARED_VALIDATE | MAP_DIRECT. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR -- 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
