From: Andrew Morton <akpm@zip.com.au>
To: Robert Kuebel <kuebelr@email.uc.edu>
Cc: jgarzik@mandrakesoft.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 8139too reparent_to_init() race
Date: Sun, 28 Oct 2001 17:24:20 -0800 [thread overview]
Message-ID: <3BDCAFC4.EBA4E785@zip.com.au> (raw)
In-Reply-To: <20011028200153.A331@cartman>
Robert Kuebel wrote:
>
> hello all,
>
> lately i noticed this message during boot-up (when the network
> interfaces were being configured) ...
>
> "task `ifconfig' exit_signal 17 in reparent_to_init"
>
> this happens only about 1/2 of the time.
>
> after some digging this is what i found...
> sometimes ifconfig's parent exits before ifconfig reaches
> rtl8139_thread(). when this happens, ifconfig's exit_signal is set to
> SIGCHLD (in forget_original_parent), because its new parent is init.
> then rlt8139_thread() is reached it calls reparent_to_init(), which
> complains that exit_signal is already non-zero.
>
> basically this patch stops rtl8139_thread() from calling
> reparent_to_init() when its parent is already init.
>
Thanks - that's a useful analysis.
The check in reparent_to_init() was to warn about the situation
where someone had deliberately set the exit signal to some
non-zero value and then the child calls reparent_to_init() - it's
telling you that we're about to stomp on your chosen exit signal.
I hadn't thought about the forget_original_parent() case.
So the fix should be to change the debug code in reparent_to_init()
so it doesn't complain if the exit signal is already SIGCHLD. Or
just kill it off altogether.
--- linux-2.4.14-pre3/kernel/sched.c Tue Oct 23 23:09:48 2001
+++ linux-akpm/kernel/sched.c Sun Oct 28 17:23:26 2001
@@ -1250,11 +1250,6 @@ void reparent_to_init(void)
SET_LINKS(this_task);
/* Set the exit signal to SIGCHLD so we signal init on exit */
- if (this_task->exit_signal != 0) {
- printk(KERN_ERR "task `%s' exit_signal %d in "
- __FUNCTION__ "\n",
- this_task->comm, this_task->exit_signal);
- }
this_task->exit_signal = SIGCHLD;
/* We also take the runqueue_lock while altering task fields
-
prev parent reply other threads:[~2001-10-29 1:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-29 1:01 [PATCH] 8139too reparent_to_init() race Robert Kuebel
2001-10-29 1:24 ` Andrew Morton [this message]
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=3BDCAFC4.EBA4E785@zip.com.au \
--to=akpm@zip.com.au \
--cc=jgarzik@mandrakesoft.com \
--cc=kuebelr@email.uc.edu \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.