On Tue 08-08-17 14:45:14, Rik van Riel wrote: > 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?
I would rather be conservative and implement the bare minimum until there is a reasonable usecase to demand the feature for shared mappings as well. -- Michal Hocko SUSE Labs
