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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
