As for compatibility with VM_LOCKONFAULT, do we need a new MADV_GUARD_INSTALL_LOCKED or can we say MADV_GUARD_INSTALL is new enough that it can be just retrofitted (like you retrofit file backed mappings)? AFAIU the only risk would be breaking somebody that already relies on a failure for VM_LOCKONFAULT, and it's unlikely there's such a somebody now.
Hmm yeah I suppose. I guess just to be consistent with the other _LOCKED variants? (which seem to be... undocumented at least in man pages :P, and yes I realise this is me semi-volunteering to do that obviously...).
But on the other hand, we could also expand this if you and I see also Dave feel this makes sense and wouldn't be confusing.
Just my 2 cents: one thing that came to mind: an existing library would have to be updated to use the _LOCKED variant if the app would be using mlockall(future), which is a bit unfortunate -- and if it could be avoided, it would be great.
But yeah, devil is in the detail ...