Skip to content
Snippets Groups Projects
  1. May 21, 2019
  2. Jan 15, 2019
  3. Jul 12, 2017
  4. Apr 05, 2017
  5. Sep 21, 2016
  6. Jun 03, 2016
  7. May 24, 2016
  8. May 03, 2016
    • Russell King's avatar
      ARM: kexec: fix crashkernel= handling · 61603016
      Russell King authored
      
      When the kernel crashkernel parameter is specified with just a size, we
      are supposed to allocate a region from RAM to store the crashkernel.
      However, ARM merely reserves physical address zero with no checking that
      there is even RAM there.
      
      Fix this by lifting similar code from x86, importing it to ARM with the
      ARM specific parameters added.  In the absence of any platform specific
      information, we allocate the crashkernel region from the first 512MB of
      physical memory.
      
      Update the kdump documentation to reflect this change.
      
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Reviewed-by: default avatarPratyush Anand <panand@redhat.com>
      61603016
  9. Dec 11, 2014
    • 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
      debugging.
      
      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>
      9e3961a0
  10. Aug 29, 2014
  11. Jul 03, 2013
  12. May 28, 2013
  13. Apr 02, 2013
    • Xishi Qiu's avatar
      Add size restriction to the kdump documentation · 797f6a68
      Xishi Qiu authored
      In efi_init() memory aligns in IA64_GRANULE_SIZE(16M). If set "crashkernel=1024M-:600M"
      and use sparse memory model, when crash kernel booting it changes [128M-728M] to [128M-720M].
      
      But initrd memory is in [709M-727M], and virt_addr_valid() *can not* check the invalid pages
      when freeing initrd memory, because there are some pages missed at the end of the section,
      and this causes error.
      
      ...
      Unpacking initramfs...
      Freeing initrd memory: 19648kB freed
      BUG: Bad page state in process swapper  pfn:02d00
      page:e0000000102dd800 flags:(null) count:0 mapcount:1 mapping:(null) index:0
      
      Call Trace:
       [<a000000100018dc0>] show_stack+0x80/0xa0
                                      sp=e000000021e8fbd0 bsp=e000000021e81360
       [<a00000010090fcc0>] dump_stack+0x30/0x50
                                      sp=e000000021e8fda0 bsp=e000000021e81348
       [<a0000001001a3180>] bad_page+0x280/0x380
                                      sp=e000000021e8fda0 bsp=e000000021e81308
       [<a0000001001a8740>] free_hot_cold_page+0x3a0/0x5c0
                                      sp=e000000021e8fda0 bsp=e000000021e812a0
       [<a0000001001a8a50>] free_hot_page+0x30/0x60
                                      sp=e000000021e8fda0 bsp=e000000021e81280
       [<a0000001001a8b30>] __free_pages+0xb0/0xe0
                                      sp=e000000021e8fda0 bsp=e000000021e81258
       [<a0000001001a8c00>] free_pages+0xa0/0xc0
                                      sp=e000000021e8fda0 bsp=e000000021e81230
       [<a000000100bb40c0>] free_initrd_mem+0x230/0x290
                                      sp=e000000021e8fda0 bsp=e000000021e811d8
       [<a000000100ba6620>] populate_rootfs+0x1c0/0x280
                                      sp=e000000021e8fdb0 bsp=e000000021e811a0
       [<a00000010000ac30>] do_one_initcall+0x3b0/0x3e0
                                      sp=e000000021e8fdb0 bsp=e000000021e81158
       [<a000000100ba0a90>] kernel_init+0x3f0/0x4b0
                                      sp=e000000021e8fdb0 bsp=e000000021e81108
       [<a000000100016890>] kernel_thread_helper+0xd0/0x100
                                      sp=e000000021e8fe30 bsp=e000000021e810e0
       [<a00000010000a4c0>] start_kernel_thread+0x20/0x40
                                      sp=e000000021e8fe30 bsp=e000000021e810e0
      ...
      
      In "http://marc.info/?l=linux-arch&m=136147092429314&w=2
      
      " Tony said:
      "Perhaps in Documentation/kdump/kdump.txt (which the crashkernel entry
      in kernel-parameters.txt points at).  The ia64 section of kdump.txt
      notes that the start address will be rounded up to a GRANULE boundary,
      but doesn't talk about restrictions on the size."
      
      This patch add size restriction to the documentation of kdump.
      
      Signed-off-by: default avatarXishi Qiu <qiuxishi@huawei.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      797f6a68
  14. Jul 19, 2012
  15. Dec 27, 2011
  16. Nov 25, 2010
  17. Jun 12, 2009
  18. Oct 22, 2008
    • Mohan Kumar M's avatar
      powerpc: Support for relocatable kdump kernel · 54622f10
      Mohan Kumar M authored
      
      This adds relocatable kernel support for kdump. With this one can
      use the same regular kernel to capture the kdump. A signature (0xfeed1234)
      is passed in r6 from panic code to the next kernel through kexec_sequence
      and purgatory code. The signature is used to differentiate between
      kdump kernel and non-kdump kernels.
      
      The purgatory code compares the signature and sets the __kdump_flag in
      head_64.S.  During the boot up, kernel code checks __kdump_flag and if it
      is set, the kernel will behave as relocatable kdump kernel. This kernel
      will boot at the address where it was loaded by kexec-tools ie. at the
      address reserved through crashkernel boot parameter.
      
      CONFIG_CRASH_DUMP depends on CONFIG_RELOCATABLE option to build kdump
      kernel as relocatable. So the same kernel can be used as production and
      kdump kernel.
      
      This patch incorporates the changes suggested by Paul Mackerras to avoid
      GOT use and to avoid two copies of the code.
      
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarMohan Kumar M <mohan@in.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      54622f10
  19. Jul 28, 2008
  20. Jul 08, 2008
  21. May 01, 2008
  22. Oct 19, 2007
  23. Oct 17, 2007
  24. Feb 21, 2007
  25. Feb 12, 2007
  26. Jan 23, 2007
  27. Jan 12, 2007
  28. Oct 03, 2006
  29. Jun 26, 2006
  30. Jun 25, 2006
  31. Jan 12, 2006
  32. Jan 10, 2006
  33. Sep 13, 2005
  34. Sep 09, 2005
  35. Jun 25, 2005
Loading