- fstatfs is now permitted.
- ioctl isn't, and is worth listing explicitly
- O_PATH allows an automount point to be opened with
triggering the mount.
All tested
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Recent patch to description of MNT_FORCE incorrectly
dropped the mention of possible data loss. Restore it.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
MNT_FORCE does not allow a busy filesystem to be unmounted. Only
MNT_DETACH allows that. MNT_FORCE only tries to abort pending
transactions, in the hope that might help umount not to block,
Also, other filesystems than NFS support MNT_FORCE.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Since glibc 2.25 the PID cache is removed.
Rationale given in the release notes:
https://sourceware.org/glibc/wiki/Release/2.25#pid_cache_removal
~~~
3.2.3. Calls to getpid are no longer cached
The PID cache used by glibc has been removed. In certain scenarios
the cache was not 100% reliable and because of that it was deemed
safer to remove the cache than to potentially return a wrong
answer.
Applications performing getpid() calls in a loop will see the
worst case performance degradation as the library call will
perform a system call at each invocation. Such application uses
were known to exist at least in OpenSSL (fork()-based PRNG
invalidation), but supporting the performance of that specific
invalidation mechanism was not judged to have sufficient value
against immediate and long-term benefits of removing the cache.
Functional reasons exist for the PID cache removal including
problems with PID namespaces, interoperability with raw system
calls (BZ#17214, Chrome: Issue 800183004), and improvements to
spawn (BZ#19957). Performance is actually increased in
pthread_create() with the removal of the cache since the
implementation no longer needs to perform an invalidation step.
Applications performing getpid() in a loop that need to do some
level of fork()-based invalidation can instead use
pthread_atfork() to register handlers to handle the invalidation.
There is work-in-progress to make pthread_atfork() available to
applications that do not link against libpthread.so (Provide
pthread_atfork() without libpthread.so).
Other kinds of invalidation are not supported and the glibc
community will actively look at a kernel assisted mechanism for
state management across fork(), vfork(), clone() and other
interfaces which can benefit from such semantics. It is the same
type of solution required for crypto PRNG reset across such API
calls.
~~~
Signed-off-by: Carlos O'Donell <carlos@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
First clarify that the process cannot catch this SIGSYS signal.
While the text currently says that, it's easy (IMO) to read
ambiguously and that it's referring to default behavior (no
handler -> process exits).
Then add details regarding coredump behavior. Before Linux 4.11,
there was no way to get coredumps from such crashes. Now we can
at least get crashes from single threaded processes.
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
There is a POSIX_FADV_NOREUSE for posix_fadvise(),
but no POSIX_MADV_NOREUSE for any API in POSIX.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Document the new GETFSMAP ioctl that returns the physical layout of a
(disk-based) filesystem.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
In the Illumos source (which presumably mirrors its Solaris
ancestry), there is this check in the sigaltstack()
implementation:
if (ss.ss_flags & ~SS_DISABLE)
return (set_errno(EINVAL));
And in the FreeBSD source we find similar:
if ((ss->ss_flags & ~SS_DISABLE) != 0)
return (EINVAL);
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
NeilBrown