• Prarit Bhargava's avatar
    kernel: add panic_on_warn · 9e3961a0
    Prarit Bhargava authored
    There have been several times where I have had to rebuild a kernel to
    cause a panic when hitting a WARN() in the code in order to get a crash
    dump from a system.  Sometimes this is easy to do, other times (such as
    in the case of a remote admin) it is not trivial to send new images to
    the user.
    A much easier method would be a switch to change the WARN() over to a
    panic.  This makes debugging easier in that I can now test the actual
    image the WARN() was seen on and I do not have to engage in remote
    This patch adds a panic_on_warn kernel parameter and
    /proc/sys/kernel/panic_on_warn calls panic() in the
    warn_slowpath_common() path.  The function will still print out the
    location of the warning.
    An example of the panic_on_warn output:
    The first line below is from the WARN_ON() to output the WARN_ON()'s
    location.  After that the panic() output is displayed.
        WARNING: CPU: 30 PID: 11698 at /home/prarit/dummy_module/dummy-module.c:25 init_dummy+0x1f/0x30 [dummy_module]()
        Kernel panic - not syncing: panic_on_warn set ...
        CPU: 30 PID: 11698 Comm: insmod Tainted: G        W  OE  3.17.0+ #57
        Hardware name: Intel Corporation S2600CP/S2600CP, BIOS RMLSDP.86I.00.29.D696.1311111329 11/11/2013
         0000000000000000 000000008e3f87df ffff88080f093c38 ffffffff81665190
         0000000000000000 ffffffff818aea3d ffff88080f093cb8 ffffffff8165e2ec
         ffffffff00000008 ffff88080f093cc8 ffff88080f093c68 000000008e3f87df
        Call Trace:
         [<ffffffff81665190>] dump_stack+0x46/0x58
         [<ffffffff8165e2ec>] panic+0xd0/0x204
         [<ffffffffa038e05f>] ? init_dummy+0x1f/0x30 [dummy_module]
         [<ffffffff81076b90>] warn_slowpath_common+0xd0/0xd0
         [<ffffffffa038e040>] ? dummy_greetings+0x40/0x40 [dummy_module]
         [<ffffffff81076c8a>] warn_slowpath_null+0x1a/0x20
         [<ffffffffa038e05f>] init_dummy+0x1f/0x30 [dummy_module]
         [<ffffffff81002144>] do_one_initcall+0xd4/0x210
         [<ffffffff811b52c2>] ? __vunmap+0xc2/0x110
         [<ffffffff810f8889>] load_module+0x16a9/0x1b30
         [<ffffffff810f3d30>] ? store_uevent+0x70/0x70
         [<ffffffff810f49b9>] ? copy_module_from_fd.isra.44+0x129/0x180
         [<ffffffff810f8ec6>] SyS_finit_module+0xa6/0xd0
         [<ffffffff8166cf29>] system_call_fastpath+0x12/0x17
    Successfully tested by me.
    hpa said: There is another very valid use for this: many operators would
    rather a machine shuts down than being potentially compromised either
    functionally or security-wise.
    Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
    Acked-by: default avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
    Cc: Fabian Frederick <fabf@skynet.be>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
sysctl_binary.c 51 KB