On Thu, Dec 17, 2015 at 08:06:21AM +0100, Michael Kerrisk (man-pages) wrote:

So, I just realized that a recent change to the API, plus its
associated documentation in the mlock(2) pages actually probably
lessens the chance of this mistake. The next release of man-pages
will include documentation of MCL_ONFAULT:

       MCL_CURRENT Lock  all pages which are currently mapped into the
                   address space of the process.

       MCL_FUTURE  Lock all pages which will become  mapped  into  the
                   address  space of the process in the future.  These
                   could be, for instance, new  pages  required  by  a
                   growing heap and stack as well as new memory-mapped
                   files or shared memory regions.

       MCL_ONFAULT (since Linux 4.4)
                   Used  together  with  MCL_CURRENT,  MCL_FUTURE,  or
                   both.   Mark  all  current  (with  MCL_CURRENT)  or
                   future (with MCL_FUTURE)  mappings  to  lock  pages
                   when  they are faulted in.  When used with MCL_CUR‐
                   RENT, all present pages are locked, but  mlockall()
                   will  not  fault  in  non-present pages.  When used
                   with MCL_FUTURE, all future mappings will be marked
                   to  lock  pages  when they are faulted in, but they
                   will not be populated by the lock when the  mapping
                   is  created.   MCL_ONFAULT must be used with either
                   MCL_CURRENT or MCL_FUTURE or both.

Do you think that text helps?

Yes.  It seems foolproof for the one fool that is me.

Thank you!

Jörn

--
It does not matter how slowly you go, so long as you do not stop.
-- Confucius
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html