* waitid() fails with EINVAL for SA_RESTART signals
@ 2005-05-18 8:20 Michael Kerrisk
2005-05-26 21:17 ` Roland McGrath
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Michael Kerrisk @ 2005-05-18 8:20 UTC (permalink / raw)
To: roland; +Cc: linux-kernel, michael.kerrisk
Hello Roland,
I'm seeing a strange behaviour with waitid() in 2.6.12-rc3
(I'm fairly sure the behaviour also appears in other 2.6.x).
If we establish a handler for a signal with SA_RESTART, and that
signal interrupts a blocked waitid(), then waitid() fails with
the error EINVAL. I would expect the call to be restarted
(like wait(), waitpid(), etc.) or if you are choosing to design
waitid() to ignore SA_RESTART, then fail with EINTR.
I haven't been able to spot the source of the EINVAL in kernel
or glibc sources.
The program below can be used to demonstrate the problem.
Cheers,
Michael
/* waitid_intr.c
Michael Kerrisk, May 2005
Demonstration of a problem with waitid() on Linux (Linux 2.6.12-rc3).
If S_A_RESTART was specified for a signal handler, and that signal
is delivered during a blocked waitid(), then the waitid() fails
with EINVAL, when it should either be restarted or (if the intent
is to ignore SA_RESTART in the waitid() implementation) fail
with EINTR. This program demonstrates the problem.
The program creates two children. The first is a child that sleeps
for argv[2] seconds and is then reaped by waitid() in the parent.
The second child sends a signal (SIG) to the parent after argv[3]
seconds.
argv[1] specifies options for the waitid() call (see the code
below).
If the optional argv[4] is present (as any string), then the
handler for the signal sent by the second child is established
with SA_RESTART.
To demonstrate the waitid() problem, use the following command:
./waitid_intr esc 10 2 restart
*/
#define _GNU_SOURCE
#include <sys/types.h>
#include <sys/time.h>
#include <sys/wait.h>
#include <string.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <syscall.h>
#include <unistd.h>
#include <errno.h>
#define errExit(msg) { perror(msg); exit(EXIT_FAILURE); }
#define fatalErr(msg) { fprintf(stderr, "%s\n", msg); \
exit(EXIT_FAILURE); }
static void
handler(int sig)
{
int savedErrno;
savedErrno = errno;
printf("Caught signal\n");
errno = savedErrno;
} /* handler */
#define SIG SIGUSR1
int
main(int argc, char *argv[])
{
siginfo_t info;
int options, s;
char *p;
pid_t pid;
struct rusage ru;
struct sigaction sa;
setbuf(stdout, NULL);
printf("Parent's PID is %ld\n", (long) getpid());
if (argc < 4) {
fprintf(stderr, "%s {escHW} child-secs sig-secs [sa_restart]\n",
argv[0]);
exit(EXIT_FAILURE);
}
options = 0;
for (p = argv[1]; *p != '\0'; p++) {
if (*p == 'e') options |= WEXITED;
else if (*p == 's') options |= WSTOPPED;
else if (*p == 'c') options |= WCONTINUED;
else if (*p == 'H') options |= WNOHANG;
else if (*p == 'W') options |= WNOWAIT;
else fatalErr("Bad option letter");
}
/* Create first child to waitid() for */
pid = fork();
if (pid == -1) errExit("fork");
if (pid == 0) {
printf("child (PID = %ld) started\n", (long) getpid());
sleep(atoi(argv[2]));
printf("child (PID = %ld) finished\n", (long) getpid());
exit(EXIT_SUCCESS);
}
/* Parent falls through */
/* Set up handler for signal sent by child 2 */
sa.sa_handler = handler;
sigemptyset(&sa.sa_mask);
sa.sa_flags = (argc > 4) ? SA_RESTART : 0;
if (sigaction(SIG, &sa, NULL) == -1) errExit("sigaction");
/* Create a second child that will send parent a signal */
switch (fork()) {
case -1:
errExit("fork-2");
case 0:
sleep(atoi(argv[3]));
printf("Sending signal to parent\n");
if (kill(getppid(), SIG) == -1) errExit("kill");
exit(EXIT_SUCCESS);
default:
break;
}
/* Parent now waits for the first child */
memset(&info, 0, sizeof(siginfo_t));
s = waitid(P_PID, pid, &info, options);
//s = syscall(SYS_waitid, P_ALL, 0, &info, options, &ru);
//s = syscall(SYS_waitpid, -1, NULL, 0);
if (s == -1) errExit("waitid");
printf("waitid() returned %d\n", s);
printf(" ");
printf("si_pid=%ld; ", (long) info.si_pid);
printf("si_uid=%ld; ", (long) info.si_uid);
printf("si_signo=%ld; ", (long) info.si_signo);
printf("\n");
printf(" ");
printf("si_status=%ld; ", (long) info.si_status);
printf("si_code=%ld ", (long) info.si_code);
printf("(%s); ",
(info.si_code == CLD_EXITED) ? "CLD_EXITED" :
(info.si_code == CLD_KILLED) ? "CLD_KILLED" :
(info.si_code == CLD_DUMPED) ? "CLD_DUMPED" :
(info.si_code == CLD_TRAPPED) ? "CLD_TRAPPED" :
(info.si_code == CLD_STOPPED) ? "CLD_STOPPED" :
(info.si_code == CLD_CONTINUED) ? "CLD_CONTINUED" :
"????");
printf("\n");
} /* main */
--
Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie!
Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: waitid() fails with EINVAL for SA_RESTART signals 2005-05-18 8:20 waitid() fails with EINVAL for SA_RESTART signals Michael Kerrisk @ 2005-05-26 21:17 ` Roland McGrath 2005-05-26 22:21 ` [PATCH] i386: fix prevent_tail_call Roland McGrath 2005-05-26 22:22 ` waitid() fails with EINVAL for SA_RESTART signals Roland McGrath 2 siblings, 0 replies; 13+ messages in thread From: Roland McGrath @ 2005-05-26 21:17 UTC (permalink / raw) To: Michael Kerrisk; +Cc: linux-kernel, michael.kerrisk Your test works fine on FC4 kernels (which are pretty current), but it does hit the problem on my vanilla build. strace output suggests something is clobbering two registers: waitid(P_PID, 1740, Sending signal to parent 0xbfc8b198, WEXITED|WSTOPPED|WCONTINUED, NULL) = ? ERESTARTSYS (To be restarted) --- SIGUSR1 (User defined signal 1) @ 0 (0) --- --- SIGCHLD (Child exited) @ 0 (0) --- write(1, "Caught signal", 13Caught signal) = 13 write(1, "\n", 1 ) = 1 sigreturn() = ? (mask now []) waitid(0x6cc /* P_??? */, 14, 0xbfc8b198, 0, NULL) = -1 EINVAL (Invalid argument) I will look into it further. Thanks, Roland ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] i386: fix prevent_tail_call 2005-05-18 8:20 waitid() fails with EINVAL for SA_RESTART signals Michael Kerrisk 2005-05-26 21:17 ` Roland McGrath @ 2005-05-26 22:21 ` Roland McGrath 2005-05-26 22:22 ` waitid() fails with EINVAL for SA_RESTART signals Roland McGrath 2 siblings, 0 replies; 13+ messages in thread From: Roland McGrath @ 2005-05-26 22:21 UTC (permalink / raw) To: Andrew Morton, Linus Torvalds; +Cc: Michael Kerrisk, linux-kernel We fixed this bug before, but it didn't take. It may have been the case that the problem was first noticed to occur in a CONFIG_REGPARM compile. But it's not regparm functions that need not to make tail calls, it's asmlinkage functions called with a user pt_regs frame on the stack supplying their arguments. prevent_tail_call probably doesn't do anything at all in regparm functions (your argument registers are going to be clobbered, period). It was a braino to conditionalize that definition in the first place. Signed-off-by: Roland McGrath <roland@redhat.com> --- commit 20da6762d8c1921800686ce31b1563e3ac24880d tree cffaf6d5044bb44f13bb540d750f1e44562901e4 parent 3b54f47d661b933498f0709e5ce215d0f285e928 author Roland McGrath <roland@redhat.com> Thu, 26 May 2005 15:19:26 -0700 committer Roland McGrath <roland@redhat.com> Thu, 26 May 2005 15:19:26 -0700 asm-i386/linkage.h | 4 +--- 1 files changed, 1 insertion(+), 3 deletions(-) Index: include/asm-i386/linkage.h =================================================================== --- a2dc8eec0e30ffa0f39d2f835e018ee86387ff61/include/asm-i386/linkage.h (mode:100644) +++ cffaf6d5044bb44f13bb540d750f1e44562901e4/include/asm-i386/linkage.h (mode:100644) @@ -5,9 +5,7 @@ #define FASTCALL(x) x __attribute__((regparm(3))) #define fastcall __attribute__((regparm(3))) -#ifdef CONFIG_REGPARM -# define prevent_tail_call(ret) __asm__ ("" : "=r" (ret) : "0" (ret)) -#endif +#define prevent_tail_call(ret) __asm__ ("" : "=r" (ret) : "0" (ret)) #ifdef CONFIG_X86_ALIGNMENT_16 #define __ALIGN .align 16,0x90 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: waitid() fails with EINVAL for SA_RESTART signals 2005-05-18 8:20 waitid() fails with EINVAL for SA_RESTART signals Michael Kerrisk 2005-05-26 21:17 ` Roland McGrath 2005-05-26 22:21 ` [PATCH] i386: fix prevent_tail_call Roland McGrath @ 2005-05-26 22:22 ` Roland McGrath 2005-05-26 22:37 ` David S. Miller 2 siblings, 1 reply; 13+ messages in thread From: Roland McGrath @ 2005-05-26 22:22 UTC (permalink / raw) To: Andrew Morton, Linus Torvalds Cc: Michael Kerrisk, linux-kernel, michael.kerrisk Other machines are subject to the same risk and should have a prevent_tail_call definition too. The asm-i386/linkage.h version probably works fine for every machine. It might as well be generic, I'd say. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: waitid() fails with EINVAL for SA_RESTART signals 2005-05-26 22:22 ` waitid() fails with EINVAL for SA_RESTART signals Roland McGrath @ 2005-05-26 22:37 ` David S. Miller 2005-05-26 23:19 ` Linus Torvalds 0 siblings, 1 reply; 13+ messages in thread From: David S. Miller @ 2005-05-26 22:37 UTC (permalink / raw) To: roland; +Cc: akpm, torvalds, mtk-lkml, linux-kernel, michael.kerrisk From: Roland McGrath <roland@redhat.com> Date: Thu, 26 May 2005 15:22:17 -0700 > Other machines are subject to the same risk and should have a > prevent_tail_call definition too. The asm-i386/linkage.h version probably > works fine for every machine. It might as well be generic, I'd say. Sparc, for one, doesn't need it. We pass the pt_regs in via a pointer to the trap level stack frame which won't be released by a tail-call in C code. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: waitid() fails with EINVAL for SA_RESTART signals 2005-05-26 22:37 ` David S. Miller @ 2005-05-26 23:19 ` Linus Torvalds 2005-05-26 23:22 ` Roland McGrath 2005-05-30 16:55 ` Michael Kerrisk 0 siblings, 2 replies; 13+ messages in thread From: Linus Torvalds @ 2005-05-26 23:19 UTC (permalink / raw) To: David S. Miller; +Cc: roland, akpm, mtk-lkml, linux-kernel, michael.kerrisk On Thu, 26 May 2005, David S. Miller wrote: > > > Other machines are subject to the same risk and should have a > > prevent_tail_call definition too. The asm-i386/linkage.h version probably > > works fine for every machine. It might as well be generic, I'd say. > > Sparc, for one, doesn't need it. We pass the pt_regs in via a pointer > to the trap level stack frame which won't be released by a tail-call > in C code. x86 has largely tried to move in that direction too, ie a lot of the asm-calls have been turned into FASTCALL() with %eax pointing to the stack. Roland, I applied the patch, but if there was some particular case that triggered this, maybe it's worth trying to re-write that one. Linus ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: waitid() fails with EINVAL for SA_RESTART signals 2005-05-26 23:19 ` Linus Torvalds @ 2005-05-26 23:22 ` Roland McGrath 2005-05-27 0:03 ` Parag Warudkar 2005-05-30 16:55 ` Michael Kerrisk 1 sibling, 1 reply; 13+ messages in thread From: Roland McGrath @ 2005-05-26 23:22 UTC (permalink / raw) To: Linus Torvalds Cc: David S. Miller, akpm, mtk-lkml, linux-kernel, michael.kerrisk > x86 has largely tried to move in that direction too, ie a lot of the > asm-calls have been turned into FASTCALL() with %eax pointing to the > stack. > > Roland, I applied the patch, but if there was some particular case that > triggered this, maybe it's worth trying to re-write that one. It's a danger for any system call. Here it was sys_waitid. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: waitid() fails with EINVAL for SA_RESTART signals 2005-05-26 23:22 ` Roland McGrath @ 2005-05-27 0:03 ` Parag Warudkar 2005-05-27 0:11 ` Roland McGrath 0 siblings, 1 reply; 13+ messages in thread From: Parag Warudkar @ 2005-05-27 0:03 UTC (permalink / raw) To: Roland McGrath Cc: Linus Torvalds, David S. Miller, akpm, mtk-lkml, linux-kernel, michael.kerrisk On Thursday 26 May 2005 19:22, Roland McGrath wrote: > > x86 has largely tried to move in that direction too, ie a lot of the > > asm-calls have been turned into FASTCALL() with %eax pointing to the > > stack. > > > > Roland, I applied the patch, but if there was some particular case that > > triggered this, maybe it's worth trying to re-write that one. > > It's a danger for any system call. Here it was sys_waitid. On X86_64 the given program fails with Operation Not Supported error on waitid() - both 32bit and 64bit modes. The problem seems to be WCONTINUED - is it unimplemented on X86_64? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: waitid() fails with EINVAL for SA_RESTART signals 2005-05-27 0:03 ` Parag Warudkar @ 2005-05-27 0:11 ` Roland McGrath 2005-05-27 0:37 ` Parag Warudkar 0 siblings, 1 reply; 13+ messages in thread From: Roland McGrath @ 2005-05-27 0:11 UTC (permalink / raw) To: Parag Warudkar Cc: Linus Torvalds, David S. Miller, akpm, mtk-lkml, linux-kernel, michael.kerrisk You are using the test with an old glibc that doesn't know about the waitid systme call. Use strace to see what system calls are actually being made. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: waitid() fails with EINVAL for SA_RESTART signals 2005-05-27 0:11 ` Roland McGrath @ 2005-05-27 0:37 ` Parag Warudkar 2005-05-27 1:05 ` Parag Warudkar 0 siblings, 1 reply; 13+ messages in thread From: Parag Warudkar @ 2005-05-27 0:37 UTC (permalink / raw) To: Roland McGrath Cc: Linus Torvalds, David S. Miller, akpm, mtk-lkml, linux-kernel, michael.kerrisk On Thursday 26 May 2005 20:11, Roland McGrath wrote: > You are using the test with an old glibc that doesn't know about the waitid > systme call. Use strace to see what system calls are actually being made. I am using the current version of glibc - 2.3.4 - and man pages seem to know about the waitid sys call and WCONTINUED(Since Linux 2.6.10). Also waitid succeeds if I remove WCONTINUED flag, so it would seem that WCONTINUED is not supported on X86_64 - I am running a 2.6.11-gentoo kernel. Here is the strace output - -------------------------------------------------------------------------- strace ./a.out esc 10 2 restart execve("./a.out", ["./a.out", "esc", "10", "2", "restart"], [/* 51 vars */]) = 0 uname({sys="Linux", node="tux-gentoo", ...}) = 0 brk(0) = 0x502000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaaaac0000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=91598, ...}) = 0 mmap(NULL, 91598, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2aaaaaac1000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\310\1\0"..., 640) = 640 lseek(3, 64, SEEK_SET) = 64 read(3, "\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0"..., 616) = 616 lseek(3, 680, SEEK_SET) = 680 read(3, "\4\0\0\0\20\0\0\0\1\0\0\0GNU\0\0\0\0\0\2\0\0\0\6\0\0\0"..., 32) = 32 fstat(3, {st_mode=S_IFREG|0755, st_size=1270208, ...}) = 0 lseek(3, 64, SEEK_SET) = 64 read(3, "\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0"..., 616) = 616 mmap(NULL, 2248808, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2aaaaabc1000 mprotect(0x2aaaaacdd000, 1085544, PROT_NONE) = 0 mmap(0x2aaaaadc1000, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED| MAP_DENYWRITE, 3, 0x100000) = 0x2aaaaadc1000 mmap(0x2aaaaade2000, 16488, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED| MAP_ANONYMOUS, -1, 0) = 0x2aaaaade2000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaaade7000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaaade8000 mprotect(0x2aaaaaddc000, 12288, PROT_READ) = 0 arch_prctl(ARCH_SET_FS, 0x2aaaaade7ae0) = 0 munmap(0x2aaaaaac1000, 91598) = 0 open("/dev/urandom", O_RDONLY) = 3 read(3, ")\371\226%\260\224\'\351", 8) = 8 close(3) = 0 getpid() = 7682 write(1, "Parent\'s PID is 7682\n", 21Parent's PID is 7682 ) = 21 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2aaaaade7b70) = 7683 child (PID = 7683) started rt_sigaction(SIGUSR1, {0x400aa0, [], SA_RESTORER|SA_RESTART, 0x2aaaaabefca0}, NULL, 8) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2aaaaade7b70) = 7684 write(1, "Error Code from waitid - -1\n", 28Error Code from waitid - -1 ) = 28 dup(2) = 3 fcntl(3, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) brk(0) = 0x502000 brk(0x523000) = 0x523000 fstat(3, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 3), ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaaaac1000 lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) write(3, "waitid: Operation not supported\n", 32waitid: Operation not supported ) = 32 close(3) = 0 munmap(0x2aaaaaac1000, 4096) = 0 exit_group(1) -- Question: Is it better to abide by the rules until they're changed or help speed the change by breaking them? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: waitid() fails with EINVAL for SA_RESTART signals 2005-05-27 0:37 ` Parag Warudkar @ 2005-05-27 1:05 ` Parag Warudkar 2005-05-27 2:01 ` Parag Warudkar 0 siblings, 1 reply; 13+ messages in thread From: Parag Warudkar @ 2005-05-27 1:05 UTC (permalink / raw) To: Roland McGrath Cc: Linus Torvalds, David S. Miller, akpm, mtk-lkml, linux-kernel, michael.kerrisk On Thursday 26 May 2005 20:37, Parag Warudkar wrote: With WCONTINUED - there is no waitid in the strace output - > clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, > child_tidptr=0x2aaaaade7b70) = 7683 > child (PID = 7683) started > rt_sigaction(SIGUSR1, {0x400aa0, [], SA_RESTORER|SA_RESTART, > 0x2aaaaabefca0}, NULL, 8) = 0 > clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, > child_tidptr=0x2aaaaade7b70) = 7684 > write(1, "Error Code from waitid - -1\n", 28Error Code from waitid - -1 > ) = 28 Without WCONTINUED - >clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2aaaaade7b70) = 7898 >child (PID = 7898) started >rt_sigaction(SIGUSR1, {0x400aa0, [], SA_RESTORER|SA_RESTART, 0x2aaaaabefca0}, >NULL, 8) = 0 >clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2aaaaade7b70) = 7899 >wait4(7898, Sending signal to parent >0x7fffffffeecc, WSTOPPED, NULL) = ? ERESTARTSYS (To be restarted) >--- SIGUSR1 (User defined signal 1) @ 0 (0) --- >--- SIGCHLD (Child exited) @ 0 (0) --- >write(1, "Caught signal", 13Caught signal) = 13 >write(1, "\n", 1 >) = 1 >rt_sigreturn(0x1) = 61 It's of course beyond me why this difference - strace output should have had mention of wait4(...) = ENOTSUP (or whatever) when WCONTINUED is used. WCONTINUED is declared in include files and mentioned as supported in the man pages. Parag ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: waitid() fails with EINVAL for SA_RESTART signals 2005-05-27 1:05 ` Parag Warudkar @ 2005-05-27 2:01 ` Parag Warudkar 0 siblings, 0 replies; 13+ messages in thread From: Parag Warudkar @ 2005-05-27 2:01 UTC (permalink / raw) To: Roland McGrath Cc: Linus Torvalds, David S. Miller, akpm, mtk-lkml, linux-kernel, michael.kerrisk Ok.. Nothing wrong with the kernel - I used the syscall(...) macro with 247 as the syscall number (__NR_waitid) the program works as expected. My version of glibc might not actually support WCONTINUED. Thanks Parag ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: waitid() fails with EINVAL for SA_RESTART signals 2005-05-26 23:19 ` Linus Torvalds 2005-05-26 23:22 ` Roland McGrath @ 2005-05-30 16:55 ` Michael Kerrisk 1 sibling, 0 replies; 13+ messages in thread From: Michael Kerrisk @ 2005-05-30 16:55 UTC (permalink / raw) To: Linus Torvalds; +Cc: davem, roland, akpm, mtk-lkml, linux-kernel [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 967 bytes --] > On Thu, 26 May 2005, David S. Miller wrote: > > > > > Other machines are subject to the same risk and should have a > > > prevent_tail_call definition too. The asm-i386/linkage.h version > > > probably > > > works fine for every machine. It might as well be generic, I'd say. > > > > Sparc, for one, doesn't need it. We pass the pt_regs in via a pointer > > to the trap level stack frame which won't be released by a tail-call > > in C code. > > x86 has largely tried to move in that direction too, ie a lot of the > asm-calls have been turned into FASTCALL() with %eax pointing to the > stack. > > Roland, I applied the patch, but if there was some particular case that > triggered this, maybe it's worth trying to re-write that one. Did I miss something. Did this patch come through the list? (I didn't see it.) Cheers, Michael -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++ ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2005-05-30 16:55 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-05-18 8:20 waitid() fails with EINVAL for SA_RESTART signals Michael Kerrisk 2005-05-26 21:17 ` Roland McGrath 2005-05-26 22:21 ` [PATCH] i386: fix prevent_tail_call Roland McGrath 2005-05-26 22:22 ` waitid() fails with EINVAL for SA_RESTART signals Roland McGrath 2005-05-26 22:37 ` David S. Miller 2005-05-26 23:19 ` Linus Torvalds 2005-05-26 23:22 ` Roland McGrath 2005-05-27 0:03 ` Parag Warudkar 2005-05-27 0:11 ` Roland McGrath 2005-05-27 0:37 ` Parag Warudkar 2005-05-27 1:05 ` Parag Warudkar 2005-05-27 2:01 ` Parag Warudkar 2005-05-30 16:55 ` Michael Kerrisk
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox