On 08/06/2017 07:04 AM, riel@xxxxxxxxxx wrote: > v2: fix MAP_SHARED case and kbuild warnings > > Introduce MADV_WIPEONFORK semantics, which result in a VMA being > empty in the child process after fork. This differs from MADV_DONTFORK > in one important way. It seems that the target use case might be private anonymous mappings. If a shared or file backed mapping exists, one would assume that it was created with the intention of sharing, even across fork. So, setting MADV_DONTFORK on such a mapping seems to change the meaning and conflict with the original intention of the mapping. If my thoughts above are correct, what about returning EINVAL if one attempts to set MADV_DONTFORK on mappings set up for sharing? If not, and you really want this to be applicable to all mappings, then you should be more specific about what happens at fork time. Do they all get turned into anonymous mappings? What happens to file references? What about the really ugly case of hugetlb mappings? Do they get 'transformed' to non-hugetlb mappings? Or, do you create a separate hugetlb mapping for the child? -- Mike Kravetz -- 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>
