1. 06 Aug, 2020 1 commit
  2. 09 Jan, 2020 1 commit
  3. 14 Nov, 2019 3 commits
    • Borislav Petkov's avatar
      x86/crash: Align function arguments on opening braces · 9eff3037
      Borislav Petkov authored
      
      
      ... or let function calls stick out and thus remain on a single line,
      even if the 80 cols rule is violated by a couple of chars, for better
      readability.
      
      No functional changes.
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: x86@kernel.org
      Link: https://lkml.kernel.org/r/20191114172200.19563-1-bp@alien8.de
      9eff3037
    • Lianbo Jiang's avatar
      x86/kdump: Remove the backup region handling · 7c321eb2
      Lianbo Jiang authored
      
      
      When the crashkernel kernel command line option is specified, the low
      1M memory will always be reserved now. Therefore, it's not necessary to
      create a backup region anymore and also no need to copy the contents of
      the first 640k to it.
      
      Remove all the code related to handling that backup region.
      
       [ bp: Massage commit message. ]
      Signed-off-by: default avatarLianbo Jiang <lijiang@redhat.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: bhe@redhat.com
      Cc: Dave Young <dyoung@redhat.com>
      Cc: d.hatayama@fujitsu.com
      Cc: dhowells@redhat.com
      Cc: ebiederm@xmission.com
      Cc: horms@verge.net.au
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jürgen Gross <jgross@suse.com>
      Cc: kexec@lists.infradead.org
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Cc: vgoyal@redhat.com
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20191108090027.11082-3-lijiang@redhat.com
      7c321eb2
    • Lianbo Jiang's avatar
      x86/kdump: Always reserve the low 1M when the crashkernel option is specified · 6f599d84
      Lianbo Jiang authored
      
      
      On x86, purgatory() copies the first 640K of memory to a backup region
      because the kernel needs those first 640K for the real mode trampoline
      during boot, among others.
      
      However, when SME is enabled, the kernel cannot properly copy the old
      memory to the backup area but reads only its encrypted contents. The
      result is that the crash tool gets invalid pointers when parsing vmcore:
      
        crash> kmem -s|grep -i invalid
        kmem: dma-kmalloc-512: slab:ffffd77680001c00 invalid freepointer:a6086ac099f0c5a4
        kmem: dma-kmalloc-512: slab:ffffd77680001c00 invalid freepointer:a6086ac099f0c5a4
        crash>
      
      So reserve the remaining low 1M memory when the crashkernel option is
      specified (after reserving real mode memory) so that allocated memory
      does not fall into the low 1M area and thus the copying of the contents
      of the first 640k to a backup region in purgatory() can be avoided
      altogether.
      
      This way, it does not need to be included in crash dumps or used for
      anything except the trampolines that must live in the low 1M.
      
       [ bp: Heavily rewrite commit message, flip check logic in
         crash_reserve_low_1M().]
      Signed-off-by: default avatarLianbo Jiang <lijiang@redhat.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: bhe@redhat.com
      Cc: Dave Young <dyoung@redhat.com>
      Cc: d.hatayama@fujitsu.com
      Cc: dhowells@redhat.com
      Cc: ebiederm@xmission.com
      Cc: horms@verge.net.au
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jürgen Gross <jgross@suse.com>
      Cc: kexec@lists.infradead.org
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Cc: vgoyal@redhat.com
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20191108090027.11082-2-lijiang@redhat.com
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=204793
      6f599d84
  4. 24 Jul, 2019 1 commit
  5. 26 Jun, 2019 1 commit
  6. 25 Jun, 2019 1 commit
  7. 20 Jun, 2019 1 commit
    • Lianbo Jiang's avatar
      x86/crash: Add e820 reserved ranges to kdump kernel's e820 table · 980621da
      Lianbo Jiang authored
      At present, when using the kexec_file_load() syscall to load the kernel
      image and initramfs, for example:
      
        kexec -s -p xxx
      
      the kernel does not pass the e820 reserved ranges to the second kernel,
      which might cause two problems:
      
       1. MMCONFIG: A device in PCI segment 1 cannot be discovered by the
      kernel PCI probing without all the e820 I/O reservations being present
      in the e820 table. Which is the case currently, because the kdump kernel
      does not have those reservations because the kexec command does not pass
      the I/O reservation via the "memmap=xxx" command line option.
      
      Further details courtesy of Bjorn Helgaas¹: I think you should regard
      correct MCFG/ECAM usage in the kdump kernel as a requirement. MMCONFIG
      (aka ECAM) space is described in the ACPI MCFG table. If you don't have
      ECAM:
      
        (a) PCI devices won't work at all on non-x86 systems that use only
         ECAM for config access,
      
        (b) you won't be able to access devices on non-0 segments (granted,
        there aren't very many of these yet, but there will be more in the
        future), and
      
        (c) you won't be able to access extended config space (addresses
        0x100-0xfff), which means none of the Extended Capabilities will be
        available (AER, ACS, ATS, etc).
      
       2. The second issue is that the SME kdump kernel doesn't work without
      the e820 reserved ranges. When SME is active in the kdump kernel, those
      reserved regions are still decrypted, but because those reserved ranges
      are not present at all in kdump kernel's e820 table, they are accessed
      as encrypted. Which is obviously wrong.
      
       [1]: https://lkml.kernel.org/r/CABhMZUUscS3jUZUSM5Y6EYJK6weo7Mjj5-EAKGvbw0qEe%2B38zw@mail.gmail.com
      
      
      
       [ bp: Heavily massage commit message. ]
      Suggested-by: default avatarDave Young <dyoung@redhat.com>
      Signed-off-by: default avatarLianbo Jiang <lijiang@redhat.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Bjorn Helgaas <bjorn.helgaas@gmail.com>
      Cc: dave.hansen@linux.intel.com
      Cc: Dave Young <dyoung@redhat.com>
      Cc: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: kexec@lists.infradead.org
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Cc: x86-ml <x86@kernel.org>
      Cc: Yi Wang <wang.yi59@zte.com.cn>
      Link: https://lkml.kernel.org/r/20190423013007.17838-4-lijiang@redhat.com
      980621da
  8. 21 May, 2019 1 commit
  9. 05 Apr, 2019 1 commit
  10. 15 Jan, 2019 1 commit
    • Dave Young's avatar
      x86/kexec: Fix a kexec_file_load() failure · 993a1103
      Dave Young authored
      Commit
      
        b6664ba4 ("s390, kexec_file: drop arch_kexec_mem_walk()")
      
      changed the behavior of kexec_locate_mem_hole(): it will try to allocate
      free memory only when kbuf.mem is initialized to zero.
      
      However, x86's kexec_file_load() implementation reuses a struct
      kexec_buf allocated on the stack and its kbuf.mem member gets set by
      each kexec_add_buffer() invocation.
      
      The second kexec_add_buffer() will reuse the same kbuf but not
      reinitialize kbuf.mem.
      
      Therefore, explictily reset kbuf.mem each time in order for
      kexec_locate_mem_hole() to locate a free memory region each time.
      
       [ bp: massage commit message. ]
      
      Fixes: b6664ba4
      
       ("s390, kexec_file: drop arch_kexec_mem_walk()")
      Signed-off-by: default avatarDave Young <dyoung@redhat.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Acked-by: default avatarBaoquan He <bhe@redhat.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Philipp Rudo <prudo@linux.vnet.ibm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Yannik Sembritzki <yannik@sembritzki.me>
      Cc: Yi Wang <wang.yi59@zte.com.cn>
      Cc: kexec@lists.infradead.org
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20181228011247.GA9999@dhcp-128-65.nay.redhat.com
      993a1103
  11. 23 Nov, 2018 1 commit
    • Yi Wang's avatar
      x86/headers: Fix -Wmissing-prototypes warning · 89f579ce
      Yi Wang authored
      
      
      When building the kernel with W=1 we get a lot of -Wmissing-prototypes
      warnings, which are trivial in nature and easy to fix - and which may
      mask some real future bugs if the prototypes get out of sync with
      the function definition.
      
      This patch fixes most of -Wmissing-prototypes warnings which
      are in the root directory of arch/x86/kernel, not including
      the subdirectories.
      
      These are the warnings fixed in this patch:
      
        arch/x86/kernel/signal.c:865:17: warning: no previous prototype for ‘sys32_x32_rt_sigreturn’ [-Wmissing-prototypes]
        arch/x86/kernel/signal_compat.c:164:6: warning: no previous prototype for ‘sigaction_compat_abi’ [-Wmissing-prototypes]
        arch/x86/kernel/traps.c:625:46: warning: no previous prototype for ‘sync_regs’ [-Wmissing-prototypes]
        arch/x86/kernel/traps.c:640:24: warning: no previous prototype for ‘fixup_bad_iret’ [-Wmissing-prototypes]
        arch/x86/kernel/traps.c:929:13: warning: no previous prototype for ‘trap_init’ [-Wmissing-prototypes]
        arch/x86/kernel/irq.c:270:28: warning: no previous prototype for ‘smp_x86_platform_ipi’ [-Wmissing-prototypes]
        arch/x86/kernel/irq.c:301:16: warning: no previous prototype for ‘smp_kvm_posted_intr_ipi’ [-Wmissing-prototypes]
        arch/x86/kernel/irq.c:314:16: warning: no previous prototype for ‘smp_kvm_posted_intr_wakeup_ipi’ [-Wmissing-prototypes]
        arch/x86/kernel/irq.c:328:16: warning: no previous prototype for ‘smp_kvm_posted_intr_nested_ipi’ [-Wmissing-prototypes]
        arch/x86/kernel/irq_work.c:16:28: warning: no previous prototype for ‘smp_irq_work_interrupt’ [-Wmissing-prototypes]
        arch/x86/kernel/irqinit.c:79:13: warning: no previous prototype for ‘init_IRQ’ [-Wmissing-prototypes]
        arch/x86/kernel/quirks.c:672:13: warning: no previous prototype for ‘early_platform_quirks’ [-Wmissing-prototypes]
        arch/x86/kernel/tsc.c:1499:15: warning: no previous prototype for ‘calibrate_delay_is_known’ [-Wmissing-prototypes]
        arch/x86/kernel/process.c:653:13: warning: no previous prototype for ‘arch_post_acpi_subsys_init’ [-Wmissing-prototypes]
        arch/x86/kernel/process.c:717:15: warning: no previous prototype for ‘arch_randomize_brk’ [-Wmissing-prototypes]
        arch/x86/kernel/process.c:784:6: warning: no previous prototype for ‘do_arch_prctl_common’ [-Wmissing-prototypes]
        arch/x86/kernel/reboot.c:869:6: warning: no previous prototype for ‘nmi_panic_self_stop’ [-Wmissing-prototypes]
        arch/x86/kernel/smp.c:176:27: warning: no previous prototype for ‘smp_reboot_interrupt’ [-Wmissing-prototypes]
        arch/x86/kernel/smp.c:260:28: warning: no previous prototype for ‘smp_reschedule_interrupt’ [-Wmissing-prototypes]
        arch/x86/kernel/smp.c:281:28: warning: no previous prototype for ‘smp_call_function_interrupt’ [-Wmissing-prototypes]
        arch/x86/kernel/smp.c:291:28: warning: no previous prototype for ‘smp_call_function_single_interrupt’ [-Wmissing-prototypes]
        arch/x86/kernel/ftrace.c:840:6: warning: no previous prototype for ‘arch_ftrace_update_trampoline’ [-Wmissing-prototypes]
        arch/x86/kernel/ftrace.c:934:7: warning: no previous prototype for ‘arch_ftrace_trampoline_func’ [-Wmissing-prototypes]
        arch/x86/kernel/ftrace.c:946:6: warning: no previous prototype for ‘arch_ftrace_trampoline_free’ [-Wmissing-prototypes]
        arch/x86/kernel/crash.c:114:6: warning: no previous prototype for ‘crash_smp_send_stop’ [-Wmissing-prototypes]
        arch/x86/kernel/crash.c:351:5: warning: no previous prototype for ‘crash_setup_memmap_entries’ [-Wmissing-prototypes]
        arch/x86/kernel/crash.c:424:5: warning: no previous prototype for ‘crash_load_segments’ [-Wmissing-prototypes]
        arch/x86/kernel/machine_kexec_64.c:372:7: warning: no previous prototype for ‘arch_kexec_kernel_image_load’ [-Wmissing-prototypes]
        arch/x86/kernel/paravirt-spinlocks.c:12:16: warning: no previous prototype for ‘__native_queued_spin_unlock’ [-Wmissing-prototypes]
        arch/x86/kernel/paravirt-spinlocks.c:18:6: warning: no previous prototype for ‘pv_is_native_spin_unlock’ [-Wmissing-prototypes]
        arch/x86/kernel/paravirt-spinlocks.c:24:16: warning: no previous prototype for ‘__native_vcpu_is_preempted’ [-Wmissing-prototypes]
        arch/x86/kernel/paravirt-spinlocks.c:30:6: warning: no previous prototype for ‘pv_is_native_vcpu_is_preempted’ [-Wmissing-prototypes]
        arch/x86/kernel/kvm.c:258:1: warning: no previous prototype for ‘do_async_page_fault’ [-Wmissing-prototypes]
        arch/x86/kernel/jailhouse.c:200:6: warning: no previous prototype for ‘jailhouse_paravirt’ [-Wmissing-prototypes]
        arch/x86/kernel/check.c:91:13: warning: no previous prototype for ‘setup_bios_corruption_check’ [-Wmissing-prototypes]
        arch/x86/kernel/check.c:139:6: warning: no previous prototype for ‘check_for_bios_corruption’ [-Wmissing-prototypes]
        arch/x86/kernel/devicetree.c:32:13: warning: no previous prototype for ‘early_init_dt_scan_chosen_arch’ [-Wmissing-prototypes]
        arch/x86/kernel/devicetree.c:42:13: warning: no previous prototype for ‘add_dtb’ [-Wmissing-prototypes]
        arch/x86/kernel/devicetree.c:108:6: warning: no previous prototype for ‘x86_of_pci_init’ [-Wmissing-prototypes]
        arch/x86/kernel/devicetree.c:314:13: warning: no previous prototype for ‘x86_dtb_init’ [-Wmissing-prototypes]
        arch/x86/kernel/tracepoint.c:16:5: warning: no previous prototype for ‘trace_pagefault_reg’ [-Wmissing-prototypes]
        arch/x86/kernel/tracepoint.c:22:6: warning: no previous prototype for ‘trace_pagefault_unreg’ [-Wmissing-prototypes]
        arch/x86/kernel/head64.c:113:22: warning: no previous prototype for ‘__startup_64’ [-Wmissing-prototypes]
        arch/x86/kernel/head64.c:262:15: warning: no previous prototype for ‘__startup_secondary_64’ [-Wmissing-prototypes]
        arch/x86/kernel/head64.c:350:12: warning: no previous prototype for ‘early_make_pgtable’ [-Wmissing-prototypes]
      
      [ mingo: rewrote the changelog, fixed build errors. ]
      Signed-off-by: default avatarYi Wang <wang.yi59@zte.com.cn>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: akataria@vmware.com
      Cc: akpm@linux-foundation.org
      Cc: andy.shevchenko@gmail.com
      Cc: anton@enomsg.org
      Cc: ard.biesheuvel@linaro.org
      Cc: bhe@redhat.com
      Cc: bhelgaas@google.com
      Cc: bp@alien8.de
      Cc: ccross@android.com
      Cc: devicetree@vger.kernel.org
      Cc: douly.fnst@cn.fujitsu.com
      Cc: dwmw@amazon.co.uk
      Cc: dyoung@redhat.com
      Cc: ebiederm@xmission.com
      Cc: frank.rowand@sony.com
      Cc: frowand.list@gmail.com
      Cc: ivan.gorinov@intel.com
      Cc: jailhouse-dev@googlegroups.com
      Cc: jan.kiszka@siemens.com
      Cc: jgross@suse.com
      Cc: jroedel@suse.de
      Cc: keescook@chromium.org
      Cc: kexec@lists.infradead.org
      Cc: konrad.wilk@oracle.com
      Cc: kvm@vger.kernel.org
      Cc: linux-efi@vger.kernel.org
      Cc: linux-pci@vger.kernel.org
      Cc: luto@kernel.org
      Cc: m.mizuma@jp.fujitsu.com
      Cc: namit@vmware.com
      Cc: oleg@redhat.com
      Cc: pasha.tatashin@oracle.com
      Cc: pbonzini@redhat.com
      Cc: prarit@redhat.com
      Cc: pravin.shedge4linux@gmail.com
      Cc: rajvi.jingar@intel.com
      Cc: rkrcmar@redhat.com
      Cc: robh+dt@kernel.org
      Cc: robh@kernel.org
      Cc: rostedt@goodmis.org
      Cc: takahiro.akashi@linaro.org
      Cc: thomas.lendacky@amd.com
      Cc: tony.luck@intel.com
      Cc: up2wing@gmail.com
      Cc: virtualization@lists.linux-foundation.org
      Cc: zhe.he@windriver.com
      Cc: zhong.weidong@zte.com.cn
      Link: http://lkml.kernel.org/r/1542852249-19820-1-git-send-email-wang.yi59@zte.com.cn
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      89f579ce
  12. 14 Apr, 2018 5 commits
  13. 17 Feb, 2018 1 commit
    • Baoquan He's avatar
      x86/apic: Fix restoring boot IRQ mode in reboot and kexec/kdump · 339b2ae0
      Baoquan He authored
      This is a regression fix.
      
      Before, to fix erratum AVR31, the following commit:
      
        522e6646
      
       ("x86/apic: Disable I/O APIC before shutdown of the local APIC")
      
      ... moved the lapic_shutdown() call to after disable_IO_APIC() in the reboot
      and kexec/kdump code paths.
      
      This introduced the following regression: disable_IO_APIC() not only clears
      the IO-APIC, but it also restores boot IRQ mode by setting the
      LAPIC/APIC/IMCR, calling lapic_shutdown() after disable_IO_APIC() will
      disable LAPIC and ruin the possible virtual wire mode setting which
      the code has been trying to do all along.
      
      The consequence is that a KVM guest kernel always prints the warning below
      during kexec/kdump as the kernel boots up:
      
        [    0.001000] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/apic/apic.c:1467 setup_local_APIC+0x228/0x330
        [    ........]
        [    0.001000] Call Trace:
        [    0.001000]  apic_bsp_setup+0x56/0x74
        [    0.001000]  x86_late_time_init+0x11/0x16
        [    0.001000]  start_kernel+0x3c9/0x486
        [    0.001000]  secondary_startup_64+0xa5/0xb0
        [    ........]
        [    0.001000] masked ExtINT on CPU#0
      
      To fix this, just call clear_IO_APIC() to stop the IO-APIC where
      disable_IO_APIC() was called, and call restore_boot_irq_mode() to
      restore boot IRQ mode before a reboot or a kexec/kdump jump.
      Signed-off-by: default avatarBaoquan He <bhe@redhat.com>
      Reviewed-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: douly.fnst@cn.fujitsu.com
      Cc: joro@8bytes.org
      Cc: prarit@redhat.com
      Cc: stable@vger.kernel.org
      Cc: uobergfe@redhat.com
      Fixes: commit 522e6646 ("x86/apic: Disable I/O APIC before shutdown of the local APIC")
      Link: http://lkml.kernel.org/r/20180214054656.3780-4-bhe@redhat.com
      
      
      [ Rewrote the changelog. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      339b2ae0
  14. 07 Nov, 2017 2 commits
  15. 12 Jul, 2017 1 commit
  16. 28 Jan, 2017 6 commits
    • Ingo Molnar's avatar
      x86/boot/e820: Clean up the E820 table size define names · 08b46d5d
      Ingo Molnar authored
      
      
      We've got a number of defines related to the E820 table and its size:
      
      	E820MAP
      	E820NR
      	E820_X_MAX
      	E820MAX
      
      The first two denote byte offsets into the zeropage (struct boot_params),
      and can are not used in the kernel and can be removed.
      
      The E820_*_MAX values have an inconsistent structure and it's unclear in any
      case what they mean. 'X' presuably goes for extended - but it's not very
      expressive altogether.
      
      Change these over to:
      
      	E820_MAX_ENTRIES_ZEROPAGE
      	E820_MAX_ENTRIES
      
      ... which are self-explanatory names.
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      08b46d5d
    • Ingo Molnar's avatar
      x86/boot/e820: Prefix the E820_* type names with "E820_TYPE_" · 09821ff1
      Ingo Molnar authored
      
      
      So there's a number of constants that start with "E820" but which
      are not types - these create a confusing mixture when seen together
      with 'enum e820_type' values:
      
      	E820MAP
      	E820NR
      	E820_X_MAX
      	E820MAX
      
      To better differentiate the 'enum e820_type' values prefix them
      with E820_TYPE_.
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      09821ff1
    • Ingo Molnar's avatar
      x86/boot/e820: Rename everything to e820_table · 61a50101
      Ingo Molnar authored
      
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      61a50101
    • Ingo Molnar's avatar
      x86/boot/e820: Rename 'e820_map' variables to 'e820_array' · acd4c048
      Ingo Molnar authored
      
      
      In line with the rename to 'struct e820_array', harmonize the naming of common e820
      table variable names as well:
      
       e820          =>  e820_array
       e820_saved    =>  e820_array_saved
       e820_map      =>  e820_array
       initial_e820  =>  e820_array_init
      
      This makes the variable names more consistent  and easier to grep for.
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      acd4c048
    • Ingo Molnar's avatar
      x86/boot/e820: Rename the basic e820 data types to 'struct e820_entry' and 'struct e820_array' · 8ec67d97
      Ingo Molnar authored
      
      
      The 'e820entry' and 'e820map' names have various annoyances:
      
       - the missing underscore departs from the usual kernel style
         and makes the code look weird,
      
       - in the past I kept confusing the 'map' with the 'entry', because
         a 'map' is ambiguous in that regard,
      
       - it's not really clear from the 'e820map' that this is a regular
         C array.
      
      Rename them to 'struct e820_entry' and 'struct e820_array' accordingly.
      
      ( Leave the legacy UAPI header alone but do the rename in the bootparam.h
        and e820/types.h file - outside tools relying on these defines should
        either adjust their code, or should use the legacy header, or should
        create their private copies for the definitions. )
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      8ec67d97
    • Ingo Molnar's avatar
      x86/boot/e820: Remove spurious asm/e820/api.h inclusions · 5520b7e7
      Ingo Molnar authored
      
      
      A commonly used lowlevel x86 header, asm/pgtable.h, includes asm/e820/api.h
      spuriously, without making direct use of it.
      
      Removing it is not simple: over the years various .c code learned to rely
      on this indirect inclusion.
      
      Remove the unnecessary include - this should speed up the kernel build a bit,
      as a large header is not included anymore in totally unrelated code.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      5520b7e7
  17. 30 Nov, 2016 1 commit
  18. 11 Oct, 2016 1 commit
    • Hidehiro Kawai's avatar
      x86/panic: replace smp_send_stop() with kdump friendly version in panic path · 0ee59413
      Hidehiro Kawai authored
      Daniel Walker reported problems which happens when
      crash_kexec_post_notifiers kernel option is enabled
      (https://lkml.org/lkml/2015/6/24/44).
      
      In that case, smp_send_stop() is called before entering kdump routines
      which assume other CPUs are still online.  As the result, for x86, kdump
      routines fail to save other CPUs' registers and disable virtualization
      extensions.
      
      To fix this problem, call a new kdump friendly function,
      crash_smp_send_stop(), instead of the smp_send_stop() when
      crash_kexec_post_notifiers is enabled.  crash_smp_send_stop() is a weak
      function, and it just call smp_send_stop().  Architecture codes should
      override it so that kdump can work appropriately.  This patch only
      provides x86-specific version.
      
      For Xen's PV kernel, just keep the current behavior.
      
      NOTES:
      
      - Right solution would be to place crash_smp_send_stop() before
        __crash_kexec() invocation in all cases and remove smp_send_stop(), but
        we can't do that until all architectures implement own
        crash_smp_send_stop()
      
      - crash_smp_send_stop()-like work is still needed by
        machine_crash_shutdown() because crash_kexec() can be called without
        entering panic()
      
      Fixes: f06e5153 (kernel/panic.c: add "crash_kexec_post_notifiers" option)
      Link: http://lkml.kernel.org/r/20160810080948.11028.15344.stgit@sysi4-13.yrl.intra.hitachi.co.jp
      
      Signed-off-by: default avatarHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Reported-by: default avatarDaniel Walker <dwalker@fifo99.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Daniel Walker <dwalker@fifo99.com>
      Cc: Xunlei Pang <xpang@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Toshi Kani <toshi.kani@hpe.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: David Daney <david.daney@cavium.com>
      Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
      Cc: "Steven J. Hill" <steven.hill@cavium.com>
      Cc: Corey Minyard <cminyard@mvista.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0ee59413
  19. 14 Jul, 2016 1 commit
    • Paul Gortmaker's avatar
      x86/kernel: Audit and remove any unnecessary uses of module.h · 186f4360
      Paul Gortmaker authored
      
      
      Historically a lot of these existed because we did not have
      a distinction between what was modular code and what was providing
      support to modules via EXPORT_SYMBOL and friends.  That changed
      when we forked out support for the latter into the export.h file.
      
      This means we should be able to reduce the usage of module.h
      in code that is obj-y Makefile or bool Kconfig.  The advantage
      in doing so is that module.h itself sources about 15 other headers;
      adding significantly to what we feed cpp, and it can obscure what
      headers we are effectively using.
      
      Since module.h was the source for init.h (for __init) and for
      export.h (for EXPORT_SYMBOL) we consider each obj-y/bool instance
      for the presence of either and replace as needed.  Build testing
      revealed some implicit header usage that was fixed up accordingly.
      
      Note that some bool/obj-y instances remain since module.h is
      the header for some exception table entry stuff, and for things
      like __init_or_module (code that is tossed when MODULES=n).
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20160714001901.31603-4-paul.gortmaker@windriver.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      186f4360
  20. 30 Jan, 2016 2 commits
    • Toshi Kani's avatar
      x86/kexec: Remove walk_iomem_res() call with GART type · f296f263
      Toshi Kani authored
      There is no longer any driver inserting a "GART" region in the
      kernel since
      
        707d4eef
      
       ("Revert "[PATCH] Insert GART region into resource map"").
      
      Remove the call to walk_iomem_res() with "GART" type, its
      callback function, and GART-specific variables set by the
      callback.
      Signed-off-by: default avatarToshi Kani <toshi.kani@hpe.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Reviewed-by: default avatarDave Young <dyoung@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Chun-Yi <joeyli.kernel@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Lee, Chun-Yi <joeyli.kernel@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Minfei Huang <mnfhuang@gmail.com>
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Takao Indoh <indou.takao@jp.fujitsu.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: kexec@lists.infradead.org
      Cc: linux-arch@vger.kernel.org
      Cc: linux-mm <linux-mm@kvack.org>
      Link: http://lkml.kernel.org/r/1453841853-11383-16-git-send-email-bp@alien8.de
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      f296f263
    • Toshi Kani's avatar
      x86, kexec, nvdimm: Use walk_iomem_res_desc() for iomem search · f0f4711a
      Toshi Kani authored
      
      
      Change the callers of walk_iomem_res() scanning for the
      following resources by name to use walk_iomem_res_desc()
      instead.
      
       "ACPI Tables"
       "ACPI Non-volatile Storage"
       "Persistent Memory (legacy)"
       "Crash kernel"
      
      Note, the caller of walk_iomem_res() with "GART" will be removed
      in a later patch.
      Signed-off-by: default avatarToshi Kani <toshi.kani@hpe.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Reviewed-by: default avatarDave Young <dyoung@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Chun-Yi <joeyli.kernel@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Lee, Chun-Yi <joeyli.kernel@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Minfei Huang <mnfhuang@gmail.com>
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Takao Indoh <indou.takao@jp.fujitsu.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: kexec@lists.infradead.org
      Cc: linux-arch@vger.kernel.org
      Cc: linux-mm <linux-mm@kvack.org>
      Cc: linux-nvdimm@lists.01.org
      Link: http://lkml.kernel.org/r/1453841853-11383-15-git-send-email-bp@alien8.de
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      f0f4711a
  21. 23 Nov, 2015 1 commit
    • Takao Indoh's avatar
      perf, x86: Stop Intel PT before kdump starts · da06a43d
      Takao Indoh authored
      
      
      This patch stops Intel PT logging and saves its registers in memory
      before kdump is started. This feature is needed to prevent Intel PT from
      overwriting its log buffer after panic, and saved registers are needed to
      find the last position where Intel PT wrote data.
      
      After the crash dump is captured by kdump, users can retrieve the log buffer
      from the vmcore and use it to investigate bad kernel behavior.
      Signed-off-by: default avatarTakao Indoh <indou.takao@jp.fujitsu.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin<alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: H.Peter Anvin <hpa@zytor.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Link: http://lkml.kernel.org/r/1446614553-6072-3-git-send-email-indou.takao@jp.fujitsu.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      da06a43d
  22. 12 Oct, 2015 1 commit
  23. 02 Oct, 2015 1 commit
    • Lee, Chun-Yi's avatar
      x86/kexec: Fix kexec crash in syscall kexec_file_load() · e3c41e37
      Lee, Chun-Yi authored
      
      
      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: [<ffffffff8103d645>] 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: default avatarLee, Chun-Yi <jlee@suse.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: kexec@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Cc: <stable@vger.kernel.org>
      Link: http://lkml.kernel.org/r/1443531537-29436-1-git-send-email-jlee@suse.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      e3c41e37
  24. 03 Jun, 2015 1 commit
    • Stephen Rothwell's avatar
      x86/mm: Decouple <linux/vmalloc.h> from <asm/io.h> · d6472302
      Stephen Rothwell authored
      
      
      Nothing in <asm/io.h> uses anything from <linux/vmalloc.h>, 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 <linux/vmalloc.h>
      explicitly and relied on the implicit inclusion via <asm/io.h>.
      
      Also add:
      
        - <linux/init.h> to <linux/io.h>
        - <asm/pgtable_types> to <asm/io.h>
      
      ... which were two other implicit header file dependencies.
      Suggested-by: default avatarDavid Miller <davem@davemloft.net>
      Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      [ Tidied up the changelog. ]
      Acked-by: default avatarDavid Miller <davem@davemloft.net>
      Acked-by: default avatarTakashi Iwai <tiwai@suse.de>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: default avatarVinod Koul <vinod.koul@intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Anton Vorontsov <anton@enomsg.org>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Colin Cross <ccross@android.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Cc: James E.J. Bottomley <JBottomley@odin.com>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Kristen Carlson Accardi <kristen@linux.intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Suma Ramars <sramars@cisco.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      d6472302
  25. 23 Mar, 2015 1 commit
  26. 16 Dec, 2014 1 commit
    • Jiang Liu's avatar
      x86, irq: Move IOAPIC related declarations from hw_irq.h into io_apic.h · 8643e28d
      Jiang Liu authored
      
      
      Clean up code by moving IOAPIC related declarations from hw_irq.h into
      io_apic.h.
      Signed-off-by: default avatarJiang Liu <jiang.liu@linux.intel.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Matt Fleming <matt.fleming@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
      Cc: Aubrey <aubrey.li@linux.intel.com>
      Cc: Ryan Desfosses <ryan@desfo.org>
      Cc: Quentin Lambert <lambert.quentin@gmail.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Link: http://lkml.kernel.org/r/1414397531-28254-14-git-send-email-jiang.liu@linux.intel.com
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      8643e28d
  27. 14 Oct, 2014 1 commit