"Guilherme G. Piccoli" <gpiccoli@xxxxxxxxxx> writes: > Be more clear about the downsides, the upsides (yes, there are some!) > and about code that unconditionally sets that. > > Signed-off-by: Guilherme G. Piccoli <gpiccoli@xxxxxxxxxx> > --- > 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..cb25dc5cbe9a 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. As a bright > + side, it might allow to collect more data on dmesg like > + stack traces from other CPUs or extra data dumped by > + panic_print. This is usually only for users who doubt > + kdump will succeed every time. This is definitely clearer and an improvement! But I didn't (and still don't) love the phrase "users who doubt kdump will succeed" because I think that implies user error or silly beliefs. What if these two sentences read something like: In 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. Yes, great addition. With or without my suggestions it's an improvement, so: Reviewed-by: Stephen Brennan <stephen.s.brennan@xxxxxxxxxx>
