On Tue, Aug 8, 2017 at 5:46 PM, Rik van Riel <riel@xxxxxxxxxx> 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. Anonymous would be sufficient for all of the Crypto-cases that I've come across. But I can imagine someone wanting to initialize all application state from a saved file, or share it between processes. The comparable minherit call sidesteps all of this by simply documenting that it results in a new anonymous page after fork, and so the previous state doesn't matter. Maybe the problem here is the poor name (my fault). WIPEONFORK suggests an action being taken ... like a user might think that it literally zeroes a file, for example. At the risk of bike shedding: maybe ZEROESONFORK would resolve that small ambiguity? -- Colm -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
