Re: [Fastboot] Re: Announce: dumpfs v0.01 - common RAS output API

[Andrew Morton <akpm@osdl.org>]

ebiederm@xmission.com (Eric W. Biederman) wrote:
>
> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> 
> > On Mer, 2004-07-28 at 21:33, Andrew Morton wrote:
> > > We really don't want to be calling driver shutdown functions from a crashed
> > > kernel.
> > 
> > Then at the very least you need to disable bus mastering and have
> > specialist recovery functions for problematic devices. The bus
> > mastering one is essential otherwise bus masters will continue to
> > DMA random data into your new universe.
> > 
> > Other stuff like graphics cards and IDE may need care too.
> 
> Alan if we call anything the shutdown methods really are the thing
> to call.  Because they are exactly the specialty recovery functions for
> problematic devices.
> 
> Of course no matter what we do will this work 100% of the time because
> part of what we will be fighting is broken hardware.  However we should
> be able to get a mechanism that works most of the time.

Shutdown methods will typically call into the slab allocator and the page
allocator to free stuff, and they are pretty common sources of oopses. 
Often with locks held.  You run an excellent change of deadlocking.

Possibly one could add

#ifdef CONFIG_WHATEVER
	if (unlikely(oops_in_progress))
		return;
#endif

to the relevant entry points.

The shutdown routines may also call into sysfs/kobject/procfs release entry
points, and they're even more popular oops sites.

We really want to get into the new kernel ASAP and clean stuff up from
in there.