public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Robert Love <rml@tech9.net>
To: Ingo Molnar <mingo@elte.hu>
Cc: Steven Cole <elenstev@mesatop.com>,
	torvalds@transmeta.com, linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@digeo.com>, Steven Cole <scole@lanl.gov>
Subject: Re: [PATCH] kernel BUG at sched.c:944! only with CONFIG_PREEMPT=y]
Date: 12 Sep 2002 16:45:43 -0400	[thread overview]
Message-ID: <1031863543.3837.110.camel@phantasy> (raw)
In-Reply-To: <Pine.LNX.4.44.0209122242300.21936-100000@localhost.localdomain>

On Thu, 2002-09-12 at 16:44, Ingo Molnar wrote:

> it *is* a great debugging check, at zero added cost. Scheduling from an
> atomic region *is* a critical bug that can and will cause problems in 99%
> of the cases. Rather fix the asserts that got triggered instead of backing
> out useful debugging checks ...

There are a lot of shitty drivers that this is going to catch.  Yes,
that is great... but we cannot BUG().  There really are a LOT of them. 
In the least, we need to show_trace().

Anyhow, this currently will catch _all_ kernel preemptions because the
PREEMPT_ACTIVE flag is set.

We need to do something like the attached (untested), at the very
least...

I would prefer to make this a kernel debugging check, however.  Or, make
using kernel preemption the default.  Using the "free" abilities of
kernel preemption is great, but not at the expense of its users.

	Robert Love

diff -urN linux-2.5.34/kernel/sched.c linux/kernel/sched.c
--- linux-2.5.34/kernel/sched.c	Thu Sep 12 16:26:23 2002
+++ linux/kernel/sched.c	Thu Sep 12 16:42:59 2002
@@ -940,8 +940,10 @@
 	struct list_head *queue;
 	int idx;
 
-	if (unlikely(in_atomic()))
-		BUG();
+	if (unlikely(in_atomic() && preempt_count() != PREEMPT_ACTIVE)) {
+		printk(KERN_ERROR "schedule() called while non-atomic!\n");
+		show_stack(NULL);
+	}
 
 #if CONFIG_DEBUG_HIGHMEM
 	check_highmem_ptes();
@@ -959,7 +961,7 @@
 	 * if entering off of a kernel preemption go straight
 	 * to picking the next task.
 	 */
-	if (unlikely(preempt_count() & PREEMPT_ACTIVE))
+	if (unlikely(preempt_count() == PREEMPT_ACTIVE))
 		goto pick_next_task;
 
 	switch (prev->state) {


  reply	other threads:[~2002-09-12 20:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3D80EF3F.D82B9CB9@digeo.com>
     [not found] ` <1031862049.2799.402.camel@spc9.esa.lanl.gov>
2002-09-12 20:35   ` [PATCH] kernel BUG at sched.c:944! only with CONFIG_PREEMPT=y] Robert Love
2002-09-12 20:44     ` Ingo Molnar
2002-09-12 20:45       ` Robert Love [this message]
2002-09-12 20:58         ` Steven Cole
2002-09-13  7:19         ` Ingo Molnar
2002-09-13  7:36           ` Robert Love
2002-09-13  7:40             ` Robert Love
2002-09-13 11:56               ` Thunder from the hill
2002-09-12 21:08       ` Andrew Morton

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=1031863543.3837.110.camel@phantasy \
    --to=rml@tech9.net \
    --cc=akpm@digeo.com \
    --cc=elenstev@mesatop.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=scole@lanl.gov \
    --cc=torvalds@transmeta.com \
    /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