On Thu, 2002-11-07 at 08:50, Eric W. Biederman wrote:
> panic does not call sys_reboot it rolls that functionality by hand.
> And to a certain extent it makes sense for panic to take a different
> path because we know something is badly wrong so we need to be extra
However both of them should use the same end point routines and the
hooks should go there
> reboots or panics. This memory is not accounted for anywhere so no
> one can see that we have it allocated, which makes debugging hard.
> Additionally in locking up megabytes for a long period of time we
> create unsolvable fragmentation issues for the mm layer to deal with.
We have an MMU so if you just n thousand "get me a page" calls its quite
> In a unified design I can buffer the image in the anonymous pages of a
> user space process just as well as I can in locked down kernel memory.
> So factoring sys_kexec in to load and execute pieces only helps for
> executing the new image on a kernel panic, and that case does not
> actually work.
What if your user space is swapped out - you can't page it back in
> - How should the pages allocated to an early loaded image be accounted
Just get_free_page them - if you can handle it over 4Gb then specify
that high pages are fine and kmap them to copy into them - that makes
the VM on giant boxes way happier. For bonus points also adjust the
virtual memory accounting.
> - How do we avoid making life hard for the mm system with an early
> loaded image?
Not really, especially if you are allowing high pages
> - Is it safe to call sys_reboot from panic?
No but both can call sys_machine_restart or whatever
> - Can we simply factor out the sequence:
> notifier_call_chain(&reboot_notifier_list, SYS_RESTART, NULL);
> system_running = 0;
> And place it into it's own subroutine?
Don't do that sequence on a panic IMHO (this is a standing issue, we
should not pass NULL but REBOOT/PANIC/KEXEC/... so the drivers can make
that decision - then we can do it right
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Nov 15 2002 - 22:00:16 EST