On Tue, 2017-08-08 at 09:52 -0700, Matthew Wilcox wrote: > On Tue, Aug 08, 2017 at 11:46:08AM -0400, Rik van Riel wrote: > > On Tue, 2017-08-08 at 08:19 -0700, Mike Kravetz wrote: > > > If the use case is fairly specific, then perhaps it makes sense > > > to > > > make MADV_WIPEONFORK not applicable (EINVAL) for mappings where > > > the > > > result is 'questionable'. > > > > That would be a question for Florian and Colm. > > > > If they are OK with MADV_WIPEONFORK only working on > > anonymous VMAs (no file mapping), that certainly could > > be implemented. > > > > On the other hand, I am not sure that introducing cases > > where MADV_WIPEONFORK does not implement wipe-on-fork > > semantics would reduce user confusion... > > It'll simply do exactly what it does today, so it won't introduce any > new fallback code.
Sure, but actually implementing MADV_WIPEONFORK in a way that turns file mapped VMAs into zero page backed anonymous VMAs after fork takes no more code than implementing it in a way that refuses to work on VMAs that have a file backing. There is no complexity argument for or against either approach. The big question is, what is the best for users? Should we return -EINVAL when MADV_WIPEONFORK is called on a VMA that has a file backing, and only succeed on anonymous VMAs? Or, should we simply turn every memory range that has MADV_WIPEONFORK done to it into an anonymous VMA in the child process?
