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;
next prev parent 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®