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

[Eric W. Biederman]

Andrew Morton <akpm@xxxxxxxx> writes:

> ebiederm@xxxxxxxxxxxx (Eric W. Biederman) wrote:
> >
> > Andrew Morton <akpm@xxxxxxxx> writes:
> 
> OK.  But some (most) of them will sleep, too.  And we shouldn't sleep in a
> dead kernel.

Probably not.  And that is legitimate...

> > 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.

No but we will be running in the first 16M of memory.  The 16M that
is allocated is currently used to hold a copy of the low 16M.
 
> > So for a first pass I think calling the shutdown methods make sense.
> 
> Well.  There aren't any.

Which makes them both safe and worthless.  On the normal kexec path
they we will need to get them written though.

> > 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..

Well if calling shutdown is not really usable, then I we had better
transition quickly beyond using it...
 
> [*] At least, I _assume_ the 16MB will be prereserved,
>     physically-contiguous and wholly within ZONE_NORMAL.  Is this wrong?

The problem is that we really won't be using it for running code out
of because of i386 kernel limitations.  Unless someone can tell
my why 0 -16MB won't have DMA traffic in them.  Or how to run a kernel
at an address other than 1MB.

I suspect we can play with the initial page tables and how virtual
addresses map to physical addresses and fairly simply generate a
relocatable kernel.  I have not had a chance to investigate that
though.  Once we have that it will be trivial to run out of the
reserved 16M and many of the practical problems melt away.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/