* Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> Borislav,
>
> On Mon, 5 Oct 2015, Borislav Petkov wrote:
> > On Mon, Oct 05, 2015 at 02:03:58AM +0000, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > That's different from my point of view. I'm not going to pass
> > > some data from the first kernel to the second kernel. I'm just going to
> > > provide a configurable option for the second kernel to users.
> >
> > Dude, WTF?! You're adding a kernel command line which is supposed to
> > be used *only* by the kdump kernel. But nooo, it is there in the open
> > and visible to people. And anyone can type it in during boot. AND THAT
> > SHOULDN'T BE POSSIBLE IN THE FIRST PLACE!
> >
> > This information is strictly for the kdump kernel - it shouldn't be a
> > generic command line option. How hard it is to understand that simple
> > fact?!
>
> Calm down!
>
> Disabling that NMI in the first kernel is not going to make the world
> explode. We have enough command line options a user can type in, which
> are way worse than that one. If some "expert" types nonsense on the
> first kernel command line, then it's none of our problems, really.
>
> If Kawai would have marked that option as a debug feature, this
> discussion would have probably never happened.
>
> Aside of that, the best way to hand in options for the kdump kernel is
> the command line. We have an existing interface for that.
>
> Let's move on. Nothing to see here.
So Boris kind of has a point: there are numerous problems with boot options as
kexec parameter interface:
- boot option strings are not a well defined programmatic interface:
- failures are not obvious (they are often ignored)
- inserting/setting parameters is awkward as well.
- boot options are not an ABI, so when options have dual use with kexec it's easy
to break things inadvertently: without that failure being apparent other than
reintroducing obscure kexec failure modes again.
- in the booted up kexec kernel it's not really obvious which options got set by
kexec and which got set by the user - as there's no separation of namespaces.
- likewise, if the user specifies an option in conflict with a kexec requirement
it's not really obvious what's happening: the user setting should probably
dominate - I'm not sure that's the case with the current kexec code.
Boot options are basically a user interface.
On the other hand the hack of (ab-)using boot parameters as kexec parameter
passing is an existing, many years old practice and we cannot just stop it without
offering an alternative (and better!) interface first.
We could improve things by either adding a separate kexec-only parameter passing
facility (like programmatic boot parameters are) - or by creating some sort of
boot parameter alias that clearly identifies kexec parameters.
So for example when introducing 'noextnmi' we'd also add a facility to add a
'kexec_noextnmi' alias - which clearly identifies this boot parameter as a kexec
related one.
Every 'kexec' inserted parameter would be prefixed by kexec_ - and then the
separation of namespaces (and the prioritization of user vs. kexec requirements)
becomes well defined as well..
We should also probably print a warning if a kexec_* parameter is passed in that
has no matching handler in the kexec()-ed kernel.
I do concur that this patch is probably OK given existing practices.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
