While testing the 2.4.27-bs2 prerelease, I discovered that when I run, at a
login shell, this amazingly difficult stress-test:
while /bin/true; do /bin/true; done
makes the login shell exit back to the login prompt, after some time (so it's
a race condition).
I've analyzed this and discovered that it's caused by the 2.4.27-1um security
fixes, which I incorporated in that tree.
I think that Jeff and Bodo has an idea about this, because in a chat between
me, him and Bodo, he said that in 2.6, with this stripped-down set of
security fixes, he was seeing problems (maybe wrong return values) with
fork()/vfork(). (Nobody mentioned this test case however).
I didn't understand fully the problems at that time, however.
I've verified this with a 2.4.27-1um vanilla tree, too.
From looking at the code, it's probably related to syscall-security-6 (IIRC it
was somehow related to handle_signal). And in fact, I can fix this by removing
the two attached patches.
This was subsequently fixed by merging all the rest of the work, since Bodo
noted that the full patchset didn't have the mentioned problem (and in a
improved form, since the 2.6.10 is more stable than 2.6.9-bs7 for some users,
notably Rob Landley who is using TT mode).
So I guess this should be fixed by backporting all that stuff to 2.4.
For now, I can't, so I'm going to release 2.4.27-2um excluding the attached
problematic patches. syscall-security-7 stems from syscall-security-6, while
syscall-security-7-fix is a couple of fixes extracted from the released
2.4.27-1um patch which are missing in the official splitout.
--
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
um-linux-2.4.27-paolo/arch/um/kernel/signal_kern.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff -puN arch/um/kernel/signal_kern.c~syscall-security-6-fix arch/um/kernel/signal_kern.c
--- um-linux-2.4.27/arch/um/kernel/signal_kern.c~syscall-security-6-fix 2005-03-29 19:41:21.000000000 +0200
+++ um-linux-2.4.27-paolo/arch/um/kernel/signal_kern.c 2005-03-29 19:41:21.000000000 +0200
@@ -47,14 +47,15 @@ static void force_segv(int sig)
*/
static int handle_signal(struct pt_regs *regs, unsigned long signr,
struct k_sigaction *ka, siginfo_t *info,
- sigset_t *oldset, int error)
+ sigset_t *oldset)
{
__sighandler_t handler;
void (*restorer)(void);
unsigned long sp;
sigset_t save;
- int err, ret;
+ int error, err, ret;
+ error = PT_REGS_SYSCALL_RET(¤t->thread.regs);
ret = 0;
switch(error){
case -ERESTARTNOHAND:
@@ -131,7 +132,6 @@ static int kern_do_signal(struct pt_regs
{
siginfo_t info;
struct k_sigaction *ka;
- int err;
if (!oldset)
oldset = ¤t->blocked;
_
Fails when running "while /bin/true; do /bin/true; done".
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
um-linux-2.4.27-paolo/arch/um/kernel/signal_kern.c | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
diff -puN arch/um/kernel/signal_kern.c~syscall-security-7 arch/um/kernel/signal_kern.c
--- um-linux-2.4.27/arch/um/kernel/signal_kern.c~syscall-security-7 2005-03-29 19:41:25.000000000 +0200
+++ um-linux-2.4.27-paolo/arch/um/kernel/signal_kern.c 2005-03-29 19:41:25.000000000 +0200
@@ -114,12 +114,8 @@ static int handle_signal(struct pt_regs
else
err = setup_signal_stack_sc(sp, signr, (unsigned long) handler,
restorer, regs, &save);
- if(err) goto segv;
-
- return(0);
- segv:
- force_segv(signr);
- return(1);
+ if(err)
+ force_segv(signr);
}
/*
@@ -229,8 +225,8 @@ static int kern_do_signal(struct pt_regs
}
/* Whee! Actually deliver the signal. */
- err = handle_signal(regs, signr, ka, &info, oldset, error);
- if(!err) return(1);
+ handle_signal(regs, signr, ka, &info, oldset);
+ return(1);
}
/* Did we come from a system call? */
_
