Adding support for MAP_LOCK and mlock

[vmx]

Around the same time of this fork, there was a fork started called mapr, which implemented MAP_PRIVATE, MAP_LOCK and mlock. All use cases for MAP_PRIVATE are now covered by memmap2 through function calls. Thanks for pointing that out at #50 (comment).

What is left from that fork, what memmap2 is missing is MAP_LOCK and mlock. Before I do another PR, I'd like to check what the best way would be, hence this issue.

The only use-case for MAP_LOCK we currently have in our code base is in combination with map_anon. Should it only be added there? Or should it be added to all methods (similar to MAP_POPULATE as I did in at #50?

I think for adding mlock() there aren't any questions.

[adamreichold]

From the man page

MAP_LOCKED (since Linux 2.5.37)
              Mark  the mapped region to be locked in the same way as mlock(2).  This implementation will try to populate (prefault) the whole range but the mmap() call doesn't fail with ENOMEM if this fails.  Therefore major faults might happen later on.  So the
              semantic is not as strong as mlock(2).  One should use mmap() plus mlock(2) when major faults are not acceptable after the initialization of the mapping.  The MAP_LOCKED flag is ignored in older kernels.

Since it can fail silently, maybe it would be better to provide only lock and unlock methods and ignore the flag?

Otherwise, it should be handled just like MAP_POPULATE IMHO.

What I wondered about in the initial PR is whether can have at least some tests for the lock/unlock functionality. What is resource limit for locking memory in GitHub actions? Would that be sufficient for a small test case?

[vmx]

Since it can fail silently, maybe it would be better to provide only lock and unlock methods and ignore the flag?

That sounds like a good idea.

Do I understand the mmap documentation correctly, that if I would want to have a similar to the MAP_LOCKED flag, I'd call populate() and the mlock()? That should work for my use case (populate() wasn't a thing at the time of the fork).

So I'll do a PR with lock() and unlock() only (I guess the names should be without the leading "m", just as advise()).

I wanted to do a test, but I couldn't think of a way to do it. How would I test that a page is actually locked? Did you think of creating a lock of a mmap that is bigger than the available memory which then should fail as it won't swap?

[adamreichold]

Do I understand the mmap documentation correctly, that if I would want to have a similar to the MAP_LOCKED flag, I'd call populate() and the mlock()? That should work for my use case (populate() wasn't a thing at the time of the fork).

From the man page

  mlock(), mlock2(), and munlock()
       mlock()  locks pages in the address range starting at addr and continuing for len bytes.  All pages that contain a part of the specified address range are guaranteed to be resident in RAM when the call returns successfully; the pages are guaranteed to stay
       in RAM until later unlocked.

I would assume that MAP_POPULATE is not even necessary.

I wanted to do a test, but I couldn't think of a way to do it. How would I test that a page is actually locked? Did you think of creating a lock of a mmap that is bigger than the available memory which then should fail as it won't swap?

I was thinking about having the test make the system calls without errors would be helpful already. Theoretically /proc/self/smaps could be checked to determine if the range is locked into memory, but I think that might be a bit too much (and too specific to Linux).