1. 11 4月, 2017 2 次提交
  2. 05 4月, 2017 1 次提交
  3. 01 4月, 2017 1 次提交
  4. 31 3月, 2017 2 次提交
  5. 30 3月, 2017 1 次提交
    • J
      x86/build: Mostly disable '-maccumulate-outgoing-args' · 3f135e57
      Josh Poimboeuf 提交于
      The GCC '-maccumulate-outgoing-args' flag is enabled for most configs,
      mostly because of issues which are no longer relevant.  For most
      configs, and with most recent versions of GCC, it's no longer needed.
      
      Clarify which cases need it, and only enable it for those cases.  Also
      produce a compile-time error for the ftrace graph + mcount + '-Os' case,
      which will otherwise cause runtime failures.
      
      The main benefit of '-maccumulate-outgoing-args' is that it prevents an
      ugly prologue for functions which have aligned stacks.  But removing the
      option also has some benefits: more readable argument saves, smaller
      text size, and (presumably) slightly improved performance.
      
      Here are the object size savings for 32-bit and 64-bit defconfig
      kernels:
      
            text	   data	    bss	     dec	    hex	filename
        10006710	3543328	1773568	15323606	 e9d1d6	vmlinux.x86-32.before
         9706358	3547424	1773568	15027350	 e54c96	vmlinux.x86-32.after
      
            text	   data	    bss	     dec	    hex	filename
        10652105	4537576	 843776	16033457	 f4a6b1	vmlinux.x86-64.before
        10639629	4537576	 843776	16020981	 f475f5	vmlinux.x86-64.after
      
      That comes out to a 3% text size improvement on x86-32 and a 0.1% text
      size improvement on x86-64.
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andrew Lutomirski <luto@kernel.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20170316193133.zrj6gug53766m6nn@trebleSigned-off-by: NIngo Molnar <mingo@kernel.org>
      3f135e57
  6. 28 3月, 2017 3 次提交
  7. 24 3月, 2017 7 次提交
    • B
      x86/mm/KASLR: Exclude EFI region from KASLR VA space randomization · a46f60d7
      Baoquan He 提交于
      Currently KASLR is enabled on three regions: the direct mapping of physical
      memory, vamlloc and vmemmap. However the EFI region is also mistakenly
      included for VA space randomization because of misusing EFI_VA_START macro
      and assuming EFI_VA_START < EFI_VA_END.
      
      (This breaks kexec and possibly other things that rely on stable addresses.)
      
      The EFI region is reserved for EFI runtime services virtual mapping which
      should not be included in KASLR ranges. In Documentation/x86/x86_64/mm.txt,
      we can see:
      
        ffffffef00000000 - fffffffeffffffff (=64 GB) EFI region mapping space
      
      EFI uses the space from -4G to -64G thus EFI_VA_START > EFI_VA_END,
      Here EFI_VA_START = -4G, and EFI_VA_END = -64G.
      
      Changing EFI_VA_START to EFI_VA_END in mm/kaslr.c fixes this problem.
      Signed-off-by: NBaoquan He <bhe@redhat.com>
      Reviewed-by: NBhupesh Sharma <bhsharma@redhat.com>
      Acked-by: NDave Young <dyoung@redhat.com>
      Acked-by: NThomas Garnier <thgarnie@google.com>
      Cc: <stable@vger.kernel.org> #4.8+
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/1490331592-31860-1-git-send-email-bhe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      a46f60d7
    • W
      KVM: VMX: Fix enable VPID conditions · 08d839c4
      Wanpeng Li 提交于
      This can be reproduced by running L2 on L1, and disable VPID on L0
      if w/o commit "KVM: nVMX: Fix nested VPID vmx exec control", the L2
      crash as below:
      
      KVM: entry failed, hardware error 0x7
      EAX=00000000 EBX=00000000 ECX=00000000 EDX=000306c3
      ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
      EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
      ES =0000 00000000 0000ffff 00009300
      CS =f000 ffff0000 0000ffff 00009b00
      SS =0000 00000000 0000ffff 00009300
      DS =0000 00000000 0000ffff 00009300
      FS =0000 00000000 0000ffff 00009300
      GS =0000 00000000 0000ffff 00009300
      LDT=0000 00000000 0000ffff 00008200
      TR =0000 00000000 0000ffff 00008b00
      GDT=     00000000 0000ffff
      IDT=     00000000 0000ffff
      CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
      DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
      DR6=00000000ffff0ff0 DR7=0000000000000400
      EFER=0000000000000000
      
      Reference SDM 30.3 INVVPID:
      
      Protected Mode Exceptions
      - #UD
        - If not in VMX operation.
        - If the logical processor does not support VPIDs (IA32_VMX_PROCBASED_CTLS2[37]=0).
        - If the logical processor supports VPIDs (IA32_VMX_PROCBASED_CTLS2[37]=1) but does
          not support the INVVPID instruction (IA32_VMX_EPT_VPID_CAP[32]=0).
      
      So we should check both VPID enable bit in vmx exec control and INVVPID support bit
      in vmx capability MSRs to enable VPID. This patch adds the guarantee to not enable
      VPID if either INVVPID or single-context/all-context invalidation is not exposed in
      vmx capability MSRs.
      Reviewed-by: NDavid Hildenbrand <david@redhat.com>
      Reviewed-by: NJim Mattson <jmattson@google.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: NWanpeng Li <wanpeng.li@hotmail.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      08d839c4
    • W
      KVM: nVMX: Fix nested VPID vmx exec control · 63cb6d5f
      Wanpeng Li 提交于
      This can be reproduced by running kvm-unit-tests/vmx.flat on L0 w/ vpid disabled.
      
      Test suite: VPID
      Unhandled exception 6 #UD at ip 00000000004051a6
      error_code=0000      rflags=00010047      cs=00000008
      rax=0000000000000000 rcx=0000000000000001 rdx=0000000000000047 rbx=0000000000402f79
      rbp=0000000000456240 rsi=0000000000000001 rdi=0000000000000000
      r8=000000000000000a  r9=00000000000003f8 r10=0000000080010011 r11=0000000000000000
      r12=0000000000000003 r13=0000000000000708 r14=0000000000000000 r15=0000000000000000
      cr0=0000000080010031 cr2=0000000000000000 cr3=0000000007fff000 cr4=0000000000002020
      cr8=0000000000000000
      STACK: @4051a6 40523e 400f7f 402059 40028f
      
      We should hide and forbid VPID in L1 if it is disabled on L0. However, nested VPID
      enable bit is set unconditionally during setup nested vmx exec controls though VPID
      is not exposed through nested VMX capablity. This patch fixes it by don't set nested
      VPID enable bit if it is disabled on L0.
      
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: stable@vger.kernel.org
      Fixes: 5c614b35 (KVM: nVMX: nested VPID emulation)
      Signed-off-by: NWanpeng Li <wanpeng.li@hotmail.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      63cb6d5f
    • W
      KVM: x86: correct async page present tracepoint · 24dccf83
      Wanpeng Li 提交于
      After async pf setup successfully, there is a broadcast wakeup w/ special
      token 0xffffffff which tells vCPU that it should wake up all processes
      waiting for APFs though there is no real process waiting at the moment.
      
      The async page present tracepoint print prematurely and fails to catch the
      special token setup. This patch fixes it by moving the async page present
      tracepoint after the special token setup.
      
      Before patch:
      
      qemu-system-x86-8499  [006] ...1  5973.473292: kvm_async_pf_ready: token 0x0 gva 0x0
      
      After patch:
      
      qemu-system-x86-8499  [006] ...1  5973.473292: kvm_async_pf_ready: token 0xffffffff gva 0x0
      
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: NWanpeng Li <wanpeng.li@hotmail.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      24dccf83
    • J
      kvm: vmx: Flush TLB when the APIC-access address changes · fb6c8198
      Jim Mattson 提交于
      Quoting from the Intel SDM, volume 3, section 28.3.3.4: Guidelines for
      Use of the INVEPT Instruction:
      
      If EPT was in use on a logical processor at one time with EPTP X, it
      is recommended that software use the INVEPT instruction with the
      "single-context" INVEPT type and with EPTP X in the INVEPT descriptor
      before a VM entry on the same logical processor that enables EPT with
      EPTP X and either (a) the "virtualize APIC accesses" VM-execution
      control was changed from 0 to 1; or (b) the value of the APIC-access
      address was changed.
      
      In the nested case, the burden falls on L1, unless L0 enables EPT in
      vmcs02 when L1 doesn't enable EPT in vmcs12.
      Signed-off-by: NJim Mattson <jmattson@google.com>
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      fb6c8198
    • P
      KVM: x86: use pic/ioapic destructor when destroy vm · c761159c
      Peter Xu 提交于
      We have specific destructors for pic/ioapic, we'd better use them when
      destroying the VM as well.
      Signed-off-by: NPeter Xu <peterx@redhat.com>
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      c761159c
    • P
      KVM: x86: check existance before destroy · 950712eb
      Peter Xu 提交于
      Mostly used for split irqchip mode. In that case, these two things are
      not inited at all, so no need to release.
      Signed-off-by: NPeter Xu <peterx@redhat.com>
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      950712eb
  8. 23 3月, 2017 1 次提交
  9. 22 3月, 2017 2 次提交
  10. 20 3月, 2017 3 次提交
  11. 17 3月, 2017 3 次提交
  12. 16 3月, 2017 1 次提交
  13. 15 3月, 2017 3 次提交
    • J
      x86/intel_rdt: Put group node in rdtgroup_kn_unlock · 49ec8f5b
      Jiri Olsa 提交于
      The rdtgroup_kn_unlock waits for the last user to release and put its
      node. But it's calling kernfs_put on the node which calls the
      rdtgroup_kn_unlock, which might not be the group's directory node, but
      another group's file node.
      
      This race could be easily reproduced by running 2 instances
      of following script:
      
        mount -t resctrl resctrl /sys/fs/resctrl/
        pushd /sys/fs/resctrl/
        mkdir krava
        echo "krava" > krava/schemata
        rmdir krava
        popd
        umount  /sys/fs/resctrl
      
      It triggers the slub debug error message with following command
      line config: slub_debug=,kernfs_node_cache.
      
      Call kernfs_put on the group's node to fix it.
      
      Fixes: 60cf5e10 ("x86/intel_rdt: Add mkdir to resctrl file system")
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Shaohua Li <shli@fb.com>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/1489501253-20248-1-git-send-email-jolsa@kernel.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      49ec8f5b
    • J
      x86/unwind: Fix last frame check for aligned function stacks · 87a6b297
      Josh Poimboeuf 提交于
      Pavel Machek reported the following warning on x86-32:
      
        WARNING: kernel stack frame pointer at f50cdf98 in swapper/2:0 has bad value   (null)
      
      The warning is caused by the unwinder not realizing that it reached the
      end of the stack, due to an unusual prologue which gcc sometimes
      generates for aligned stacks.  The prologue is based on a gcc feature
      called the Dynamic Realign Argument Pointer (DRAP).  It's almost always
      enabled for aligned stacks when -maccumulate-outgoing-args isn't set.
      
      This issue is similar to the one fixed by the following commit:
      
        8023e0e2 ("x86/unwind: Adjust last frame check for aligned function stacks")
      
      ... but that fix was specific to x86-64.
      
      Make the fix more generic to cover x86-32 as well, and also ensure that
      the return address referred to by the frame pointer is a copy of the
      original return address.
      
      Fixes: acb4608a ("x86/unwind: Create stack frames for saved syscall registers")
      Reported-by: NPavel Machek <pavel@ucw.cz>
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/50d4924db716c264b14f1633037385ec80bf89d2.1489465609.git.jpoimboe@redhat.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      87a6b297
    • A
      mm, x86: Fix native_pud_clear build error · d434936e
      Arnd Bergmann 提交于
      We still get a build error in random configurations, after this has been
      modified a few times:
      
      In file included from include/linux/mm.h:68:0,
                       from include/linux/suspend.h:8,
                       from arch/x86/kernel/asm-offsets.c:12:
      arch/x86/include/asm/pgtable.h:66:26: error: redefinition of 'native_pud_clear'
       #define pud_clear(pud)   native_pud_clear(pud)
      
      My interpretation is that the build error comes from a typo in __PAGETABLE_PUD_FOLDED,
      so fix that typo now, and remove the incorrect #ifdef around the native_pud_clear
      definition.
      
      Fixes: 3e761a42 ("mm, x86: fix HIGHMEM64 && PARAVIRT build config for native_pud_clear()")
      Fixes: a00cc7d9 ("mm, x86: add support for PUD-sized transparent hugepages")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NDave Jiang <dave.jiang@intel.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Thomas Garnier <thgarnie@google.com>
      Link: http://lkml.kernel.org/r/20170314121330.182155-1-arnd@arndb.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      d434936e
  14. 14 3月, 2017 5 次提交
  15. 13 3月, 2017 1 次提交
  16. 12 3月, 2017 1 次提交
    • D
      x86/tlb: Fix tlb flushing when lguest clears PGE · 2c4ea6e2
      Daniel Borkmann 提交于
      Fengguang reported random corruptions from various locations on x86-32
      after commits d2852a22 ("arch: add ARCH_HAS_SET_MEMORY config") and
      9d876e79 ("bpf: fix unlocking of jited image when module ronx not set")
      that uses the former. While x86-32 doesn't have a JIT like x86_64, the
      bpf_prog_lock_ro() and bpf_prog_unlock_ro() got enabled due to
      ARCH_HAS_SET_MEMORY, whereas Fengguang's test kernel doesn't have module
      support built in and therefore never had the DEBUG_SET_MODULE_RONX setting
      enabled.
      
      After investigating the crashes further, it turned out that using
      set_memory_ro() and set_memory_rw() didn't have the desired effect, for
      example, setting the pages as read-only on x86-32 would still let
      probe_kernel_write() succeed without error. This behavior would manifest
      itself in situations where the vmalloc'ed buffer was accessed prior to
      set_memory_*() such as in case of bpf_prog_alloc(). In cases where it
      wasn't, the page attribute changes seemed to have taken effect, leading to
      the conclusion that a TLB invalidate didn't happen. Moreover, it turned out
      that this issue reproduced with qemu in "-cpu kvm64" mode, but not for
      "-cpu host". When the issue occurs, change_page_attr_set_clr() did trigger
      a TLB flush as expected via __flush_tlb_all() through cpa_flush_range(),
      though.
      
      There are 3 variants for issuing a TLB flush: invpcid_flush_all() (depends
      on CPU feature bits X86_FEATURE_INVPCID, X86_FEATURE_PGE), cr4 based flush
      (depends on X86_FEATURE_PGE), and cr3 based flush.  For "-cpu host" case in
      my setup, the flush used invpcid_flush_all() variant, whereas for "-cpu
      kvm64", the flush was cr4 based. Switching the kvm64 case to cr3 manually
      worked fine, and further investigating the cr4 one turned out that
      X86_CR4_PGE bit was not set in cr4 register, meaning the
      __native_flush_tlb_global_irq_disabled() wrote cr4 twice with the same
      value instead of clearing X86_CR4_PGE in the first write to trigger the
      flush.
      
      It turned out that X86_CR4_PGE was cleared from cr4 during init from
      lguest_arch_host_init() via adjust_pge(). The X86_FEATURE_PGE bit is also
      cleared from there due to concerns of using PGE in guest kernel that can
      lead to hard to trace bugs (see bff672e6 ("lguest: documentation V:
      Host") in init()). The CPU feature bits are cleared in dynamic
      boot_cpu_data, but they never propagated to __flush_tlb_all() as it uses
      static_cpu_has() instead of boot_cpu_has() for testing which variant of TLB
      flushing to use, meaning they still used the old setting of the host
      kernel.
      
      Clearing via setup_clear_cpu_cap(X86_FEATURE_PGE) so this would propagate
      to static_cpu_has() checks is too late at this point as sections have been
      patched already, so for now, it seems reasonable to switch back to
      boot_cpu_has(X86_FEATURE_PGE) as it was prior to commit c109bf95
      ("x86/cpufeature: Remove cpu_has_pge"). This lets the TLB flush trigger via
      cr3 as originally intended, properly makes the new page attributes visible
      and thus fixes the crashes seen by Fengguang.
      
      Fixes: c109bf95 ("x86/cpufeature: Remove cpu_has_pge")
      Reported-by: NFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Cc: bp@suse.de
      Cc: Kees Cook <keescook@chromium.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: netdev@vger.kernel.org
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: lkp@01.org
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernrl.org/r/20170301125426.l4nf65rx4wahohyl@wfg-t540p.sh.intel.com
      Link: http://lkml.kernel.org/r/25c41ad9eca164be4db9ad84f768965b7eb19d9e.1489191673.git.daniel@iogearbox.netSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      2c4ea6e2
  17. 11 3月, 2017 3 次提交
    • D
      x86/acpi: Restore the order of CPU IDs · 2b85b3d2
      Dou Liyang 提交于
      The following commits:
      
        f7c28833 ("x86/acpi: Enable acpi to register all possible cpus at
      boot time") and 8f54969d ("x86/acpi: Introduce persistent storage
      for cpuid <-> apicid mapping")
      
      ... registered all the possible CPUs at boot time via ACPI tables to
      make the mapping of cpuid <-> apicid fixed. Both enabled and disabled
      CPUs could have a logical CPU ID after boot time.
      
      But, ACPI tables are unreliable. the number amd order of Local APIC
      entries which depends on the firmware is often inconsistent with the
      physical devices. Even if they are consistent, The disabled CPUs which
      take up some logical CPU IDs will also make the order discontinuous.
      
      Revert the part of disabled CPUs registration, keep the allocation
      logic of logical CPU IDs and also keep some code location changes.
      Signed-off-by: NDou Liyang <douly.fnst@cn.fujitsu.com>
      Tested-by: NXiaolong Ye <xiaolong.ye@intel.com>
      Cc: rjw@rjwysocki.net
      Cc: linux-acpi@vger.kernel.org
      Cc: guzheng1@huawei.com
      Cc: izumi.taku@jp.fujitsu.com
      Cc: lenb@kernel.org
      Link: http://lkml.kernel.org/r/1488528147-2279-4-git-send-email-douly.fnst@cn.fujitsu.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      2b85b3d2
    • D
      Revert "x86/acpi: Set persistent cpuid <-> nodeid mapping when booting" · c962cff1
      Dou Liyang 提交于
      Revert: dc6db24d ("x86/acpi: Set persistent cpuid <-> nodeid mapping when booting")
      
      The mapping of "cpuid <-> nodeid" is established at boot time via ACPI
      tables to keep associations of workqueues and other node related items
      consistent across cpu hotplug.
      
      But, ACPI tables are unreliable and failures with that boot time mapping
      have been reported on machines where the ACPI table and the physical
      information which is retrieved at actual hotplug is inconsistent.
      
      Revert the mapping implementation so it can be replaced with a less error
      prone approach.
      Signed-off-by: NDou Liyang <douly.fnst@cn.fujitsu.com>
      Tested-by: NXiaolong Ye <xiaolong.ye@intel.com>
      Cc: rjw@rjwysocki.net
      Cc: linux-acpi@vger.kernel.org
      Cc: guzheng1@huawei.com
      Cc: izumi.taku@jp.fujitsu.com
      Cc: lenb@kernel.org
      Link: http://lkml.kernel.org/r/1488528147-2279-2-git-send-email-douly.fnst@cn.fujitsu.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      c962cff1
    • T
      kexec, x86/purgatory: Unbreak it and clean it up · 40c50c1f
      Thomas Gleixner 提交于
      The purgatory code defines global variables which are referenced via a
      symbol lookup in the kexec code (core and arch).
      
      A recent commit addressing sparse warnings made these static and thereby
      broke kexec_file.
      
      Why did this happen? Simply because the whole machinery is undocumented and
      lacks any form of forward declarations. The variable names are unspecific
      and lack a prefix, so adding forward declarations creates shadow variables
      in the core code. Aside of that the code relies on magic constants and
      duplicate struct definitions with no way to ensure that these things stay
      in sync. The section placement of the purgatory variables happened by
      chance and not by design.
      
      Unbreak kexec and cleanup the mess:
      
       - Add proper forward declarations and document the usage
       - Use common struct definition
       - Use the proper common defines instead of magic constants
       - Add a purgatory_ prefix to have a proper name space
       - Use ARRAY_SIZE() instead of a homebrewn reimplementation
       - Add proper sections to the purgatory variables [ From Mike ]
      
      Fixes: 72042a8c ("x86/purgatory: Make functions and variables static")
      Reported-by: NMike Galbraith <&lt;efault@gmx.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Nicholas Mc Guire <der.herr@hofr.at>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: "Tobin C. Harding" <me@tobin.cc>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1703101315140.3681@nanosSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      40c50c1f