From: George Anzinger <george@mvista.com>
To: Andrew Morton <andrewm@uow.edu.au>
Cc: Keith Owens <kaos@ocs.com.au>, John Kacur <jkacur@home.com>,
linux-kernel@vger.kernel.org
Subject: Re: test11-pre2 compile error undefined reference to `bust_spinlocks' WHAT?!
Date: Mon, 13 Nov 2000 09:47:02 -0800 [thread overview]
Message-ID: <3A102916.ACD71F76@mvista.com> (raw)
In-Reply-To: <23569.973832900@kao2.melbourne.sgi.com> <3A0C2D4A.83C75D4B@mvista.com> <3A0C90FD.CB645430@uow.edu.au>
[-- Attachment #1: Type: text/plain, Size: 2297 bytes --]
Andrew Morton wrote:
>
> George Anzinger wrote:
> >
> > The notion of releasing a spin lock by initializing it seems IMHO, on
> > the face of it, way off. Firstly the protected area is no longer
> > protected which could lead to undefined errors/ crashes and secondly,
> > any future use of spinlocks to control preemption could have a lot of
> > trouble with this, principally because the locker is unknown.
> >
> > In the case at hand, it would seem that an unlocked path to the console
> > is a more correct answer that gives the system a far better chance of
> > actually remaining viable.
> >
>
> Does bust_spinlocks() muck up the preemptive kernel's spinlock
> counting? Would you prefer spin_trylock()/spin_unlock()?
> It doesn't matter - if we call bust_spinlocks() the kernel is
> known to be dead meat and there is a fsck in your near future.
Well, actually this fails just as badly as the locker is not unlocking
and the preemption counts are task local... BUT, see below.
>
> We are still trying to find out why kumon@fujitsu's 8-way is
> crashing on the test10-pre5 sched.c. Looks like it's fixed
> in test11-pre2 but we want to know _why_ it's fixed. And at
> present each time he hits the bug, his printk() deadlocks.
>
> So bust_spinlocks() is a RAS feature :) A very important one -
> it's terrible when your one-in-a-trillion bug happens and there
> are no diagnostics.
>
I agree, this is why, in the preemption patch, we have an "unlocked"
printk. Attached is the relevant portion of the preemption patch for
test9.
I think it still suffers from the console lock, but it is a bit further
down the road.
The patch also illustrates why I am looking for a way to pass var args
to the next function down the line. If I had this the patch would be
WAY simple and would not duplicate the body of printf.
George
> It's a work-in-progress. There are a lot of things which
> can cause printk to deadlock:
>
> - console_lock
> - timerlist_lock
> - global_irq_lock (console code does global_cli)
> - log_wait.lock
> - tasklist_lock (printk does wake_up) (*)
> - runqueue_lock (printk does wake_up)
>
> I'll be proposing a better patch for this in a few days.
>
> (*) Keith: this explains why you can't do a printk() in
> __wake_up_common: printk calls wake_up(). Duh.
[-- Attachment #2: printk_unlocked-2.4.0-test9.patch --]
[-- Type: text/plain, Size: 1545 bytes --]
diff -urP -X patch.exclude linux-2.4.0-test9-kb-rts/kernel/printk.c linux/kernel/printk.c
--- linux-2.4.0-test9-kb-rts/kernel/printk.c Wed Jul 5 11:00:21 2000
+++ linux/kernel/printk.c Thu Nov 2 10:17:20 2000
@@ -312,6 +312,64 @@
return i;
}
+#if defined(CONFIG_KGDB) && defined(CONFIG_PREEMPT)
+asmlinkage int printk_unlocked(const char *fmt, ...)
+{
+ va_list args;
+ int i;
+ char *msg, *p, *buf_end;
+ int line_feed;
+ static signed char msg_level = -1;
+
+ va_start(args, fmt);
+ i = vsprintf(buf + 3, fmt, args); /* hopefully i < sizeof(buf)-4 */
+ buf_end = buf + 3 + i;
+ va_end(args);
+ for (p = buf + 3; p < buf_end; p++) {
+ msg = p;
+ if (msg_level < 0) {
+ if (
+ p[0] != '<' ||
+ p[1] < '0' ||
+ p[1] > '7' ||
+ p[2] != '>'
+ ) {
+ p -= 3;
+ p[0] = '<';
+ p[1] = default_message_loglevel + '0';
+ p[2] = '>';
+ } else
+ msg += 3;
+ msg_level = p[1] - '0';
+ }
+ line_feed = 0;
+ for (; p < buf_end; p++) {
+ log_buf[(log_start+log_size) & LOG_BUF_MASK] = *p;
+ if (log_size < LOG_BUF_LEN)
+ log_size++;
+ else
+ log_start++;
+
+ logged_chars++;
+ if (*p == '\n') {
+ line_feed = 1;
+ break;
+ }
+ }
+ if (msg_level < console_loglevel && console_drivers) {
+ struct console *c = console_drivers;
+ while(c) {
+ if ((c->flags & CON_ENABLED) && c->write)
+ c->write(c, msg, p - msg + line_feed);
+ c = c->next;
+ }
+ }
+ if (line_feed)
+ msg_level = -1;
+ }
+ return i;
+}
+#endif
void console_print(const char *s)
{
struct console *c;
next prev parent reply other threads:[~2000-11-13 17:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-10 5:32 test11-pre2 compile error undefined reference to `bust_spinlocks' John Kacur
2000-11-10 4:57 ` Keith Owens
2000-11-10 5:07 ` Jeff Garzik
2000-11-10 5:08 ` Keith Owens
2000-11-10 17:15 ` test11-pre2 compile error undefined reference to `bust_spinlocks' WHAT?! George Anzinger
2000-11-10 17:34 ` Keith Owens
2000-11-11 0:21 ` Andrew Morton
2000-11-11 8:50 ` Eric W. Biederman
2000-11-13 17:47 ` George Anzinger [this message]
2000-11-10 5:18 ` [patch] Re: test11-pre2 compile error undefined reference to `bust_spinlocks' 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=3A102916.ACD71F76@mvista.com \
--to=george@mvista.com \
--cc=andrewm@uow.edu.au \
--cc=jkacur@home.com \
--cc=kaos@ocs.com.au \
--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 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.