New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 638723 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 908726
Owner: ----
Closed: Jan 15
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

kernel-4.4: panic and kgdb are no longer friends, but need to kiss and make up

Project Member Reported by diand...@chromium.org, Aug 17 2016

Issue description

In the commit 5516fd7b92a7 ("debug: prevent entering debug mode on panic/exception.") we will now no longer enter kgdb on a panic if the "panic" value is non-zero.

On Chrome OS you can see that "/proc/sys/kernel/panic" is -1.

This makes it a PITA for folks who build a kernel with USE=kgdb

How can we fix this?  For now I'm just reverting the offending commit.
 

Comment 1 by groeck@chromium.org, Aug 17 2016

Maybe figure out why /proc/sys/kernel/panic isn't 0 ?
Also, did you try setting it to 0 after boot ?

Guenter

Comment 2 by groeck@chromium.org, Aug 17 2016

/etc/sysctl.d/00-sysctl.conf:

# When the kernel panics, automatically reboot to preserve dump in ram
kernel.panic = -1
kernel.panic_on_oops = 1

Maybe just set it to 0 on a debug system ? Seems to be much less invasive than just reverting an upstream patch.

Yup, could do that.  Was hoping to come up with some solution that doesn't require me to make changes to my root filesystem every time I re-image my device.

We actually never put kgdb on a shipping system anyway, so technically we don't need the upstream patch.  Any system that has kgdb enabled really wants kgdb enabled to debug crashes.

Anyway, for now I'll just keep either reverting the patch or hacking my root filesystem, but it would be nice to come up with a better solution.

Comment 4 by groeck@chromium.org, Aug 17 2016

Problem is that the kernel's default value is overwritten by 00-sysctl.conf.
A generic solution would probably require us to drop that and to rely on the the default kernel configuration (CONFIG_PANIC_TIMEOUT) instead. We could set a default value of -1. USE=kgdb could overwrite this default with 0.

@4: Another option would be to make it configurable about whether "panic != 0" trumps kgdb or kgdb tumps "panic != 0".

One could argue that in all kernels prior to the above commit that the ABI to userspace was that if kgdb was configured and enabled that you would drop into kgdb even if panic != 0.  By this argument the above CL was a ABI regression.

Comment 6 by groeck@google.com, Aug 18 2016

Seems to me that calling this an "ABI to userspace" is a bit of a stretch, even more so since the specific _purpose_ of the patch in question is to change that behavior. Not every behavioral change is an ABI regression. Also, I actually agree with commit 5516fd7b92a7; that it causes inconvenience for us is more a matter of our setup, not with the patch itself.

@6: 

https://xkcd.com/1172/

Look, my setup works for me.  Just add an option to reenable <kgdb overriding panic>.

===

Agree that dropping the sysctl.conf might be sane?  Maybe this explains why we're so inconsistent with our kernel configs yet there is no bad side effect.
Mergedinto: 908726
Status: Duplicate (was: Untriaged)

Sign in to add a comment