Re: [RESEND PATCH V2 0/3] Allow user to request memory to be locked on page fault

From: Vlastimil Babka
Date: Tue Jun 23 2015 - 09:04:28 EST

On 06/15/2015 04:43 PM, Eric B Munson wrote:
Note that the semantic of MAP_LOCKED can be subtly surprising:

"mlock(2) fails if the memory range cannot get populated to guarantee
that no future major faults will happen on the range.
mmap(MAP_LOCKED) on the other hand silently succeeds even if the
range was populated only

( from )

So MAP_LOCKED can silently behave like MAP_LOCKONFAULT. While
MAP_LOCKONFAULT doesn't suffer from such problem, I wonder if that's
sufficient reason not to extend mmap by new mlock() flags that can
be instead applied to the VMA after mmapping, using the proposed
mlock2() with flags. So I think instead we could deprecate
MAP_LOCKED more prominently. I doubt the overhead of calling the
extra syscall matters here?

We could talk about retiring the MAP_LOCKED flag but I suspect that
would get significantly more pushback than adding a new mmap flag.

Oh no we can't "retire" as in remove the flag, ever. Just not continue the way of mmap() flags related to mlock().

Likely that the overhead does not matter in most cases, but presumably
there are cases where it does (as we have a MAP_LOCKED flag today).
Even with the proposed new system calls I think we should have the

I'm not convinced, but it's not a major issue.

- mlock() takes a `flags' argument. Presently that's

- munlock() takes a `flags' arument. MLOCK_LOCKED|MLOCK_LOCKONFAULT
to specify which flags are being cleared.

- mlockall() and munlockall() ditto.

IOW, LOCKED and LOCKEDONFAULT are treated identically and independently.

Now, that's how we would have designed all this on day one. And I
think we can do this now, by adding new mlock2() and munlock2()
syscalls. And we may as well deprecate the old mlock() and munlock(),
not that this matters much.

*should* we do this? I'm thinking "yes" - it's all pretty simple
boilerplate and wrappers and such, and it gets the interface correct,
and extensible.

If the new LOCKONFAULT functionality is indeed desired (I haven't
still decided myself) then I agree that would be the cleanest way.

Do you disagree with the use cases I have listed or do you think there
is a better way of addressing those cases?

I'm somewhat sceptical about the security one. Are security sensitive buffers that large to matter? The performance one is more convincing and I don't see a better way, so OK.

What do others think?

To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at