SPARC reverses the use of 'addr' and 'data' for
PTRACE_GETREGS, PTRACE_GETFPREGS, PTRACE_SETREGS,
and PTRACE_SETFPREGS.
Reported-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The corresponding kernel change from Marchel Holtmann was
The attached patch fixes a flaw in the "parent process
death signal" when executing SUID binaries. An
unprivileged user may send arbitrary signal to a child
process even if it is running with higher privileges.
The idea to fix this issue is to reset pdeath_signal not
only on fork, but also on the execution of a SUID binary.
Reported-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As reported in https://bugzilla.redhat.com/show_bug.cgi?id=680214
the descriptions of ENOSYS and EOPNOTSUP are not corrected
Reported-by: John Sullivan <jsrhbz@kanargh.force9.co.uk>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It seems sendto() can return EACCES for UDP as well; the current
man page in git only says it can return EACCES for Unix sockets.
I was able to make sendto() return EACCES if I try to send from
192.168.1.1/24 to 192.168.1.0. I think the relevant code (in
kernel 2.6.38, but also present in 2.6.7 and 2.6.32, the 2 kernels
we use) is this (net/ipv4/udp.c, udp_sendmsg()):
910 err = -EACCES;
911 if ((rt->rt_flags & RTCF_BROADCAST) &&
912 !sock_flag(sk, SOCK_BROADCAST))
913 goto out;
So I guess if the kernel finds a route to the destination and
it's a broadcast route (and the socket doesn't have the broadcast
flag), then it returns EACCES.
I can verify the behavior with a very simple program (attached).
I've run it on my Ubuntu 10.10 (2.6.35 kernel) and got this:
stefan@spuiu-vml2:~/src/test/broadcast$ ./broadcast_test 10.205.20.94
10.205.20.1
sendto() returned 4
stefan@spuiu-vml2:~/src/test/broadcast$ ./broadcast_test 10.205.20.94
10.205.20.0
sendto() returned negative, errno: 13/Permission denied
(10.205.20.94 is my local IP, of course).
=====
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <errno.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
int sock;
if (argc < 2) {
printf("Usage: %s local_address destination_address\n", argv[0]);
exit(1);
}
sock = socket(AF_INET, SOCK_DGRAM, 0);
if (sock < 0) {
perror("socket");
return -1;
}
struct sockaddr_in local_addr;
local_addr.sin_family = AF_INET;
local_addr.sin_port = htons(1234);
local_addr.sin_addr.s_addr = inet_addr(argv[1]);
int ret = bind(sock, (struct sockaddr *) &local_addr, sizeof(local_addr));
if (ret < 0) {
perror("bind");
return -1;
}
struct sockaddr_in remote_addr;
remote_addr.sin_family = AF_INET;
remote_addr.sin_port = htons(1234);
remote_addr.sin_addr.s_addr = inet_addr(argv[2]);
ret = sendto(sock, "blah", 4, 0, (struct sockaddr *)&remote_addr, sizeof(remote_addr));
if (ret < 0) {
printf("sendto() returned negative, errno: %d/%m\n", errno);
}
else {
printf("sendto() returned %d\n", ret);
}
return 0;
}
=====
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
For a long time now, glibc's raise(3) didn't yield SI_USER
for the signal receiver, so remove mention of raise(3)
here. The user can deduce the details, if needed, by looking
at the recently updated raise(3) page.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Remove some FIXMEs and comment out pieces of text that describe
features not yet merged mainline kernel.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
* Wording improvements
* Addition of some FIXMEs for suspicious points
* Addition of various EINVAL cases
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As Simone notes, RETURN VALUE says:
On error, (clock_t) -1 is returned, and errno is set appropriately
but no value for errno is specified. The only error case is
EFAULT, so let's add that.
Reported-by: Simone Piccardi <piccardi@truelite.it>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The wrapper function has a 'flags' argument (which currently
serves no purpose), while the underlying system call does not.
Reported-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Here's a patch to the fcntl.2 manpage that explains
the working of F_GETLEASE in a bit more detail during
lease breaks. Basically, what happens is this: When a
lease break is initiated by a lease breaker, subsequent
F_GETLEASE calls return the target lease type after
the lease break and not the existing lease type. This
behavior persists until the lease holder downgrades/unlocks
the lease or the kernel forcibly does it after the lease
break timeout expires.
The implicit assumption is that F_GETLEASE should
return the existing lock type until the downgrade/unlock
has actually taken place, which is not true. I've verified
that the kernel indeed returns the target lease type. It
is also simple enough to verify this behavior in a small
program, where you can observe that the lease type
returned by F_GETLEASE in the signal handler for a
lease break is different from the existing lease type.
Signed-off-by: Abhijith Das <adas@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Various fcntl(2) commands require an integral 'arg'.
The man page said it must be "long" in all such cases.
However, for the cases covered by POSIX, there is an
explicit requirement that these arguments be "int".
Update the man page to reflect. Probably, all of the
other "long" cases (not specified in POSIX) should
be "int", and this patch makes them so. Based on a
note fromEric Blake, relating to F_DUPFD_CLOEXEC.
Reported-by: Eric Blake <ebb9@byu.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
For some reason, the PTRACE_TRACEME paragraph talks about some
general aspects of ptraced process behavior. It repeats the
"tracee stops on every signal" information even though that was
already explained just a few paragraphs before. Then it describes
legacy SIGTRAP on execve().
This patch deletes the first part, and moves the second part up,
into the general ptrace description. It also adds
"If PTRACE_O_TRACEEXEC option is not in effect" to the description
of the legacy SIGTRAP on execve().
The patch also amends the part which says "For requests other
than PTRACE_KILL, the tracee must be stopped." - PTRACE_ATTACH
also doesn't require that.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The unimplemented system calls are in any case noted lower down
in the page. Also: rearrange the text describing the unimplemented
system calls.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
syscalls.2: fix
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
* Wording and formatting fixes to existing text and
Denys Vlasenko's new text.
* Various technical amendments and improvements to
Denys Vlasenko's new text.
* Added FIXME for various problems with the current text.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Changes include:
s/parent/tracer/g, s/child/tracee/g - ptrace interface now
is sufficiently cleaned up to not treat tracing process
as parent.
Deleted several outright false statements:
- pid 1 can be traced
- tracer is not shown as parent in ps output
- PTRACE_ATTACH is not "the same behavior as if tracee had done
a PTRACE_TRACEME": PTRACE_ATTACH delivers a SIGSTOP.
- SIGSTOP _can_ be injected.
- Removed mentions of SunOS and Solaris as irrelevant.
- Added a few more known bugs.
Added a large block of text in DESCRIPTION which doesn't focus
on mechanical description of each flag and operation, but rather
tries to describe a bigger picture. The targeted audience is
a person which is reasonably knowledgeable in Unix but did not
spend years working with ptrace, and thus may be unaware of its
quirks. This text went through several iterations of review by
Oleg Nesterov and Tejun Heo.
This block of text intentionally uses as little markup as possible,
otherwise future modifications to it will be very hard to make.
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
An edited version of Guillem Jover's comments:
[While the file descriptor does not need to be writable on Linux]
that's not a safe portable assumption to make on POSIX in general
as that behavior is not specified and as such is
implementation-specific. Some Unix systems do actually fail on
read-only file descriptors, for example [HP-UX and AIX].
Reported-by: Guillem Jover <guillem@hadrons.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
- explain the situation with disk caches better
- remove the duplicate fdatasync() explanation in the NOTES
section
- remove an incorrect note about fsync() generally requiring two
writes
- remove an obsolete ext2 example note
- fsync() works on any file descriptor (doesn't need to be
writable); correct the EBADF error code explanation
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The addition of a second class of operation ("hole punching")
to the man page made it clear that some significant restructuring
is required. So I substantially reworked the page, including the
preexisting material on the default "file allocation" operation.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
FALLOC_FL_PUNCH_HOLE was added in Linux 2.6.38,
for punching holes in the allocated space in a file.
Signed-off-by: Lucian Adrian Grijincu <lucian.grijincu@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Some pieces inspired by an initial attempt by Stephan Mueller.
Reported-by: Stephan Mueller <stephan.mueller@atsec.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Add some words to make it clear to the reader that vfork(),
like fork(), creates duplicates of process attributes
in the child.
Reported-by: starlight@binnacle.cx
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Since Linux 2.6.24, it is no longer possible to
modify the SCHED_RR quantum using setpriority(2).
(Slight edits to Clemens' patch by mtk.)
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Please find attach a consistency fix: there were only five
"zeroes" but twenty four "zeros" in those manual pages.
(Make all instances "zeros".)
Signed-off-by: David Prévot <taffit@debian.org>
Document the MADV_HUGEPAGE and MADV_NOHUGEPAGE flags added to
madvise() in Linux 2.6.38.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Since Linux 2.6.39, unprivileged processes under the
SCHED_IDLE policy can switch to another nonrealtime
policy if their nice value falls within the range
permitted by their RLIMIT_NICE limit.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
These flags, designed for discovering holes in a file,
were added in Linux 3.1. Included comments from Eric
Blake and Sunil Mushran.
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Sunil Mushran <sunil.mushran@oracle.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As noted by Alan Curry:
According to man2/lseek.2,
This document's use of whence is incorrect English, but
maintained for historical reasons.
What is the grammatical objection?
From WordNet (r) 3.0 (2006) [wn]:
whence
adv 1: from what place, source, or cause
Wiktionary:
[edit] Adverb
whence (not comparable)
1. From where; from which place or source.
lseek's second parameter is a distance to be traveled, and
the third parameter chooses the starting point from which
that distance is measured. How is that not a "whence"?
Looking at some man page archives, I found that the accusation
of incorrect English goes back to before 4.4BSD. It survives
not just in the linux-man-pages but also in recent versions
of {Net,Open,Free}BSD. The name "whence" for this parameter
goes back at least to V7.
Of all the people who have read this page over the years,
am I the only one wondering... what's this about? Who decided
that "whence" was incorrect and put that note in the man page?
Was there ever anything wrong, or do we have someone's
20-year-old unresearched pet peeve lingering in the man pages?
Reported-by: Alan Curry <pacman@kosh.dhis.org>
Reported-by: Reuben Thomas <rrt@sc3d.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Now that the underlying system call rt_sigqueueinfo(2) is
properly documented, move sigqueue() to Section 3, since
it is really a library function.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This replaces the previous '.so' man page link file for
rt_sigqueueinfo.2, which linked to ths sigqueue() man page.
Reported-by: Stephan Mueller <stephan.mueller@atsec.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
We've recently discovered that GDB will fail to attach to any
process that sets itself non-dumpable. Tested on kernel 2.6.32,
with:
int main(int argc, char *argv[])
{
if (prctl(PR_SET_DUMPABLE, 0, 0, 0) != 0) {
perror("prctl");
}
printf("Run gdb %s %d\n", argv[0], getpid());
sleep(20);
abort();
}
./a.out
Run gdb ./a.out 30476
gdb -q ./a.out 30476
Reading symbols from /tmp/a.out...done.
Attaching to program: /tmp/a.out, process 30476
ptrace: Operation not permitted.
/tmp/30476: No such file or directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The current version of the page says (under ERRORS):
> EBUSY (not on Linux)
> The file pathname cannot be unlinked because it is being
> used by the system or another process and the
> implementation considers this an error.
But if you look in the kernel source file fs/namei.c
at routine may_delete() you'll see two occasions where
an EBUSY is generated. So the above "not on Linux" is wrong.
I suggest that this '(not on Linux)' be removed. It may
also improve the page if the commentary is reworded to give a
better description of the two situations. Something along
the lines of:
> The file pathname cannot be unlinked because it is being used
> by the system, e.g. if some (relative) rootdir is mounted upon it,
> or because the NFS client software created it to represent an
> active but otherwise nameless inode ("NFS silly renamed").
Just FYI: the NFS silly rename (you'll find this term mentioned
in the kernel source code) is described at:
http://nfs.sourceforge.net/#section_d
under section D2. The reason I found this manpage bug is because
I stumbled upon one of these silly renamed files, and an strace
of the rm-command revealed the EBUSY return errno.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
See http://bugs.debian.org/cgi-bin/bugreport.cgi?641513
timerfd_settime(2) states that "The old_value argument returns a
structure containing the setting of the timer that was current at
the time of the call"; however, it does not mention that the
caller can pass NULL to ignore that value. Only the example
shows that the caller can pass NULL.
Reported-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Linux kernel commit cc56f7de7f00d188c7c4da1e9861581853b9e92f
meant sendfile(2) can work with any output file.
Therefore the 'out_fd' of sendfile(2) can refer to any file
(since Linux 2.6.33).
Signed-off-by: Akira Fujita <a-fujita@rs.jp.nec.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk