From: Andrew Morton <akpm@linux-foundation.org>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Gautham R Shenoy <ego@in.ibm.com>,
LKML <linux-kernel@vger.kernel.org>,
Oleg Nesterov <oleg@tv-sign.ru>
Subject: Re: 2.6.21-rc7-mm1: BUG_ON in kthread_bind during _cpu_down
Date: Wed, 25 Apr 2007 16:54:10 -0700 [thread overview]
Message-ID: <20070425165410.b73443b4.akpm@linux-foundation.org> (raw)
In-Reply-To: <200704260110.22224.rjw@sisk.pl>
On Thu, 26 Apr 2007 01:10:21 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> Hi,
>
> The BUG_ON in khthread_bind (line 165 in kthread.c) triggers for me during
> attempted suspend to disk, when disable_nonboot_cpus() calls _cpu_down()
> (on x86_64).
I guess the backtrace would be pretty important here.
Guys, please don't add BUG_ONs unless there is simply no sane way to recover.
Because when someone goofs up, the BUG_ON will kill the whole machine and
everyone else who has code being tested in -mm loses a tester.
Plus a BUG_ON *greatly* decreases our chances of getting a trace from the
tester: dead box, nothing in the logs.
--- a/kernel/kthread.c~fix-kthread_create-vs-freezer-theoretical-race-dont-be-obnoxious
+++ a/kernel/kthread.c
@@ -162,7 +162,10 @@ EXPORT_SYMBOL(kthread_create);
*/
void kthread_bind(struct task_struct *k, unsigned int cpu)
{
- BUG_ON(k->state != TASK_UNINTERRUPTIBLE);
+ if (k->state != TASK_UNINTERRUPTIBLE) {
+ WARN_ON(1);
+ return;
+ }
/* Must have done schedule() in kthread() before we set_task_cpu */
wait_task_inactive(k);
set_task_cpu(k, cpu);
_
next prev parent reply other threads:[~2007-04-25 23:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-25 23:10 2.6.21-rc7-mm1: BUG_ON in kthread_bind during _cpu_down Rafael J. Wysocki
2007-04-25 23:54 ` Andrew Morton [this message]
2007-04-26 10:09 ` Gautham R Shenoy
2007-04-26 10:15 ` Oleg Nesterov
2007-04-26 12:58 ` Gautham R Shenoy
2007-04-28 1:42 ` Andrew Morton
2007-05-01 18:48 ` [PATCH] add-suspend-related-notifications-for-cpu-hotplug-cleanup Oleg Nesterov
2007-05-01 22:56 ` libata-core.c: unsafe cancel_delayed_work() usage? Oleg Nesterov
2007-05-01 23:35 ` Jeff Garzik
2007-05-01 23:48 ` Oleg Nesterov
2007-05-03 21:38 ` kernel/relay.c: a strange usage of delayed_work Oleg Nesterov
2007-05-04 5:42 ` Tom Zanussi
2007-04-26 10:20 ` 2.6.21-rc7-mm1: BUG_ON in kthread_bind during _cpu_down Eric W. Biederman
2007-04-26 20:20 ` Rafael J. Wysocki
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=20070425165410.b73443b4.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=ego@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@tv-sign.ru \
--cc=rjw@sisk.pl \
/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.