Add some basic documentation of these operations, with a pointer to
tools/perf/design.txt for more information.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
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>
Michael Kerrisk