linux-toradex.git/arch/x86/kernel/crash.c, branch v4.4.26

x86/kexec: Remove obsolete 'in_crash_kexec' flag

2015-10-12T07:43:11+00:00

Previously, UV NMI used the 'in_crash_kexec' flag to determine whether
we are in a kdump kernel or not:

  5edd19af18a36a4 ("x86, UV: Make kdump avoid stack dumps")

But this flags was removed in the following commit:

  9c48f1c629ecfa1 ("x86, nmi: Wire up NMI handlers to new routines")

Since it isn't used any more, remove it.

Signed-off-by: Minfei Huang 
Acked-by: Don Zickus 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: cpw@sgi.com
Cc: kexec@lists.infradead.org
Cc: mhuang@redhat.com
Link: http://lkml.kernel.org/r/1444070155-17934-1-git-send-email-mhuang@redhat.com
Signed-off-by: Ingo Molnar

x86/kexec: Fix kexec crash in syscall kexec_file_load()

2015-10-02T07:13:06+00:00

The original bug is a page fault crash that sometimes happens
on big machines when preparing ELF headers:

    BUG: unable to handle kernel paging request at ffffc90613fc9000
    IP: [] prepare_elf64_ram_headers_callback+0x165/0x260

The bug is caused by us under-counting the number of memory ranges
and subsequently not allocating enough ELF header space for them.
The bug is typically masked on smaller systems, because the ELF header
allocation is rounded up to the next page.

This patch modifies the code in fill_up_crash_elf_data() by using
walk_system_ram_res() instead of walk_system_ram_range() to correctly
count the max number of crash memory ranges. That's because the
walk_system_ram_range() filters out small memory regions that
reside in the same page, but walk_system_ram_res() does not.

Here's how I found the bug:

After tracing prepare_elf64_headers() and prepare_elf64_ram_headers_callback(),
the code uses walk_system_ram_res() to fill-in crash memory regions information
to the program header, so it counts those small memory regions that
reside in a page area.

But, when the kernel was using walk_system_ram_range() in
fill_up_crash_elf_data() to count the number of crash memory regions,
it filters out small regions.

I printed those small memory regions, for example:

  kexec: Get nr_ram ranges. vaddr=0xffff880077592258 paddr=0x77592258, sz=0xdc0

Based on the code in walk_system_ram_range(), this memory region
will be filtered out:

  pfn = (0x77592258 + 0x1000 - 1) >> 12 = 0x77593
  end_pfn = (0x77592258 + 0xfc0 -1 + 1) >> 12 = 0x77593
  end_pfn - pfn = 0x77593 - 0x77593 = 0  <=== if (end_pfn > pfn) is FALSE

So, the max_nr_ranges that's counted by the kernel doesn't include
small memory regions - causing us to under-allocate the required space.
That causes the page fault crash that happens in a later code path
when preparing ELF headers.

This bug is not easy to reproduce on small machines that have few
CPUs, because the allocated page aligned ELF buffer has more free
space to cover those small memory regions' PT_LOAD headers.

Signed-off-by: Lee, Chun-Yi 
Cc: Andy Lutomirski 
Cc: Baoquan He 
Cc: Jiang Liu 
Cc: Linus Torvalds 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Stephen Rothwell 
Cc: Takashi Iwai 
Cc: Thomas Gleixner 
Cc: Viresh Kumar 
Cc: Vivek Goyal 
Cc: kexec@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: 
Link: http://lkml.kernel.org/r/1443531537-29436-1-git-send-email-jlee@suse.com
Signed-off-by: Ingo Molnar

x86/mm: Decouple from

2015-06-03T10:02:00+00:00

Nothing in  uses anything from , so
remove it from there and fix up the resulting build problems
triggered on x86 {64|32}-bit {def|allmod|allno}configs.

The breakages were triggering in places where x86 builds relied
on vmalloc() facilities but did not include 
explicitly and relied on the implicit inclusion via .

Also add:

  -  to 
  -  to 

... which were two other implicit header file dependencies.

Suggested-by: David Miller 
Signed-off-by: Stephen Rothwell 
[ Tidied up the changelog. ]
Acked-by: David Miller 
Acked-by: Takashi Iwai 
Acked-by: Viresh Kumar 
Acked-by: Vinod Koul 
Cc: Andrew Morton 
Cc: Anton Vorontsov 
Cc: Boris Ostrovsky 
Cc: Colin Cross 
Cc: David Vrabel 
Cc: H. Peter Anvin 
Cc: Haiyang Zhang 
Cc: James E.J. Bottomley 
Cc: Jaroslav Kysela 
Cc: K. Y. Srinivasan 
Cc: Kees Cook 
Cc: Konrad Rzeszutek Wilk 
Cc: Kristen Carlson Accardi 
Cc: Len Brown 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Rafael J. Wysocki 
Cc: Suma Ramars 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Signed-off-by: Ingo Molnar

x86/asm/entry: Change all 'user_mode_vm()' calls to 'user_mode()'

2015-03-23T10:14:17+00:00

user_mode_vm() and user_mode() are now the same.  Change all callers
of user_mode_vm() to user_mode().

The next patch will remove the definition of user_mode_vm.

Signed-off-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brad Spengler 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/43b1f57f3df70df5a08b0925897c660725015554.1426728647.git.luto@kernel.org
[ Merged to a more recent kernel. ]
Signed-off-by: Ingo Molnar

x86, irq: Move IOAPIC related declarations from hw_irq.h into io_apic.h

2014-12-16T13:08:17+00:00

Clean up code by moving IOAPIC related declarations from hw_irq.h into
io_apic.h.

Signed-off-by: Jiang Liu 
Cc: Konrad Rzeszutek Wilk 
Cc: Tony Luck 
Cc: Joerg Roedel 
Cc: Greg Kroah-Hartman 
Cc: H. Peter Anvin 
Cc: Benjamin Herrenschmidt 
Cc: Rafael J. Wysocki 
Cc: Bjorn Helgaas 
Cc: Randy Dunlap 
Cc: Yinghai Lu 
Cc: Borislav Petkov 
Cc: Prarit Bhargava 
Cc: Grant Likely 
Cc: Vivek Goyal 
Cc: Baoquan He 
Cc: Matt Fleming 
Cc: Fenghua Yu 
Cc: Christian Gmeiner 
Cc: Aubrey 
Cc: Ryan Desfosses 
Cc: Quentin Lambert 
Cc: Rafael J. Wysocki 
Link: http://lkml.kernel.org/r/1414397531-28254-14-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner

kexec: check if crashk_res_low exists when exclude it from crash mem ranges

2014-10-14T00:18:21+00:00

Add a check if crashk_res_low exists just like GART region does.  If
crashk_res_low doesn't exist, calling exclude_mem_range is unnecessary.

Meanwhile, since crashk_res_low has been initialized at definition, it's
safe just use "if (crashk_low_res.end)" to check if it's exist.  And this
can make it consistent with other places of check.

Signed-off-by: Baoquan He 
Acked-by: Vivek Goyal 
Cc: Eric W. Biederman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kexec: create a new config option CONFIG_KEXEC_FILE for new syscall

2014-08-29T23:28:16+00:00

Currently new system call kexec_file_load() and all the associated code
compiles if CONFIG_KEXEC=y.  But new syscall also compiles purgatory
code which currently uses gcc option -mcmodel=large.  This option seems
to be available only gcc 4.4 onwards.

Hiding new functionality behind a new config option will not break
existing users of old gcc.  Those who wish to enable new functionality
will require new gcc.  Having said that, I am trying to figure out how
can I move away from using -mcmodel=large but that can take a while.

I think there are other advantages of introducing this new config
option.  As this option will be enabled only on x86_64, other arches
don't have to compile generic kexec code which will never be used.  This
new code selects CRYPTO=y and CRYPTO_SHA256=y.  And all other arches had
to do this for CONFIG_KEXEC.  Now with introduction of new config
option, we can remove crypto dependency from other arches.

Now CONFIG_KEXEC_FILE is available only on x86_64.  So whereever I had
CONFIG_X86_64 defined, I got rid of that.

For CONFIG_KEXEC_FILE, instead of doing select CRYPTO=y, I changed it to
"depends on CRYPTO=y".  This should be safer as "select" is not
recursive.

Signed-off-by: Vivek Goyal 
Cc: Eric Biederman 
Cc: H. Peter Anvin 
Tested-by: Shaun Ruffell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kexec: support for kexec on panic using new system call

2014-08-08T22:57:33+00:00

This patch adds support for loading a kexec on panic (kdump) kernel usning
new system call.

It prepares ELF headers for memory areas to be dumped and for saved cpu
registers.  Also prepares the memory map for second kernel and limits its
boot to reserved areas only.

Signed-off-by: Vivek Goyal 
Cc: Borislav Petkov 
Cc: Michael Kerrisk 
Cc: Yinghai Lu 
Cc: Eric Biederman 
Cc: H. Peter Anvin 
Cc: Matthew Garrett 
Cc: Greg Kroah-Hartman 
Cc: Dave Young 
Cc: WANG Chao 
Cc: Baoquan He 
Cc: Andy Lutomirski 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

x86, crash: Unify ifdef

2014-03-13T22:32:44+00:00

Merge two back-to-back CONFIG_X86_32 ifdefs into one.

Signed-off-by: Borislav Petkov 
Link: http://lkml.kernel.org/r/1394633584-5509-3-git-send-email-bp@alien8.de
Signed-off-by: H. Peter Anvin

x86: Delete non-required instances of include

2014-01-07T05:25:18+00:00

None of these files are actually using any __init type directives
and hence don't need to include .  Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.

[ hpa: undid incorrect removal from arch/x86/kernel/head_32.S ]

Signed-off-by: Paul Gortmaker 
Link: http://lkml.kernel.org/r/1389054026-12947-1-git-send-email-paul.gortmaker@windriver.com
Signed-off-by: H. Peter Anvin