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

[ebiederm@xmission.com (Eric W. Biederman)]

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. 

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

Again.  If a shutdown method does that it is a BUG.  Only the remove method
should do that.  

If I actually believed that shutdown methods existed, and did that 
I would be in favor of writing a patch to test for any accesses of
memory management or sysfs/kobject/procfs release stuff and BUG
if it happened.

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

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

For a second pass we need to use a relocatable that can do everything itself.
And we should run it out of a reserved area of memory.

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.

Eric