Messages in this thread | | | Date | Wed, 28 Jul 2004 18:09:54 -0700 | From | Andrew Morton <> | Subject | Re: [Fastboot] Re: Announce: dumpfs v0.01 - common RAS output API |
| |
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?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |