Re: [RFC V2 PATCH 0/1] kexec: crash_kexec_post_notifiers boot option related fixes

[Eric W. Biederman]

"æåèå / KAWAIïHIDEHIRO"  <hidehiro.kawai.ez@xxxxxxxxxxx> writes:

> Hello,
>
> Thanks for the reply.
>
>> From: Eric W. Biederman [mailto:ebiederm@xxxxxxxxxxxx]
> [...]
>> A specific hook for a very specific purpose when there is no other way
>> we can consider.
>
> So, is kmsg_dump like feature admissible?
>
>> If you don't have something that generalises well into a general purpose
>> operation that it makes sense for everyone to call you can always use
>> the world's largest aka you can run code before the new kernel starts
>> that is loaded with kexec_load.
>
> One of our purposes, notifying "I'm dying", would be achieved by purgatory
> code provided by kexec command as I stated before.  Since the way of the
> notification will differ from each vendor, I think we need to modify
> the purgatory codes pluggable.  Also, I think we need some parameter
> passing mechanism to the purgatory code.  For example, passing the panic
> message via boot parameter to save it to SEL.  Although I'm not sure
> we can do that (I've not investigated well yet).  Is that acceptable?

I think the address of panic message is available in crash notes.  If
not that is very reasonable to add.

Updating the SEL from purgatory after purgatory has validated the
checksums of the crash handling code is acceptable.

All that is desired is to run as little code as possible in a kernel
that is known broken.  Once the checksums have verified things in
purgatory you should be in good shape, and there is no possibility of
relying on broken infrastructure because that code simply is not present
in purgatory.

We already have a few early_printk style drivers in purgatory and I
don't the code to update the SEL would be much worse.

On the flip side there are enough firmware bugs that I personally would
not want to rely on firmware code running properly when the machine is
in a known broken state, so I don't want the SEL update to be
unconditional.

Eric


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/