From: Blaisorblade <blaisorblade@yahoo.it>
To: user-mode-linux-devel@lists.sourceforge.net,
user-mode-linux-user@lists.sourceforge.net
Cc: Jeff Dike <jdike@addtoit.com>,
Bodo Stroesser <bstroesser@fujitsu-siemens.com>
Subject: [uml-devel] Critical instability in 2.4.27-1um
Date: Tue, 29 Mar 2005 20:21:19 +0200 [thread overview]
Message-ID: <200503292021.19564.blaisorblade@yahoo.it> (raw)
[-- Attachment #1: Type: text/plain, Size: 1764 bytes --]
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
[-- Attachment #2: syscall-security-7-fix.patch --]
[-- Type: text/x-diff, Size: 1128 bytes --]
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
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;
_
[-- Attachment #3: syscall-security-7.patch --]
[-- Type: text/x-diff, Size: 1141 bytes --]
Fails when running "while /bin/true; do /bin/true; done".
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
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? */
_
reply other threads:[~2005-03-30 18:30 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200503292021.19564.blaisorblade@yahoo.it \
--to=blaisorblade@yahoo.it \
--cc=bstroesser@fujitsu-siemens.com \
--cc=jdike@addtoit.com \
--cc=user-mode-linux-devel@lists.sourceforge.net \
--cc=user-mode-linux-user@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox