[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <987664A83D2D224EAE907B061CE93D5301F527F980@orsmsx505.amr.corp.intel.com>
Date: Wed, 2 Nov 2011 13:57:26 -0700
From: "Luck, Tony" <tony.luck@...el.com>
To: "holzheu@...ux.vnet.ibm.com" <holzheu@...ux.vnet.ibm.com>,
Don Zickus <dzickus@...hat.com>
CC: Andrew Morton <akpm@...ux-foundation.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"heiko.carstens@...ibm.com" <heiko.carstens@...ibm.com>,
"kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
"schwidefsky@...ibm.com" <schwidefsky@...ibm.com>,
Vivek Goyal <vgoyal@...hat.com>
Subject: RE: [PATCH v2] kdump: Fix crash_kexec - smp_send_stop race in panic
> Instead of introducing the panic lock, as an alternative we could move
> smp_send_stop() to the beginning of panic(). Eric told me that the
> function is currently "insufficiently reliable" for that, but perhaps we
> could make it more reliable.
That's tough to do. We are in panic because something went horribly
wrong somewhere in the kernel - so we can make few assumptions about
which subsystems are still working. In the worst case (for this example)
our panic was caused by a failure in the code that sends cross-processor
interrupts ... so calling that same code to stop the other cpus is
likely to run into the same problem - perhaps causing a nested panic.
So what looks like a good fix for some panic scenarios actually makes
others worse.
-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists