The perf_output_sample_ustack in kernel/events/core.c only writes
a single 64 bit word if it can't dump the user registers. From the
current version of the man page, I would have expected two 64 bit
words (one for size, one for dyn_size). Change the man page to
make this behavior explicit.
Reviewed-by: Vince Weaver <vincent.weaver@maine.edu>
The license on the original versoin of this page is troublesome,
because of restrictions imposed by the clause that the page may be
modified "for the purpose of improving Linux or its documentation
efforts".
By now, I have rewritten all except trivial pieces of the page,
and the structure definitions in any case came from kernel header
files. So, I'm relicensing the page to the "verbatim" license.
See https://bugzilla.kernel.org/show_bug.cgi?id=118311
Reported-by: Tom Callaway <tcallawa@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Niki Rahimi, the author of this page, has agreed that it's okay
to change the license to note that the page can be modified.
See https://bugzilla.kernel.org/show_bug.cgi?id=118311
Reported-by: Tom Callaway <tcallawa@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The page as originally written carried text that said the page may
be freely distributed but made no statement about modification.
In the 20+ years since it was first written, the page has in fact
seen repeated, sometimes substantial, modifications, and only a
small portion of the original text remains. One could I suppose
rewrite the last few pieces that remain from the original,
but as the largest contributor to the pages existing text,
I'm just going to relicense it to explicitly note that
modification is permitted. (I presume the failure by the
original author to grant permission to modify was simply an
oversight; certainly, the large number of people who have
changed the page have taken that to be the case.)
Reported-by: Tom Callaway <tcallawa@redhat.com>
See also https://bugzilla.kernel.org/show_bug.cgi?id=118311
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The discussion of RLIMIT_NICE was hidden under the EPERM error,
where it was difficult to find. Place some relevant text in
DESCRIPTION.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
See sysdeps/unix/sysv/linux/i386/setfsuid.c in glibc-2.2.1.
(This code is not present in modern glibc anymore.)
Signed-off-by: Jann Horn <jannh@google.com>
Reframe the discussion in terms of PTRACE_MODE_ATTACH checks,
and make a few other minor tweaks and additions.
Reviewed-by: Jann Horn <jann@thejh.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Among other things, Jann pointed out that the commoncap LSM
is always invoked, and Kees Cook pointed out the relevant
kernel code:
===
> BTW, can you point me at the piece(s) of kernel code that show that
> "commoncap" is always invoked in addition to any other LSM that has
> been installed?
It's not entirely obvious, but the bottom of security/commoncap.c shows:
struct security_hook_list capability_hooks[] = {
LSM_HOOK_INIT(capable, cap_capable),
...
};
void __init capability_add_hooks(void)
{
security_add_hooks(capability_hooks, ARRAY_SIZE(capability_hooks));
}
And security/security.c shows the initialization order of the LSMs:
int __init security_init(void)
{
pr_info("Security Framework initialized\n");
/*
* Load minor LSMs, with the capability module always first.
*/
capability_add_hooks();
yama_add_hooks();
loadpin_add_hooks();
/*
* Load all the remaining security modules.
*/
do_security_initcalls();
return 0;
}
===
Reported-by: Jann Horn <jann@thejh.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The "ptrace access mode" text is about user-space-visible
behavior, but in order to explain that behavior at what I
believe is a sufficient level of detail (e.g., to differentiate
the various types of checks that are performed for various
system calls and pseudofile accesses), one needs (1) to discuss
the MODE flag details as implemented in the kernel, and (2) to
have a shorthand way to refer to the various cases from other
pages. It's not absolutely necessary to name the flags for (1),
but using the flag names is certainly a handy shorthand for (2).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
At least one bit must be set in the 'val3' mask supplied for the
FUTEX_WAIT_BITSET and FUTEX_WAKE_BITSET operations.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Reported-by: Thomas Gleixner <tglx@linutronix.de>
Reported-by: Darren Hart <dvhart@infradead.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Since Linux 4.5, FUTEX_WAIT also understands
FUTEX_CLOCK_REALTIME.
Reported-by: Darren Hart <dvhart@infradead.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Under discussion of PR_SET_TIMERSLACK, refer the reader to
the /proc/[pid]/timerslack_ns file, documented in proc(5).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Mention that FICLONE, FICLONERANGE, and FIDEDUPERANGE all require
both files to reside on the same filesystem.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Document the FIDEDUPERANGE ioctl, formerly known as
BTRFS_IOC_EXTENT_SAME.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Document the FICLONE and FICLONERANGE ioctls, formerly known as
the BTRFS_IOC_CLONE and BTRFS_IOC_CLONE_RANGE ioctls.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
iBoth add_key and the utility "keyctl add" return EINVAL when
attempting to add a user key with an empty or NULL payload.
The manpage implies that this should be valid.
From my reading of the kernel source, this has not been possible
since at least linux kernel commit 1da177e4 (2.6.12-rc2 on
2005-04-16).
Until kernel commit cf7f601c,
security/keys/user_defined.c:user_instantiate returned -EINVAL
if datalen <= 0. That commit only moved this behavior to a new
user_preparse function, where it remains today in b562e44f
(4.5.0 on 2016-03-13).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk