Messages in this thread | | | Subject | Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK | From | Rik van Riel <> | Date | Tue, 08 Aug 2017 14:45:14 -0400 |
| |
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?
| |