Re: [ANNOUNCE][CFT] kexec for v2.5.48 && kexec-tools-1.7 -- Success Story!

Eric W. Biederman
2002-11-20T16:43:40Z

Werner Almesberger <wa@almesberger.net> writes:

> Eric W. Biederman wrote:
> > The needed hooks are there. You can make certain an appropriate
> > ->shutdown()/reboot_notifier method is present, or you can fix the driver
> > so it can initialize the device from any random state.
>
> In the case of a crash, you may not be able to use the normal
> shutdown, but there may still be pending bus master accesses, e.g.
> from an on-going transfer, or free buffers that will eventually
> (i.e. there's no use in "waiting for the operation to finish") get
> used.
>
> Initializing the device from any state is certainly a good feature,
> and it will cure the most visible symptoms, but problems may still
> occur if the device decides to scribble over memory after leaving
> the original kernel, and before the reset has occurred under the
> new kernel. (Or did you mean to initialize before invoking kexec ?

In this case I suspect the best route is to locate the kexec_on_panic
buffers for kexec where we want to use them. Then even in most
cases a devices is scribbling on memory, unless the device was
improperly setup, it isn't scribbling on memory necessary to get
the new kernel going.

> I see several possible approaches for this:
>
> 0) do as bootimg did, and ignore the problem :-)
> 1) try to call the regular device shutdown. In the case of a
> crash, this may hang, or corrupt the system further.
> 2) add a new callback that just silences the device, without
> trying to clean things up. This is probably the best
> long-term solution.

Roughly that is ->shutdown() it was separated from the ->remove()
case so that it could be stripped down to a minimal implementation.

Eric