On 12/18/14 at 10:34am, WANG Chao wrote:
On 12/17/14 at 04:45pm, Dave Young wrote:
> On 12/17/14 at 04:40pm, Dave Young wrote:
> > On 12/16/14 at 11:23am, Prarit Bhargava wrote:
> > >
> > >
> > > On 11/17/2014 03:48 PM, Vivek Goyal wrote:
> > > > On Mon, Nov 17, 2014 at 11:13:50AM -0500, Prarit Bhargava wrote:
> > > >> With the inclusion of 'panic_on_warn',
> > > >>
> > > >>
http://marc.info/?l=linux-api&m=141570937328528&w=2
> > > >>
> > > >> and which is now staged in Andrew Morton's tree, we need to
remove
> > > >> 'panic_on_warn' from the 2nd kernel's cmdline. If it
is included it is
> > > >> possible a non-fatal warning could panic the second kernel.
> > > >
> > > > This patch looks good to me. I think we can commit it once it show
> > > > up in Linus tree.
> > > >
> > > > Acked-by: Vivek Goyal <vgoyal(a)redhat.com>
> > >
> > > Dave and Vivek (who is on PTO),
> > >
> > > The panic_on_warn patch has been committed into linux.git as
> > > 9e3961a0979817c612b10b2da4f3045ec9faa779 ("kernel: add
panic_on_warn").
> >
> > Prarit, rethink about it. How about do something in kexec-tools c code to
remove
> > panic_on_warn for kdump kernel boot? Since it is for not only rh distribution
> > it will save time for other people who do not notice the changes.
>
> We already have below:
> kexec-tools/kexec/kexec.c:
> 1055 if (kexec_flags & KEXEC_ON_CRASH)
> 1056 remove_parameter(line, "crashkernel");
I don't think so. crashkernel=X is mandatory in kernel cmdline for
1st kernel, but 2nd kernel definitely do not want it. That's why we have
to remove it at any case. That's why we do it in kexec.c
I don't think it's a good idea to hard code removal of other kernel
parameters which won't hurt 2nd kernel, like panic_on_warn or something
like that. It's rare that one needs panic_on_warn on purpose in 2nd
kernel. But we shouldn't make the assumption that no one needs it.
IMHO panic_on_warn is useless in 2nd kernel, it will cause vmcore capture failed
due to some minor issues which can be ignored. It is harmful actually, if one
forget to remove it in 2nd kernel cmdline he maybe has never chance to redo
it again because bugs are not easily reproduced sometimes.
You mentioned one can use it by purpose, but it can not convince me,
head-scratching :)
I think it's better to do it in our kexec-tools as a distribution
specific manner.
Do it in distribution is good, but I do like it in upstream.
Thanks
Dave