lkml.org 
[lkml]   [1999]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
Subject[PATCH] 2.2.x bugfix (signal handling)
Hi,

I've found a bug in kernel/signal.c, which causes unkillable processes,
increasing load by 1 for each instance of such process.

When process is exiting, it's state is changed to TASK_ZOMBIE in
do_exit(). After this, signals are sent to the parent process and
to the actual process group. We made some changes to the signal
delivering code, which contained re-scheduling. After return into
do_exit(), current process had TASK_RUNNING set, because of queued
signals. This caused infinite loop. I understand that this is my fault
(due to rescheduling), but I noticed such tasks on server running original
kernel (2.2.9, 2.2.10) sometimes - it's heavy loaded server and many users
are doing many things there, which may cause re-scheduling after
state-change at places, where author assumed that state of process will
remain unchanged.

This have to be true for the zombies, so I propose following patch
to the kernel/signal.c:

--- signal.c.orig Tue Sep 7 17:23:50 1999
+++ signal.c Tue Sep 7 17:25:22 1999
@@ -260,6 +260,10 @@
ret = -EINVAL;
if (sig < 0 || sig > _NSIG)
goto out_nolock;
+ /* Zombie task cannot be killed! <marek@fornax.elf.stuba.sk> */
+ ret = -ESRCH;
+ if ( t->state == TASK_ZOMBIE )
+ goto out_nolock;
/* The somewhat baroque permissions check... */
ret = -EPERM;
if ((!info || ((unsigned long)info != 1 && SI_FROMUSER(info)))
Let me know, if I got it wrong.

Thanks,
Marek Zelem

--
e-mail: marek@fornax.elf.stuba.sk
marek.zelem@pobox.sk
web: http://fornax.elf.stuba.sk/~marek/
pgp key: http://fornax.elf.stuba.sk/~marek/pgp.txt



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.028 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site