public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

-

      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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox