mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Roland Dreier <roland@digitalvampire.org>
To: Andrew Morton <akpm@osdl.org>
Cc: torvalds@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Linux 2.6.0-test8 __might_sleep warnings on boot
Date: 18 Oct 2003 17:11:28 -0700	[thread overview]
Message-ID: <87d6cuozm7.fsf@love-shack.home.digitalvampire.org> (raw)
In-Reply-To: <20031018161439.484915f8.akpm@osdl.org>

    Andrew> We already have the `system_running' flag which is
    Andrew> suitable for this.

OK, an alternate patch is below (also tested on my system).  I felt
that my first patch, which added the "init_idle_done" flag, was nice
because the flag gets set exactly when might_sleep() becomes valid,
and everything is contained in kernel/sched.c.  On the other hand, I
can see why not adding yet another flag is nice, too.  It's a matter
of taste, I guess.

    Andrew> I've been dithering over whether we should use it, mainly
    Andrew> because doing things like downing a semaphore before we've
    Andrew> even called sched_init() (cpufreq) is a
    Andrew> happens-to-be-harmless but fairly dumb thing to do.

True, but fixing some of the problems will be pretty ugly.  For
example, to fix the warning from kmem_cache_init:

    Debug: sleeping function called from invalid context at mm/slab.c:1857
    in_atomic():1, irqs_disabled():0
    Call Trace:
     [<c0105000>] _stext+0x0/0x30
     [<c011aea8>] __might_sleep+0x88/0xa0
     [<c013e708>] kmem_cache_alloc+0x1d8/0x1e0
     [<c011d531>] printk+0x121/0x150
     [<c0105000>] _stext+0x0/0x30
     [<c013d059>] kmem_cache_create+0x169/0x6a0
     [<c03019c0>] mem_init+0x1a0/0x210
     [<c0105000>] _stext+0x0/0x30
     [<c030469e>] kmem_cache_init+0x11e/0x2c0
     [<c02fa6d8>] start_kernel+0xb8/0x150
     [<c02fa4e0>] unknown_bootoption+0x0/0x110

We would probably have to change lots of stuff in mm/slab.c, including
kmem_cache_create(), since right now it unconditionally does

        /* Get cache's description obj. */
        cachep = (kmem_cache_t *) kmem_cache_alloc(&cache_cache, SLAB_KERNEL);

which will trigger a might_sleep.  Maybe the least bad way to fix that
would be to do something like

        if (system_running)
                cachep = (kmem_cache_t *) kmem_cache_alloc(&cache_cache, SLAB_KERNEL);
        else
                cachep = (kmem_cache_t *) kmem_cache_alloc(&cache_cache, SLAB_ATOMIC);

which strikes me as pretty ugly.  And there would be other changes in slab.c ...

Similarly, for the register_console() warning, I guess we would change
register_console to do

        if (system_running)
                acquire_console_sem();

        /* ... */

        if (system_running)
                release_console_sem();

in kernel/printk.c.  Let me know if you'd like a patch like that, I
can cook it up.

    Andrew> Yes, we should probably do something like this, but later.

I've already seen several more reports of this problem on lkml.  I
definitely think this should be fixed for -test9 and possibly even
-test8-mm1 -- otherwise you're going to continue to get reports of
this.  Nobody likes seeing tracebacks in their kernel messages.  Your
call though, obviously...

 - Roland

--- linux-2.6.0-test8/kernel/sched.c~early_might_sleep	Sat Oct 18 11:54:24 2003
+++ linux-2.6.0-test8/kernel/sched.c	Sat Oct 18 16:44:14 2003
@@ -2847,8 +2847,12 @@ void __might_sleep(char *file, int line)
 {
 #if defined(in_atomic)
 	static unsigned long prev_jiffy;	/* ratelimiting */
+	extern int system_running;
 
-	if (in_atomic() || irqs_disabled()) {
+	/* Don't print warnings until system_running is set.  This avoids
+	   spurious warnings during boot before local_irq_enable() and
+	   init_idle(). */
+	if (system_running && (in_atomic() || irqs_disabled())) {
 		if (time_before(jiffies, prev_jiffy + HZ) && prev_jiffy)
 			return;
 		prev_jiffy = jiffies;

  reply	other threads:[~2003-10-19  0:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-18 21:38 Roland Dreier
2003-10-18 23:14 ` Andrew Morton
2003-10-19  0:11   ` Roland Dreier [this message]
2003-10-19  0:21     ` Andrew Morton
2003-10-19  1:19       ` Roland Dreier
2003-10-19  1:53         ` Jesper Juhl
2003-10-19 19:17           ` Roland Dreier
2003-10-20  8:28             ` Jesper Juhl

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=87d6cuozm7.fsf@love-shack.home.digitalvampire.org \
    --to=roland@digitalvampire.org \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.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

all inboxes | Powered by JetHome®