QEMU, for example, will issue an mlockall(MCL_CURRENT | MCL_FUTURE); when
requested to then exit(); if it fails.
Hm under what circumstances? I use qemu extensively to test this stuff with
no issues. Unless you mean it's using it in the 'host' code somehow.
-overcommit mem-lock=on
or (legacy)
-realtime mlock=on
I think.
[...]
It fails because it tries to 'touch' the memory, but 'touching' guard
region memory causes a segfault. This kind of breaks the idea of
mlock()'ing guard regions.
I think adding workarounds to make this possible in any way is not really
worth it (and would probably be pretty gross).
We already document that 'mlock()ing lightweight guard regions will fail'
as per man page so this is all in line with that.
Right, and I claim that supporting VM_LOCKONFAULT might likely be as easy as
allowing install/remove of guard regions when that flag is set.
We already allow this flag! VM_LOCKED and VM_HUGETLB are the only flags we
disallow.
See mlock2();
SYSCALL_DEFINE3(mlock2, unsigned long, start, size_t, len, int, flags)
{
vm_flags_t vm_flags = VM_LOCKED;
if (flags & ~MLOCK_ONFAULT)
return -EINVAL;
if (flags & MLOCK_ONFAULT)
vm_flags |= VM_LOCKONFAULT;
return do_mlock(start, len, vm_flags);
}
VM_LOCKONFAULT always as VM_LOCKED set as well.
--
Cheers,
David / dhildenb
