From: Andi Kleen <ak@muc.de>
To: Andrew Morton <akpm@digeo.com>
Cc: "Martin J. Bligh" <mbligh@aracnet.com>,
ak@muc.de, linux-kernel@vger.kernel.org, rddunlap@osdl.org
Subject: Re: garbled oopsen
Date: Thu, 8 May 2003 09:29:17 +0200 [thread overview]
Message-ID: <20030508072917.GA21868@averell> (raw)
In-Reply-To: <20030507225310.609ae215.akpm@digeo.com>
On Thu, May 08, 2003 at 07:53:10AM +0200, Andrew Morton wrote:
> A recursive oops is easy enough to detect anyway.
>
> preempt_disable();
> if (oops_cpu == -1 || oops_cpu != smp_processor_id()) {
> _raw_spin_lock(&oops_lock);
> oops_cpu = smp_processor_id();
> }
> <current stuff>
> oops_cpu = -1;
> spin_lock_init(&oops_lock);
> preempt_enable();
>
> or something like that.
yes I did it this way in my old 2.4 x86-64 patch. But i never
felt comfortable enough about it to commit it.
(the in_interrupt thing was to avoid an interrupt stack problem on
x86-64, not needed anymore or on i386)
But I would prefer the spinlock timeout I think. It's an safer and more
obviously correct algorithm.
-Andi
Index: arch/x86_64/mm/fault.c
===================================================================
RCS file: /home/cvs/Repository/linux/arch/x86_64/mm/fault.c,v
retrieving revision 1.33
diff -u -u -r1.33 fault.c
--- arch/x86_64/mm/fault.c 2002/10/02 15:41:14 1.33
+++ arch/x86_64/mm/fault.c 2003/01/13 08:42:35
@@ -30,6 +30,9 @@
#include <asm/proto.h>
#include <asm/kdebug.h>
+spinlock_t pcrash_lock;
+int crashing_cpu;
+
extern spinlock_t console_lock, timerlist_lock;
void bust_spinlocks(int yes)
@@ -251,6 +254,14 @@
console_verbose();
bust_spinlocks(1);
+ if (!in_interrupt()) {
+ if (!spin_trylock(&pcrash_lock)) {
+ if (crashing_cpu != smp_processor_id())
+ spin_lock(&pcrash_lock);
+ }
+ crashing_cpu = smp_processor_id();
+ }
+
if (address < PAGE_SIZE)
printk(KERN_ALERT "Unable to handle kernel NULL pointer dereference");
else
@@ -259,7 +270,14 @@
printk(" printing rip:\n");
printk("%016lx\n", regs->rip);
dump_pagetable(address);
+
die("Oops", regs, error_code);
+
+ if (!in_interrupt()) {
+ crashing_cpu = -1; /* small harmless window */
+ spin_unlock(&pcrash_lock);
+ }
+
bust_spinlocks(0);
do_exit(SIGKILL);
next prev parent reply other threads:[~2003-05-08 7:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20030508011013$3d80@gated-at.bofh.it>
[not found] ` <20030508015008$481c@gated-at.bofh.it>
2003-05-08 2:49 ` garbled oopsen Andi Kleen
2003-05-08 3:32 ` Martin J. Bligh
2003-05-08 5:53 ` Andrew Morton
2003-05-08 7:29 ` Andi Kleen [this message]
2003-05-08 6:44 ` Andi Kleen
2003-05-08 1:05 Randy.Dunlap
2003-05-08 1:40 ` Andrew Morton
2003-05-08 0:06 ` Martin J. Bligh
2003-05-08 4:34 ` Randy.Dunlap
2003-05-19 7:20 ` Keith Owens
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=20030508072917.GA21868@averell \
--to=ak@muc.de \
--cc=akpm@digeo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@aracnet.com \
--cc=rddunlap@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