Adding upstream version 4.22.0.upstream/4.22.0

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 193 insertions, 0 deletions

diff --git a/upstream/archlinux/man3p/msync.3p b/upstream/archlinux/man3p/msync.3p
new file mode 100644
index 00000000..ba461b6b
--- /dev/null
+++ b/upstream/archlinux/man3p/msync.3p
@@ -0,0 +1,193 @@
+'\" et
+.TH MSYNC "3P" 2017 "IEEE/The Open Group" "POSIX Programmer's Manual"
+.\"
+.SH PROLOG
+This manual page is part of the POSIX Programmer's Manual.
+The Linux implementation of this interface may differ (consult
+the corresponding Linux manual page for details of Linux behavior),
+or the interface may not be implemented on Linux.
+.\"
+.SH NAME
+msync
+\(em synchronize memory with physical storage
+.SH SYNOPSIS
+.LP
+.nf
+#include <sys/mman.h>
+.P
+int msync(void *\fIaddr\fP, size_t \fIlen\fP, int \fIflags\fP);
+.fi
+.SH DESCRIPTION
+The
+\fImsync\fR()
+function shall write all modified data to permanent storage locations,
+if any, in those whole pages containing any part of the address space of
+the process starting at address
+.IR addr
+and continuing for
+.IR len
+bytes. If no such storage exists,
+\fImsync\fR()
+need not have any effect. If requested, the
+\fImsync\fR()
+function shall then invalidate cached copies of data.
+.P
+The implementation may require that
+.IR addr
+be a multiple of the page size as returned by
+\fIsysconf\fR().
+.P
+For mappings to files, the
+\fImsync\fR()
+function shall ensure that all write operations are completed as
+defined for synchronized I/O data integrity completion. It is
+unspecified whether the implementation also writes out other file
+attributes. When the
+\fImsync\fR()
+function is called on MAP_PRIVATE mappings, any modified data shall
+not be written to the underlying object and shall not cause such data
+to be made visible to other processes. It is unspecified whether data
+in MAP_PRIVATE mappings has any permanent storage locations.
+The effect of
+\fImsync\fR()
+on a shared memory object or a typed memory object is unspecified.
+The behavior of this function is unspecified if the mapping was not
+established by a call to
+\fImmap\fR().
+.P
+The
+.IR flags
+argument is constructed from the bitwise-inclusive OR of one or more of
+the following flags defined in the
+.IR <sys/mman.h> 
+header:
+.TS
+center box tab(!);
+cB | cB
+lw(1.5i) | lw(2i).
+Symbolic Constant!Description
+_
+MS_ASYNC!Perform asynchronous writes.
+MS_SYNC!Perform synchronous writes.
+MS_INVALIDATE!Invalidate cached data.
+.TE
+.P
+When MS_ASYNC is specified,
+\fImsync\fR()
+shall return immediately once all the write operations are initiated or
+queued for servicing; when MS_SYNC is specified,
+\fImsync\fR()
+shall not return until all write operations are completed as defined for
+synchronized I/O data integrity completion. Either MS_ASYNC or MS_SYNC
+shall be specified, but not both.
+.P
+When MS_INVALIDATE is specified,
+\fImsync\fR()
+shall invalidate all cached copies of mapped data that are inconsistent
+with the permanent storage locations such that subsequent references
+shall obtain data that was consistent with the permanent storage
+locations sometime between the call to
+\fImsync\fR()
+and the first subsequent memory reference to the data.
+.P
+If
+\fImsync\fR()
+causes any write to a file, the file's last data modification and
+last file status change timestamps shall be marked for update.
+.SH "RETURN VALUE"
+Upon successful completion,
+\fImsync\fR()
+shall return 0; otherwise, it shall return \-1 and set
+.IR errno
+to indicate the error.
+.SH ERRORS
+The
+\fImsync\fR()
+function shall fail if:
+.TP
+.BR EBUSY
+Some or all of the addresses in the range starting at
+.IR addr
+and continuing for
+.IR len
+bytes are locked, and MS_INVALIDATE is specified.
+.TP
+.BR EINVAL
+The value of
+.IR flags
+is invalid.
+.TP
+.BR ENOMEM
+The addresses in the range starting at
+.IR addr
+and continuing for
+.IR len
+bytes are outside the range allowed for the address space of a process
+or specify one or more pages that are not mapped.
+.P
+The
+\fImsync\fR()
+function may fail if:
+.TP
+.BR EINVAL
+The value of
+.IR addr
+is not a multiple of the page size as returned by
+\fIsysconf\fR().
+.LP
+.IR "The following sections are informative."
+.SH EXAMPLES
+None.
+.SH "APPLICATION USAGE"
+The
+\fImsync\fR()
+function is only supported if the Synchronized Input and Output
+option is supported, and thus need not be available on all implementations.
+.P
+The
+\fImsync\fR()
+function should be used by programs that require a memory object to be
+in a known state; for example, in building transaction facilities.
+.P
+Normal system activity can cause pages to be written to disk.
+Therefore, there are no guarantees that
+\fImsync\fR()
+is the only control over when pages are or are not written to disk.
+.SH RATIONALE
+The
+\fImsync\fR()
+function writes out data in a mapped region to the permanent
+storage for the underlying object. The call to
+\fImsync\fR()
+ensures data integrity of the file.
+.P
+After the data is written out, any cached data may be invalidated if
+the MS_INVALIDATE
+flag was specified. This is useful on systems that do not support
+read/write consistency.
+.SH "FUTURE DIRECTIONS"
+None.
+.SH "SEE ALSO"
+.IR "\fImmap\fR\^(\|)",
+.IR "\fIsysconf\fR\^(\|)"
+.P
+The Base Definitions volume of POSIX.1\(hy2017,
+.IR "\fB<sys_mman.h>\fP"
+.\"
+.SH COPYRIGHT
+Portions of this text are reprinted and reproduced in electronic form
+from IEEE Std 1003.1-2017, Standard for Information Technology
+-- Portable Operating System Interface (POSIX), The Open Group Base
+Specifications Issue 7, 2018 Edition,
+Copyright (C) 2018 by the Institute of
+Electrical and Electronics Engineers, Inc and The Open Group.
+In the event of any discrepancy between this version and the original IEEE and
+The Open Group Standard, the original IEEE and The Open Group Standard
+is the referee document. The original Standard can be obtained online at
+http://www.opengroup.org/unix/online.html .
+.PP
+Any typographical or formatting errors that appear
+in this page are most likely
+to have been introduced during the conversion of the source files to
+man page format. To report such errors, see
+https://www.kernel.org/doc/man-pages/reporting_bugs.html .