[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH XEN v8 24/29] tools/libs/call: linux: touch newly allocated pages after madvise lockdown



El 19/01/16 a les 14.24, Wei Liu ha escrit:
> On Fri, Jan 15, 2016 at 01:23:03PM +0000, Ian Campbell wrote:
>> This avoids a potential issue with a fork after allocation but before
>> madvise.
>>
>> Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
>> ---
>> v7: New, replacing "tools/libs/call: linux: avoid forking between mmap
>>     and madvise".
>> ---
>>  tools/libs/call/linux.c | 14 +++++++++++++-
>>  1 file changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/libs/call/linux.c b/tools/libs/call/linux.c
>> index 3641e41..651f380 100644
>> --- a/tools/libs/call/linux.c
>> +++ b/tools/libs/call/linux.c
> 
> I didn't notice you only handled this for Linux until now.
> 
> I think FreeBSD and NetBSD need similar treatment, too? But then current
> BSD* code doesn't even support DONTFORK in madvise.
> 
> Adding Roger for more input.

Hm, right, thanks for noticing this. I don't think FreeBSD needs a
similar treatment (pre-faulting), because mlock will remove any CoW when
making the pages wired.

Also, AFAICT we don't need to call madvise or minherit(2) because
mlock(2) already takes care of preventing the memory region from being
copied to the child on fork:

"Locked mappings are not inherited by the child process after a
fork(2)." [0]

So I think we are safe on the FreeBSD side.

Roger.

[0] https://www.freebsd.org/cgi/man.cgi?query=mlock


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.