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@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..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. 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

"Guilherme G. Piccoli" <gpiccoli@igalia.com> 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@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..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@oracle.com>

On 30/08/2024 14:15, Stephen Brennan wrote:
> [...]
> 
> 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@oracle.com>
> 

Thanks Stephen, I agree - your wording sounds better.
I've incorporated that in the just sent V2.
Cheers,


Guilherme


P.S. I'll be OOO some days, so expect a bit of delay in case there are
more reviews/interactions.