kexec, remove panic_on_warn kernel parameter from kdump situations

panic_on_warn kernel parameter will cause the kernel to panic when a WARN() is hit in the kernel. This is not a good situation for the kdump kernel because then it would be possible for the kdump kernel to panic in a non-fatal WARN().

This patch removes panic_on_warn as a kernel parameter for the kdump kernel.

Signed-off-by Prarit Bhargava <[email protected]>

Cc Dave Young <[email protected]>

Cc Vivek Goyal <[email protected]>

Cc WANG Chao <[email protected]>

---
 kexec/kexec.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

kexec/kexec.c +3 -1

index b088916..323cafb 100644
@@ -1048,8 +1048,10 @@ char *get_command_line(void)
 	line[strlen(line) - 1] = '\0';
 
 	remove_parameter(line, "BOOT_IMAGE");
-	if (kexec_flags & KEXEC_ON_CRASH)
+	if (kexec_flags & KEXEC_ON_CRASH) {
 		remove_parameter(line, "crashkernel");
+		remove_parameter(line, "panic_on_warn");
+	}
 
 	return line;
 }

Signature · 1 line

1.7.9.3

Quoted 5 lines · Prarit Bhargava

panic_on_warn kernel parameter will cause the kernel to panic when a WARN() is hit in the kernel. This is not a good situation for the kdump kernel because then it would be possible for the kdump kernel to panic in a non-fatal WARN().

Quoted 3 lines

This patch removes panic_on_warn as a kernel parameter for the kdump kernel.

I think modifying kexec-tools is not best place for this. It probably is better to take care of this in distribution specific scripts.

In the past we have learnt that it is best that kexec-tools does least amount of manipulation with command line.

Thanks
Vivek

Quoted 22 lines

Signed-off-by Prarit Bhargava <[email protected]>

Cc Dave Young <[email protected]>

Cc Vivek Goyal <[email protected]>

Cc WANG Chao <[email protected]>

---
 kexec/kexec.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

kexec/kexec.c +3 -1

index b088916..323cafb 100644
@@ -1048,8 +1048,10 @@ char *get_command_line(void)
 	line[strlen(line) - 1] = '\0';
 
 	remove_parameter(line, "BOOT_IMAGE");
-	if (kexec_flags & KEXEC_ON_CRASH)
+	if (kexec_flags & KEXEC_ON_CRASH) {
 		remove_parameter(line, "crashkernel");
+		remove_parameter(line, "panic_on_warn");
+	}
 

Quoted 4 lines

kexec/kexec.c +0 -0

 	return line;
 }

Signature · 1 line

1.7.9.3

Quoted 10 lines · Vivek Goyal

Quoted 8 lines · Prarit Bhargava

panic_on_warn kernel parameter will cause the kernel to panic when a WARN() is hit in the kernel. This is not a good situation for the kdump kernel because then it would be possible for the kdump kernel to panic in a non-fatal WARN().

This patch removes panic_on_warn as a kernel parameter for the kdump kernel.

Quoted 4 lines

I think modifying kexec-tools is not best place for this. It probably is better to take care of this in distribution specific scripts.

In the past we have learnt that it is best that kexec-tools does least amount of manipulation with command line.

Well .. here's the question to think about: what does adding panic_on_warn to the kdump kernel get you? AFAICT, nothing.

If panic_on_warn is specified, the only thing that will happen is that kdump will fail (which is always bad IMO). There is no real difference in the stack trace between the WARN() and panic situations so there is no information loss.

So I disagree -- we should never specify panic_on_warn on kdump kernel.

Quoted 13 lines · Prarit Bhargava

Quoted 10 lines · Vivek Goyal

Quoted 8 lines · Prarit Bhargava

panic_on_warn kernel parameter will cause the kernel to panic when a WARN() is hit in the kernel. This is not a good situation for the kdump kernel because then it would be possible for the kdump kernel to panic in a non-fatal WARN().

This patch removes panic_on_warn as a kernel parameter for the kdump kernel.

Quoted 7 lines

Quoted 4 lines

I think modifying kexec-tools is not best place for this. It probably is better to take care of this in distribution specific scripts.

In the past we have learnt that it is best that kexec-tools does least amount of manipulation with command line.

Well .. here's the question to think about: what does adding panic_on_warn to the kdump kernel get you? AFAICT, nothing.

Let us consider a hypothetical situation. What if we have some buggy code which will corrupt file system in certain situation and we detect that situation and throw a warning.

In that case as a work around specifying panic_on_warn in kdump kernel will make sense as we don't want to make further progress if we hit the warning as it has potential to corrupt fs.

Again this is hypothetical but it can happen. So panic_on_warn might still be useful in kdump kernel for some corner debugging cases.

That's why I think we should do it in distribution specific scripts and that too only if user did not specify panic_on_warn for second kernel explicitly.

Quoted 1 line

Quoted 5 lines

If panic_on_warn is specified, the only thing that will happen is that kdump will fail (which is always bad IMO). There is no real difference in the stack trace between the WARN() and panic situations so there is no information loss.

So I disagree -- we should never specify panic_on_warn on kdump kernel.

I am saying that do it in distribution specific scripts and not in kexec-tools.

Quoted 13 lines · Prarit Bhargava

Quoted 10 lines · Vivek Goyal

Quoted 8 lines · Prarit Bhargava

panic_on_warn kernel parameter will cause the kernel to panic when a WARN() is hit in the kernel. This is not a good situation for the kdump kernel because then it would be possible for the kdump kernel to panic in a non-fatal WARN().

This patch removes panic_on_warn as a kernel parameter for the kdump kernel.

Quoted 7 lines

Quoted 4 lines

I think modifying kexec-tools is not best place for this. It probably is better to take care of this in distribution specific scripts.

In the past we have learnt that it is best that kexec-tools does least amount of manipulation with command line.

Well .. here's the question to think about: what does adding panic_on_warn to the kdump kernel get you? AFAICT, nothing.

Let us consider a hypothetical situation. What if we have some buggy code which will corrupt file system in certain situation and we detect that situation and throw a warning.

In that case as a work around specifying panic_on_warn in kdump kernel will make sense as we don't want to make further progress if we hit the warning as it has potential to corrupt fs.

Again this is hypothetical but it can happen. So panic_on_warn might still be useful in kdump kernel for some corner debugging cases.

That's why I think we should do it in distribution specific scripts and that too only if user did not specify panic_on_warn for second kernel explicitly.

Quoted 30 lines · Vivek Goyal

Quoted 13 lines · Prarit Bhargava

Quoted 10 lines · Vivek Goyal

Quoted 8 lines · Prarit Bhargava

panic_on_warn kernel parameter will cause the kernel to panic when a WARN() is hit in the kernel. This is not a good situation for the kdump kernel because then it would be possible for the kdump kernel to panic in a non-fatal WARN().

This patch removes panic_on_warn as a kernel parameter for the kdump kernel.

Quoted 7 lines

Quoted 4 lines

I think modifying kexec-tools is not best place for this. It probably is better to take care of this in distribution specific scripts.

In the past we have learnt that it is best that kexec-tools does least amount of manipulation with command line.

Well .. here's the question to think about: what does adding panic_on_warn to the kdump kernel get you? AFAICT, nothing.

Let us consider a hypothetical situation. What if we have some buggy code which will corrupt file system in certain situation and we detect that situation and throw a warning.

In that case as a work around specifying panic_on_warn in kdump kernel will make sense as we don't want to make further progress if we hit the warning as it has potential to corrupt fs.

Quoted 6 lines

Again this is hypothetical but it can happen. So panic_on_warn might still be useful in kdump kernel for some corner debugging cases.

That's why I think we should do it in distribution specific scripts and that too only if user did not specify panic_on_warn for second kernel explicitly.

Thinking of user who use upstream kexec-tools instead of distribution toolset, In case kexec --reuse-cmdline, it will copy /proc/cmdline, but user will have no way to remove part of them.

I do want to insist on removing 'panic_on_warn' in upstream kexec-tools, but we should give user an option to remove it. Something like:

kexec --reuse-cmdline --remove-params="panic_on_warn" will be good.

Quoted 38 lines · Dave Young

Quoted 30 lines · Vivek Goyal

Quoted 13 lines · Prarit Bhargava

Quoted 10 lines · Vivek Goyal

Quoted 8 lines · Prarit Bhargava

panic_on_warn kernel parameter will cause the kernel to panic when a WARN() is hit in the kernel. This is not a good situation for the kdump kernel because then it would be possible for the kdump kernel to panic in a non-fatal WARN().

This patch removes panic_on_warn as a kernel parameter for the kdump kernel.

Quoted 7 lines

Quoted 4 lines

I think modifying kexec-tools is not best place for this. It probably is better to take care of this in distribution specific scripts.

In the past we have learnt that it is best that kexec-tools does least amount of manipulation with command line.

Well .. here's the question to think about: what does adding panic_on_warn to the kdump kernel get you? AFAICT, nothing.

Let us consider a hypothetical situation. What if we have some buggy code which will corrupt file system in certain situation and we detect that situation and throw a warning.

In that case as a work around specifying panic_on_warn in kdump kernel will make sense as we don't want to make further progress if we hit the warning as it has potential to corrupt fs.

Quoted 6 lines

Again this is hypothetical but it can happen. So panic_on_warn might still be useful in kdump kernel for some corner debugging cases.

That's why I think we should do it in distribution specific scripts and that too only if user did not specify panic_on_warn for second kernel explicitly.

Quoted 8 lines

Thinking of user who use upstream kexec-tools instead of distribution toolset, In case kexec --reuse-cmdline, it will copy /proc/cmdline, but user will have no way to remove part of them.

I do want to insist on removing 'panic_on_warn' in upstream kexec-tools, but we should give user an option to remove it. Something like:

kexec --reuse-cmdline --remove-params="panic_on_warn" will be good.

If user is using --reuse-commandline at the same time does not want some of the parameters from command line, then don't use --reuse-commandline.

This is overenginnering. First provide an option to reuse the commandline and provide another option to selectively remove some parameters from that commandline.

What's wrong with existing parameters of --command-line. This just allows user to specify whatever command line is suitable.

So, no, we should not provide --remove-params. If existing command line does not work for new kenrel, then user should not use --reuse-commandline option.

Quoted 58 lines · Vivek Goyal

Quoted 38 lines · Dave Young

Quoted 30 lines · Vivek Goyal

Quoted 13 lines · Prarit Bhargava

Quoted 10 lines · Vivek Goyal

Quoted 8 lines · Prarit Bhargava

panic_on_warn kernel parameter will cause the kernel to panic when a WARN() is hit in the kernel. This is not a good situation for the kdump kernel because then it would be possible for the kdump kernel to panic in a non-fatal WARN().

This patch removes panic_on_warn as a kernel parameter for the kdump kernel.

Quoted 7 lines

Quoted 4 lines

I think modifying kexec-tools is not best place for this. It probably is better to take care of this in distribution specific scripts.

In the past we have learnt that it is best that kexec-tools does least amount of manipulation with command line.

Well .. here's the question to think about: what does adding panic_on_warn to the kdump kernel get you? AFAICT, nothing.

Let us consider a hypothetical situation. What if we have some buggy code which will corrupt file system in certain situation and we detect that situation and throw a warning.

In that case as a work around specifying panic_on_warn in kdump kernel will make sense as we don't want to make further progress if we hit the warning as it has potential to corrupt fs.

Quoted 6 lines

Again this is hypothetical but it can happen. So panic_on_warn might still be useful in kdump kernel for some corner debugging cases.

That's why I think we should do it in distribution specific scripts and that too only if user did not specify panic_on_warn for second kernel explicitly.

Quoted 8 lines

Thinking of user who use upstream kexec-tools instead of distribution toolset, In case kexec --reuse-cmdline, it will copy /proc/cmdline, but user will have no way to remove part of them.

I do want to insist on removing 'panic_on_warn' in upstream kexec-tools, but we should give user an option to remove it. Something like:

kexec --reuse-cmdline --remove-params="panic_on_warn" will be good.

If user is using --reuse-commandline at the same time does not want some of the parameters from command line, then don't use --reuse-commandline.

This is overenginnering. First provide an option to reuse the commandline and provide another option to selectively remove some parameters from that commandline.

What's wrong with existing parameters of --command-line. This just allows user to specify whatever command line is suitable.

Quoted 3 lines

So, no, we should not provide --remove-params. If existing command line does not work for new kenrel, then user should not use --reuse-commandline option.

Hmm, ok. So hope one who is use panic_on_warn in 1st kernel know what he is doing and do not simply copy the 1st kernel cmdline for 2nd kernel.

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Quoted 63 lines · Dave Young

Quoted 61 lines · Vivek Goyal

Quoted 38 lines · Dave Young

Quoted 30 lines · Vivek Goyal

Quoted 13 lines · Prarit Bhargava

Quoted 10 lines · Vivek Goyal

Quoted 8 lines · Prarit Bhargava

panic_on_warn kernel parameter will cause the kernel to panic when a WARN() is hit in the kernel. This is not a good situation for the kdump kernel because then it would be possible for the kdump kernel to panic in a non-fatal WARN().

This patch removes panic_on_warn as a kernel parameter for the kdump kernel.

Quoted 7 lines

Quoted 4 lines

I think modifying kexec-tools is not best place for this. It probably is better to take care of this in distribution specific scripts.

In the past we have learnt that it is best that kexec-tools does least amount of manipulation with command line.

Well .. here's the question to think about: what does adding panic_on_warn to the kdump kernel get you? AFAICT, nothing.

Let us consider a hypothetical situation. What if we have some buggy code which will corrupt file system in certain situation and we detect that situation and throw a warning.

In that case as a work around specifying panic_on_warn in kdump kernel will make sense as we don't want to make further progress if we hit the warning as it has potential to corrupt fs.

Quoted 6 lines

Again this is hypothetical but it can happen. So panic_on_warn might still be useful in kdump kernel for some corner debugging cases.

That's why I think we should do it in distribution specific scripts and that too only if user did not specify panic_on_warn for second kernel explicitly.

Quoted 8 lines

Thinking of user who use upstream kexec-tools instead of distribution toolset, In case kexec --reuse-cmdline, it will copy /proc/cmdline, but user will have no way to remove part of them.

I do want to insist on removing 'panic_on_warn' in upstream kexec-tools, but we should give user an option to remove it. Something like:

kexec --reuse-cmdline --remove-params="panic_on_warn" will be good.

If user is using --reuse-commandline at the same time does not want some of the parameters from command line, then don't use --reuse-commandline.

This is overenginnering. First provide an option to reuse the commandline and provide another option to selectively remove some parameters from that commandline.

What's wrong with existing parameters of --command-line. This just allows user to specify whatever command line is suitable.

So, no, we should not provide --remove-params. If existing command line does not work for new kenrel, then user should not use --reuse-commandline option.

Quoted 2 lines

Hmm, ok. So hope one who is use panic_on_warn in 1st kernel know what he is doing and do not simply copy the 1st kernel cmdline for 2nd kernel.

I am fine with which postion it should be cared in some extent. This is truly a problem we need consider. If one distribution used doesn't handle it, and user using latest upstream kernel will be surprised by this.

Quoted 58 lines · Vivek Goyal

Quoted 38 lines · Dave Young

Quoted 30 lines · Vivek Goyal

Quoted 13 lines · Prarit Bhargava

Quoted 10 lines · Vivek Goyal

Quoted 8 lines · Prarit Bhargava

panic_on_warn kernel parameter will cause the kernel to panic when a WARN() is hit in the kernel. This is not a good situation for the kdump kernel because then it would be possible for the kdump kernel to panic in a non-fatal WARN().

This patch removes panic_on_warn as a kernel parameter for the kdump kernel.

Quoted 7 lines

Quoted 4 lines

I think modifying kexec-tools is not best place for this. It probably is better to take care of this in distribution specific scripts.

In the past we have learnt that it is best that kexec-tools does least amount of manipulation with command line.

Well .. here's the question to think about: what does adding panic_on_warn to the kdump kernel get you? AFAICT, nothing.

Let us consider a hypothetical situation. What if we have some buggy code which will corrupt file system in certain situation and we detect that situation and throw a warning.

In that case as a work around specifying panic_on_warn in kdump kernel will make sense as we don't want to make further progress if we hit the warning as it has potential to corrupt fs.

Quoted 6 lines

Again this is hypothetical but it can happen. So panic_on_warn might still be useful in kdump kernel for some corner debugging cases.

That's why I think we should do it in distribution specific scripts and that too only if user did not specify panic_on_warn for second kernel explicitly.

Quoted 8 lines

Thinking of user who use upstream kexec-tools instead of distribution toolset, In case kexec --reuse-cmdline, it will copy /proc/cmdline, but user will have no way to remove part of them.

I do want to insist on removing 'panic_on_warn' in upstream kexec-tools, but we should give user an option to remove it. Something like:

kexec --reuse-cmdline --remove-params="panic_on_warn" will be good.

If user is using --reuse-commandline at the same time does not want some of the parameters from command line, then don't use --reuse-commandline.

This is overenginnering. First provide an option to reuse the commandline and provide another option to selectively remove some parameters from that commandline.

What's wrong with existing parameters of --command-line. This just allows user to specify whatever command line is suitable.

Quoted 3 lines

So, no, we should not provide --remove-params. If existing command line does not work for new kenrel, then user should not use --reuse-commandline option.

Hmm, ok. So hope one who is use panic_on_warn in 1st kernel know what he is doing and do not simply copy the 1st kernel cmdline for 2nd kernel.