Documentation/admin-guide/kernel-parameters.txt | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-)
Be more clear about the downsides, the upsides (yes, there are some!)
and about code that unconditionally sets that.
Reviewed-by: Stephen Brennan <stephen.s.brennan@oracle.com>
Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
---
V2: Some wording improvements from Stephen, thanks!
Also added his review tag.
V1 link: https://lore.kernel.org/r/20240830140401.458542-1-gpiccoli@igalia.com/
Documentation/admin-guide/kernel-parameters.txt | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index efc52ddc6864..351730108c58 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -913,12 +913,16 @@
the parameter has no effect.
crash_kexec_post_notifiers
- Run kdump after running panic-notifiers and dumping
- kmsg. This only for the users who doubt kdump always
- succeeds in any situation.
- Note that this also increases risks of kdump failure,
- because some panic notifiers can make the crashed
- kernel more unstable.
+ Only jump to kdump kernel after running the panic
+ notifiers and dumping kmsg. This option increases the
+ risks of a kdump failure, since some panic notifiers
+ can make the crashed kernel more unstable. In the
+ configurations where kdump may not be reliable,
+ running the panic notifiers can allow collecting more
+ data on dmesg, like stack traces from other CPUS or
+ extra data dumped by panic_print. Notice that some
+ code enables this option unconditionally, like
+ Hyper-V, PowerPC (fadump) and AMD SEV.
crashkernel=size[KMG][@offset[KMG]]
[KNL,EARLY] Using kexec, Linux can switch to a 'crash kernel'
--
2.46.0
On Fri, Aug 30, 2024 at 03:21:00PM -0300, Guilherme G. Piccoli wrote: > Be more clear about the downsides, the upsides (yes, there are some!) > and about code that unconditionally sets that. > > Reviewed-by: Stephen Brennan <stephen.s.brennan@oracle.com> > Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> > > --- > > V2: Some wording improvements from Stephen, thanks! > Also added his review tag. > > V1 link: https://lore.kernel.org/r/20240830140401.458542-1-gpiccoli@igalia.com/ > > > Documentation/admin-guide/kernel-parameters.txt | 16 ++++++++++------ > 1 file changed, 10 insertions(+), 6 deletions(-) > Hi Guilherme, Some subjective grammar nits. > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > index efc52ddc6864..351730108c58 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -913,12 +913,16 @@ > the parameter has no effect. > > crash_kexec_post_notifiers > - Run kdump after running panic-notifiers and dumping > - kmsg. This only for the users who doubt kdump always > - succeeds in any situation. > - Note that this also increases risks of kdump failure, > - because some panic notifiers can make the crashed > - kernel more unstable. > + Only jump to kdump kernel after running the panic > + notifiers and dumping kmsg. This option increases the > + risks of a kdump failure, since some panic notifiers > + can make the crashed kernel more unstable. In the nit: In the configurations -> In configurations > + configurations where kdump may not be reliable, > + running the panic notifiers can allow collecting more > + data on dmesg, like stack traces from other CPUS or > + extra data dumped by panic_print. Notice that some nit: Notice that -> Note that > + code enables this option unconditionally, like Maybe: some code enables -> some configurations enable > + Hyper-V, PowerPC (fadump) and AMD SEV. > > crashkernel=size[KMG][@offset[KMG]] > [KNL,EARLY] Using kexec, Linux can switch to a 'crash kernel' > -- > 2.46.0 > > > _______________________________________________ > kexec mailing list > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec >
On 02/09/2024 10:23, Simon Horman wrote: > > Hi Guilherme, > > Some subjective grammar nits. > >> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt >> index efc52ddc6864..351730108c58 100644 >> --- a/Documentation/admin-guide/kernel-parameters.txt >> +++ b/Documentation/admin-guide/kernel-parameters.txt >> @@ -913,12 +913,16 @@ >> the parameter has no effect. >> >> crash_kexec_post_notifiers >> - Run kdump after running panic-notifiers and dumping >> - kmsg. This only for the users who doubt kdump always >> - succeeds in any situation. >> - Note that this also increases risks of kdump failure, >> - because some panic notifiers can make the crashed >> - kernel more unstable. >> + Only jump to kdump kernel after running the panic >> + notifiers and dumping kmsg. This option increases the >> + risks of a kdump failure, since some panic notifiers >> + can make the crashed kernel more unstable. In the > > nit: In the configurations -> In configurations > >> + configurations where kdump may not be reliable, >> + running the panic notifiers can allow collecting more >> + data on dmesg, like stack traces from other CPUS or >> + extra data dumped by panic_print. Notice that some > > nit: Notice that -> Note that > >> + code enables this option unconditionally, like > > Maybe: some code enables -> some configurations enable > Hey Simon, tnx for the suggestions, will change in the next version. Cheers, Guilherme
On 08/30/24 at 03:21pm, Guilherme G. Piccoli wrote:
> Be more clear about the downsides, the upsides (yes, there are some!)
> and about code that unconditionally sets that.
>
> Reviewed-by: Stephen Brennan <stephen.s.brennan@oracle.com>
> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
>
> ---
>
> V2: Some wording improvements from Stephen, thanks!
> Also added his review tag.
>
> V1 link: https://lore.kernel.org/r/20240830140401.458542-1-gpiccoli@igalia.com/
>
>
> Documentation/admin-guide/kernel-parameters.txt | 16 ++++++++++------
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index efc52ddc6864..351730108c58 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -913,12 +913,16 @@
> the parameter has no effect.
>
> crash_kexec_post_notifiers
> - Run kdump after running panic-notifiers and dumping
> - kmsg. This only for the users who doubt kdump always
> - succeeds in any situation.
> - Note that this also increases risks of kdump failure,
> - because some panic notifiers can make the crashed
> - kernel more unstable.
> + Only jump to kdump kernel after running the panic
> + notifiers and dumping kmsg. This option increases the
> + risks of a kdump failure, since some panic notifiers
> + can make the crashed kernel more unstable. In the
> + configurations where kdump may not be reliable,
> + running the panic notifiers can allow collecting more
> + data on dmesg, like stack traces from other CPUS or
> + extra data dumped by panic_print. Notice that some
> + code enables this option unconditionally, like
> + Hyper-V, PowerPC (fadump) and AMD SEV.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I know Hyper-V enable panic-notifiers by default, but don't remember how
PowerPC and AMD SEC behave in this aspect. While at it, can you add a
little more words to state them in log so that people can learn it?
Thanks.
>
> crashkernel=size[KMG][@offset[KMG]]
> [KNL,EARLY] Using kexec, Linux can switch to a 'crash kernel'
> --
> 2.46.0
>
On 02/09/2024 05:05, Baoquan He wrote: > On 08/30/24 at 03:21pm, Guilherme G. Piccoli wrote: >> Be more clear about the downsides, the upsides (yes, there are some!) >> and about code that unconditionally sets that. >> >> Reviewed-by: Stephen Brennan <stephen.s.brennan@oracle.com> >> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> >> >> --- >> >> V2: Some wording improvements from Stephen, thanks! >> Also added his review tag. >> >> V1 link: https://lore.kernel.org/r/20240830140401.458542-1-gpiccoli@igalia.com/ >> >> >> Documentation/admin-guide/kernel-parameters.txt | 16 ++++++++++------ >> 1 file changed, 10 insertions(+), 6 deletions(-) >> >> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt >> index efc52ddc6864..351730108c58 100644 >> --- a/Documentation/admin-guide/kernel-parameters.txt >> +++ b/Documentation/admin-guide/kernel-parameters.txt >> @@ -913,12 +913,16 @@ >> the parameter has no effect. >> >> crash_kexec_post_notifiers >> - Run kdump after running panic-notifiers and dumping >> - kmsg. This only for the users who doubt kdump always >> - succeeds in any situation. >> - Note that this also increases risks of kdump failure, >> - because some panic notifiers can make the crashed >> - kernel more unstable. >> + Only jump to kdump kernel after running the panic >> + notifiers and dumping kmsg. This option increases the >> + risks of a kdump failure, since some panic notifiers >> + can make the crashed kernel more unstable. In the >> + configurations where kdump may not be reliable, >> + running the panic notifiers can allow collecting more >> + data on dmesg, like stack traces from other CPUS or >> + extra data dumped by panic_print. Notice that some >> + code enables this option unconditionally, like >> + Hyper-V, PowerPC (fadump) and AMD SEV. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > I know Hyper-V enable panic-notifiers by default, but don't remember how > PowerPC and AMD SEC behave in this aspect. While at it, can you add a > little more words to state them in log so that people can learn it? > Thanks. > Hi Baoquan, tnx for the suggestion! You mean mention that in the commit message? If so, I can certainly do - will sent a new version soon(tm) and include it =) Cheers, Guilherme
On 09/11/24 at 05:09pm, Guilherme G. Piccoli wrote: > On 02/09/2024 05:05, Baoquan He wrote: > > On 08/30/24 at 03:21pm, Guilherme G. Piccoli wrote: > >> Be more clear about the downsides, the upsides (yes, there are some!) > >> and about code that unconditionally sets that. > >> > >> Reviewed-by: Stephen Brennan <stephen.s.brennan@oracle.com> > >> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> > >> > >> --- > >> > >> V2: Some wording improvements from Stephen, thanks! > >> Also added his review tag. > >> > >> V1 link: https://lore.kernel.org/r/20240830140401.458542-1-gpiccoli@igalia.com/ > >> > >> > >> Documentation/admin-guide/kernel-parameters.txt | 16 ++++++++++------ > >> 1 file changed, 10 insertions(+), 6 deletions(-) > >> > >> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > >> index efc52ddc6864..351730108c58 100644 > >> --- a/Documentation/admin-guide/kernel-parameters.txt > >> +++ b/Documentation/admin-guide/kernel-parameters.txt > >> @@ -913,12 +913,16 @@ > >> the parameter has no effect. > >> > >> crash_kexec_post_notifiers > >> - Run kdump after running panic-notifiers and dumping > >> - kmsg. This only for the users who doubt kdump always > >> - succeeds in any situation. > >> - Note that this also increases risks of kdump failure, > >> - because some panic notifiers can make the crashed > >> - kernel more unstable. > >> + Only jump to kdump kernel after running the panic > >> + notifiers and dumping kmsg. This option increases the > >> + risks of a kdump failure, since some panic notifiers > >> + can make the crashed kernel more unstable. In the > >> + configurations where kdump may not be reliable, > >> + running the panic notifiers can allow collecting more > >> + data on dmesg, like stack traces from other CPUS or > >> + extra data dumped by panic_print. Notice that some > >> + code enables this option unconditionally, like > >> + Hyper-V, PowerPC (fadump) and AMD SEV. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > I know Hyper-V enable panic-notifiers by default, but don't remember how > > PowerPC and AMD SEC behave in this aspect. While at it, can you add a > > little more words to state them in log so that people can learn it? > > Thanks. > > > Hi Baoquan, tnx for the suggestion! You mean mention that in the commit > message? If so, I can certainly do - will sent a new version soon(tm) > and include it =) You are right, thanks for the effort.
© 2016 - 2025 Red Hat, Inc.