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

[Andrew Morton <akpm@osdl.org>]

ebiederm@xmission.com (Eric W. Biederman) wrote:
>
> Andrew Morton <akpm@osdl.org> writes:
> 
> > 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.
> 
> Hmm..  Last I looked shutdown methods typically don't exist at all.
> The shutdown methods are explicitly separated from the remove methods
> for exactly this reason.  It is a BUG for any shutdown method to
> free memory.  Their only function is to shutdown the hardware. 

OK.  But some (most) of them will sleep, too.  And we shouldn't sleep in a
dead kernel.

> > We really want to get into the new kernel ASAP and clean stuff up from
> > in there.
> 
> I agree.  However the gymnastics for doing that have not been worked out.
> The drivers cannot clean up stuff yet, nor do we have a good way to run
> in memory where DMA transfers on not ongoing.

Don't we?  The 16M of memory was allocated up-front at kexec load time[*],
so nobody will be pointing DMA hardware at it.  And the dump kernel won't
be pointing DMA hardware at the crashed kernel's pages.

> So for a first pass I think calling the shutdown methods make sense.

Well.  There aren't any.

> But the first pass is worth it (at least in the kexec tree) to sort out all
> of the interface issues and catch the low hanging fruit.

A significant proportion of kernel crashes happen from [soft]irq context,
from which we cannot call shutdown methods.  So we need to be able to bring
up the dump kernel without having run driver shutdown functions anwyay..

[*] At least, I _assume_ the 16MB will be prereserved,
    physically-contiguous and wholly within ZONE_NORMAL.  Is this wrong?