On Sat, Nov 24, 2012 at 11:50 AM, H. Peter Anvin <h...@zytor.com> wrote: > On 11/24/2012 09:32 AM, H. Peter Anvin wrote: >> >> On 11/24/2012 04:37 AM, Eric W. Biederman wrote: >>> >>> >>> Certainly /sbin/kexec isn't bothering to calculate the end of the setup >>> header and just being far more conservative and using all of the 16bit >>> real mode code as it's initializer. >>> >> >> That's not conservative... that's just plain wrong. It means you're >> initializing the fields in struct boot_params with garbage instead of a >> predictable value (zero). >> >> We could work around it with a sentinel hack... except you *also* >> probably modify *some* fields and now we have a horrid mix of >> initialized and uninitialized fields to sort out... and there really >> isn't any sane way for the kernel to sort that out. >> >> We have a huge problem on our hands now because of it. >> > > So, given the mess we now have on our hands... any suggestions how to best > solve it? There is the option of simply declaring old kexec binaries > broken; they will then not work reliably with newer kernels, if they even > work reliably now -- it is hard to know for certain.
yes, if the user updates kernel to be kexeced, then would be reasonable to ask them to update kexec-tools. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
