linux-stable.git/kernel/kexec_core.c, branch v4.10.2

kexec: add cond_resched into kimage_alloc_crash_control_pages

2016-12-15T00:04:07+00:00

A soft lookup will occur when I run trinity in syscall kexec_load.  the
corresponding stack information is as follows.

  BUG: soft lockup - CPU#6 stuck for 22s! [trinity-c6:13859]
  Kernel panic - not syncing: softlockup: hung tasks
  CPU: 6 PID: 13859 Comm: trinity-c6 Tainted: G           O L ----V-------   3.10.0-327.28.3.35.zhongjiang.x86_64 #1
  Hardware name: Huawei Technologies Co., Ltd. Tecal BH622 V2/BC01SRSA0, BIOS RMIBV386 06/30/2014
  Call Trace:
     dump_stack+0x19/0x1b
   panic+0xd8/0x214
   watchdog_timer_fn+0x1cc/0x1e0
   __hrtimer_run_queues+0xd2/0x260
   hrtimer_interrupt+0xb0/0x1e0
   ? call_softirq+0x1c/0x30
   local_apic_timer_interrupt+0x37/0x60
   smp_apic_timer_interrupt+0x3f/0x60
   apic_timer_interrupt+0x6d/0x80
     ? kimage_alloc_control_pages+0x80/0x270
   ? kmem_cache_alloc_trace+0x1ce/0x1f0
   ? do_kimage_alloc_init+0x1f/0x90
   kimage_alloc_init+0x12a/0x180
   SyS_kexec_load+0x20a/0x260
   system_call_fastpath+0x16/0x1b

the first time allocation of control pages may take too much time
because crash_res.end can be set to a higher value.  we need to add
cond_resched to avoid the issue.

The patch have been tested and above issue is not appear.

Link: http://lkml.kernel.org/r/1481164674-42775-1-git-send-email-zhongjiang@huawei.com
Signed-off-by: zhong jiang 
Acked-by: "Eric W. Biederman" 
Cc: Xunlei Pang 
Cc: Dave Young 
Cc: Vivek Goyal 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kexec: export the value of phys_base instead of symbol address

2016-12-15T00:04:07+00:00

Currently in x86_64, the symbol address of phys_base is exported to
vmcoreinfo.  Dave Anderson complained this is really useless for his
Crash implementation.  Because in user-space utility Crash and
Makedumpfile which exported vmcore information is mainly used for, value
of phys_base is needed to covert virtual address of exported kernel
symbol to physical address.  Especially init_level4_pgt, if we want to
access and go over the page table to look up a PA corresponding to VA,
firstly we need calculate

  page_dir = SYMBOL(init_level4_pgt) - __START_KERNEL_map + phys_base;

Now in Crash and Makedumpfile, we have to analyze the vmcore elf program
header to get value of phys_base.  As Dave said, it would be preferable
if it were readily availabl in vmcoreinfo rather than depending upon the
PT_LOAD semantics.

Hence in this patch change to export the value of phys_base instead of
its virtual address.

And people also complained that KERNEL_IMAGE_SIZE exporting is x86_64
only, should be moved into arch dependent function
arch_crash_save_vmcoreinfo.  Do the moving in this patch.

Link: http://lkml.kernel.org/r/1478568596-30060-2-git-send-email-bhe@redhat.com
Signed-off-by: Baoquan He 
Cc: Thomas Garnier 
Cc: Baoquan He 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H . Peter Anvin" 
Cc: Eric Biederman 
Cc: Xunlei Pang 
Cc: HATAYAMA Daisuke 
Cc: Kees Cook 
Cc: Eugene Surovegin 
Cc: Dave Young 
Cc: AKASHI Takahiro 
Cc: Atsushi Kumagai 
Cc: Dave Anderson 
Cc: Pratyush Anand 
Cc: Vivek Goyal 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kexec: add restriction on kexec_load() segment sizes

2016-08-02T23:35:31+00:00

I hit the following issue when run trinity in my system.  The kernel is
3.4 version, but mainline has the same issue.

The root cause is that the segment size is too large so the kerenl
spends too long trying to allocate a page.  Other cases will block until
the test case quits.  Also, OOM conditions will occur.

Call Trace:
  __alloc_pages_nodemask+0x14c/0x8f0
  alloc_pages_current+0xaf/0x120
  kimage_alloc_pages+0x10/0x60
  kimage_alloc_control_pages+0x5d/0x270
  machine_kexec_prepare+0xe5/0x6c0
  ? kimage_free_page_list+0x52/0x70
  sys_kexec_load+0x141/0x600
  ? vfs_write+0x100/0x180
  system_call_fastpath+0x16/0x1b

The patch changes sanity_check_segment_list() to verify that the usage by
all segments does not exceed half of memory.

[akpm@linux-foundation.org: fix for kexec-return-error-number-directly.patch, update comment]
Link: http://lkml.kernel.org/r/1469625474-53904-1-git-send-email-zhongjiang@huawei.com
Signed-off-by: zhong jiang 
Suggested-by: Eric W. Biederman 
Cc: Vivek Goyal 
Cc: Dave Young 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kexec: add a kexec_crash_loaded() function

2016-08-02T23:35:30+00:00

Provide a wrapper function to be used by kernel code to check whether a
crash kernel is loaded.  It returns the same value that can be seen in
/sys/kernel/kexec_crash_loaded by userspace programs.

I'm exporting the function, because it will be used by Xen, and it is
possible to compile Xen modules separately to enable the use of PV
drivers with unmodified bare-metal kernels.

Link: http://lkml.kernel.org/r/20160713121955.14969.69080.stgit@hananiah.suse.cz
Signed-off-by: Petr Tesarik 
Cc: Juergen Gross 
Cc: Josh Triplett 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Eric Biederman 
Cc: "H. Peter Anvin" 
Cc: Boris Ostrovsky 
Cc: "Paul E. McKenney" 
Cc: Dave Young 
Cc: David Vrabel 
Cc: Vivek Goyal 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kexec: allow architectures to override boot mapping

2016-08-02T23:35:27+00:00

kexec physical addresses are the boot-time view of the system.  For
certain ARM systems (such as Keystone 2), the boot view of the system
does not match the kernel's view of the system: the boot view uses a
special alias in the lower 4GB of the physical address space.

To cater for these kinds of setups, we need to translate between the
boot view physical addresses and the normal kernel view physical
addresses.  This patch extracts the current transation points into
linux/kexec.h, and allows an architecture to override the functions.

Due to the translations required, we unfortunately end up with six
translation functions, which are reduced down to four that the
architecture can override.

[akpm@linux-foundation.org: kexec.h needs asm/io.h for phys_to_virt()]
Link: http://lkml.kernel.org/r/E1b8koP-0004HZ-Vf@rmk-PC.armlinux.org.uk
Signed-off-by: Russell King 
Cc: Keerthy 
Cc: Pratyush Anand 
Cc: Vitaly Andrianov 
Cc: Eric Biederman 
Cc: Dave Young 
Cc: Baoquan He 
Cc: Vivek Goyal 
Cc: Simon Horman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kdump: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

2016-08-02T23:35:27+00:00

On PAE systems (eg, ARM LPAE) the vmcore note may be located above 4GB
physical on 32-bit architectures, so we need a wider type than "unsigned
long" here.  Arrange for paddr_vmcoreinfo_note() to return a
phys_addr_t, thereby allowing it to be located above 4GB.

This makes no difference for kexec-tools, as they already assume a
64-bit type when reading from this file.

Link: http://lkml.kernel.org/r/E1b8koK-0004HS-K9@rmk-PC.armlinux.org.uk
Signed-off-by: Russell King 
Reviewed-by: Pratyush Anand 
Acked-by: Baoquan He 
Cc: Keerthy 
Cc: Vitaly Andrianov 
Cc: Eric Biederman 
Cc: Dave Young 
Cc: Vivek Goyal 
Cc: Simon Horman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kexec: ensure user memory sizes do not wrap

2016-08-02T23:35:26+00:00

Ensure that user memory sizes do not wrap around when validating the
user input, which can lead to the following input validation working
incorrectly.

[akpm@linux-foundation.org: fix it for kexec-return-error-number-directly.patch]
Link: http://lkml.kernel.org/r/E1b8koF-0004HM-5x@rmk-PC.armlinux.org.uk
Signed-off-by: Russell King 
Reviewed-by: Pratyush Anand 
Acked-by: Baoquan He 
Cc: Keerthy 
Cc: Vitaly Andrianov 
Cc: Eric Biederman 
Cc: Dave Young 
Cc: Vivek Goyal 
Cc: Simon Horman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kexec: return error number directly

2016-08-02T23:35:24+00:00

This is a cleanup patch to make kexec more clear to return error number
directly.  The variable result is useless, because there is no other
function's return value assignes to it.  So remove it.

Link: http://lkml.kernel.org/r/1464179273-57668-1-git-send-email-mnghuan@gmail.com
Signed-off-by: Minfei Huang 
Cc: Dave Young 
Cc: Baoquan He 
Cc: Borislav Petkov 
Cc: Xunlei Pang 
Cc: Atsushi Kumagai 
Cc: Vivek Goyal 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

s390/kexec: consolidate crash_map/unmap_reserved_pages() and arch_kexec_protect(unprotect)_crashkres()

2016-05-24T00:04:14+00:00

Commit 3f625002581b ("kexec: introduce a protection mechanism for the
crashkernel reserved memory") is a similar mechanism for protecting the
crash kernel reserved memory to previous crash_map/unmap_reserved_pages()
implementation, the new one is more generic in name and cleaner in code
(besides, some arch may not be allowed to unmap the pgtable).

Therefore, this patch consolidates them, and uses the new
arch_kexec_protect(unprotect)_crashkres() to replace former
crash_map/unmap_reserved_pages() which by now has been only used by
S390.

The consolidation work needs the crash memory to be mapped initially,
this is done in machine_kdump_pm_init() which is after
reserve_crashkernel().  Once kdump kernel is loaded, the new
arch_kexec_protect_crashkres() implemented for S390 will actually
unmap the pgtable like before.

Signed-off-by: Xunlei Pang 
Signed-off-by: Michael Holzheu 
Acked-by: Michael Holzheu 
Cc: Heiko Carstens 
Cc: "Eric W. Biederman" 
Cc: Minfei Huang 
Cc: Vivek Goyal 
Cc: Dave Young 
Cc: Baoquan He 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kexec: introduce a protection mechanism for the crashkernel reserved memory

2016-05-24T00:04:14+00:00

For the cases that some kernel (module) path stamps the crash reserved
memory(already mapped by the kernel) where has been loaded the second
kernel data, the kdump kernel will probably fail to boot when panic
happens (or even not happens) leaving the culprit at large, this is
unacceptable.

The patch introduces a mechanism for detecting such cases:

1) After each crash kexec loading, it simply marks the reserved memory
   regions readonly since we no longer access it after that.  When someone
   stamps the region, the first kernel will panic and trigger the kdump.
   The weak arch_kexec_protect_crashkres() is introduced to do the actual
   protection.

2) To allow multiple loading, once 1) was done we also need to remark
   the reserved memory to readwrite each time a system call related to
   kdump is made.  The weak arch_kexec_unprotect_crashkres() is introduced
   to do the actual protection.

The architecture can make its specific implementation by overriding
arch_kexec_protect_crashkres() and arch_kexec_unprotect_crashkres().

Signed-off-by: Xunlei Pang 
Cc: Eric Biederman 
Cc: Dave Young 
Cc: Minfei Huang 
Cc: Vivek Goyal 
Cc: Baoquan He 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds