.\" $OpenBSD: mlockall.2,v 1.5 2008/06/26 05:42:05 ray Exp $ .\" $NetBSD: mlockall.2,v 1.6 2000/06/26 17:00:02 kleink Exp $ .\" .\" Copyright (c) 1999 The NetBSD Foundation, Inc. .\" All rights reserved. .\" .\" This code is derived from software contributed to The NetBSD Foundation .\" by Jason R. Thorpe of the Numerical Aerospace Simulation Facility, .\" NASA Ames Research Center. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" 3. All advertising materials mentioning features or use of this software .\" must display the following acknowledgement: .\" This product includes software developed by the NetBSD .\" Foundation, Inc. and its contributors. .\" 4. Neither the name of The NetBSD Foundation nor the names of its .\" contributors may be used to endorse or promote products derived .\" from this software without specific prior written permission. .\" .\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS .\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED .\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR .\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS .\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR .\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF .\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS .\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN .\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE .\" POSSIBILITY OF SUCH DAMAGE. .\" .Dd May 16, 2022 .Dt MLOCKALL 2 .Os .Sh NAME .Nm mlockall , .Nm munlockall .Nd lock (unlock) the address space of a process .Sh LIBRARY .Lb libc .Sh SYNOPSIS .In sys/types.h .In sys/mman.h .Ft int .Fn mlockall "int flags" .Ft int .Fn munlockall "void" .Sh DESCRIPTION The .Fn mlockall system call locks into memory the physical pages associated with the address space of a process until the address space is unlocked, the process exits, fork()s, or execs another program image. Any pages which are copy-on-write at the time of the function call will be force faulted. Locked pages will not be paged to swap backing store. .Pp The following flags affect the behavior of .Fn mlockall : .Bl -tag -width ".Dv MCL_CURRENT" .It Dv MCL_CURRENT Lock all pages currently mapped into the process's address space. .It Dv MCL_FUTURE Lock all pages mapped into the process's address space in the future, at the time the mapping is established. Note that this may cause future mappings to fail if those mappings cause resource limits to be exceeded. .El .Pp Since physical memory is a potentially scarce resource, processes are limited in how much they can lock down. A single process can lock the minimum of a system-wide .Dq wired pages limit and the per-process .Dv RLIMIT_MEMLOCK resource limit. .Pp .Fn mlockall has two limitations, necessary to keep it functional on modern systems. The first is that writable file-backed MAP_PRIVATE pages (such as shared library mappings) which have not yet been write-faulted will retain their read-only mapping to the file backing store and not be force-copied. If we were to force copy these pages, it would cause immense unnecessary overheads for the program. So any unmodified but writable pages which are currently in the pmap read-only will still take a COW fault if written to. .Pp The second limitation is that when a fork() is issued, all writable pages will be made copy-on-write (COW) in both the parent and the child. The child of course does not inherit the locked memory state, but this action will cause any locked pages in the parent to become copy-on-write and they will be faulted if written to. So they will not be quite as locked as might have been intended in this situation. .Pp The .Fn munlockall call unlocks any locked memory regions in the process address space. Any regions mapped after an .Fn munlockall call will not be locked. .Sh RETURN VALUES A return value of 0 indicates that the call succeeded and all pages in the range have either been locked or unlocked. A return value of \-1 indicates an error occurred and the locked status of all pages in the range remains unchanged. In this case, the global location .Va errno is set to indicate the error. .Sh ERRORS .Fn mlockall will fail if: .Bl -tag -width Er .It Bq Er EINVAL The .Fa flags argument is zero, or includes unimplemented flags. .It Bq Er ENOMEM Locking the indicated range would exceed either the system or per-process limit for locked memory. .It Bq Er EPERM The calling process does not have the appropriate privilege to perform the requested operation. .El .Sh SEE ALSO .Xr mincore 2 , .Xr mlock 2 , .Xr setrlimit 2 .Sh STANDARDS The .Fn mlockall and .Fn munlockall functions are believed to conform to .St -p1003.1-2001 . .Sh HISTORY The .Fn mlockall and .Fn munlockall functions first appeared in .Dx 2.9 . .Sh BUGS How could there be any bugs? This is soooo simple... .Pp These system calls are not recommended for general use. They are obviously not thread-safe, and the larger application context from which they are called might be hostile to such actions due to non-deterministic resource limits in the system. In a modern system, even semi-realtime and interactive processes are already detected and handled by the system schedule. Please use .Fn mlock and .Fn munlock to lock specific address ranges instead of locking the entire address space.