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

Andrew Morton
2004-07-29T01:12:18Z

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?