Re: [lkcd-devel] Re: What's left over.

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

Werner Almesberger <wa@almesberger.net> writes:
> 
> But ... I think you're designing too far ahead. The "load kernel on
> panic" part isn't trivial, and I think it would be better to tackle
> this in a second phase. For now, having a reasonably generic kexec
> mechanism would be all that's needed in term of building blocks.

I'm not designing yet, just looking and what I see says that it
does not very much resemble the non panic case.
 
> > Method 2 (For people with read only roots):
> > - /sbin/delayed_kexec /path/to/new/kernel 
> > - Read in the /path/to/new/kernel into anonymous pages
> 
> There's no delayed_kexec in kexec-tools 1.4, so let me gues how
> this would work: as far as I know, there's no way for regular
> user space to create a persistent unreferenced memory object, so
> you'd probably load the data, perhaps mlock the pages, and then
> fork a process that keeps the data in memory. Then, this process
> would probably call sys_kexec upon reception of a signal, or
> such.

What I was thinking is that the process would for and exec
something like "/etc/rc 6" or maybe "/etc/rc 7" to be clean.
And that script would do all of the user space shutdown.

No need to mlock any pages, or hack init, or special hacks.
Just user space cleanly shutting itself down.

> 
> > I then use the following algorithm to sort the potential mess out
> > before I jump to the new code.
> 
> I like this approach. It gives you complete freedom of where to
> load data. This also makes it future-proof. But I don't see the
> reason why you couldn't do the same thing with vmalloc. Using
> vmalloc may actually simplify your code a little.

Mostly it's a bird in the hand versus a bird in the bush.  I simply
see nowhere that vmalloc makes my code simpler.

> > Having had time to digest the idea of starting a new kernel on panic
> > I can now make some observations and what I believe it would take to
> > make it as robust as possible.
> 
> That pretty much sums it up, yes. But as I've said, this isn't
> really something that needs to be implemented at the same time
> as the basic kexec functionality. A two-phase kexec with
> unrestricted copying capabilities should be a good enough
> building block that only minor changes, if any, would be needed
> when adding kexec-on-panic.

My feel is that kexec-on-panic is a rather different problem.  Which
is why I thought it all through, to see if they felt close.  At the
very least you almost need to know that it is the same.

> 
> > And now I go back to the silly exercise of factoring my code so the
> > new kernel can be kept in locked kernel memory, instead of in a file
> > while the shutdown scripts are run.
> 
> Not silly :-)

Except for the part about getting Linus to accept it I don't see
the advantage.  kexec-on-panic looks different enough that I don't
think it will help at all with that case.

Eric