On 08/08/2017 05:19 PM, Mike Kravetz wrote: > On 08/08/2017 06:15 AM, Rik van Riel wrote: >> On Tue, 2017-08-08 at 11:58 +0200, Florian Weimer wrote: >>> On 08/07/2017 08:23 PM, Mike Kravetz wrote: >>>> If my thoughts above are correct, what about returning EINVAL if >>>> one >>>> attempts to set MADV_DONTFORK on mappings set up for sharing? >>> >>> That's my preference as well. If there is a use case for shared or >>> non-anonymous mappings, then we can implement MADV_DONTFORK with the >>> semantics for this use case. If we pick some arbitrary semantics >>> now, >>> without any use case, we might end up with something that's not >>> actually >>> useful. >> >> MADV_DONTFORK is existing semantics, and it is enforced >> on shared, non-anonymous mappings. It is frequently used >> for things like device mappings, which should not be >> inherited by a child process, because the device can only >> be used by one process at a time. >> >> When someone requests MADV_DONTFORK on a shared VMA, they >> will get it. The later madvise request overrides the mmap >> flags that were used earlier. >> >> The question is, should MADV_WIPEONFORK (introduced by >> this series) have not just different semantics, but also >> totally different behavior from MADV_DONTFORK? > > Sorry for the confusion. I accidentally used MADV_DONTFORK instead > of MADV_WIPEONFORK in my reply (which Florian commented on).
Yes, I made the same mistake. I meant MADV_WIPEONFORK as well. Florian
