1. 17 11月, 2017 2 次提交
    • H
      parisc: Add CPU topology support · bf7b4c1b
      Helge Deller 提交于
      Add topology support, including multi-core scheduler support on
      PA8800/PA8900 CPUs and enhanced output in /proc/cpuinfo, e.g.
      lscpu now reports on a single-socket, dual-core machine:
      
      Architecture:          parisc64
      CPU(s):                2
      On-line CPU(s) list:   0,1
      Thread(s) per core:    1
      Core(s) per socket:    2
      Socket(s):             1
      CPU family:            PA-RISC 2.0
      Model name:            PA8800 (Mako)
      Signed-off-by: NHelge Deller <deller@gmx.de>
      bf7b4c1b
    • J
      parisc: Fix validity check of pointer size argument in new CAS implementation · 05f016d2
      John David Anglin 提交于
      As noted by Christoph Biedl, passing a pointer size of 4 in the new CAS
      implementation causes a kernel crash.  The attached patch corrects the
      off by one error in the argument validity check.
      
      In reviewing the code, I noticed that we only perform word operations
      with the pointer size argument.  The subi instruction intentionally uses
      a word condition on 64-bit kernels.  Nullification was used instead of a
      cmpib instruction as the branch should never be taken.  The shlw
      pseudo-operation generates a depw,z instruction and it clears the target
      before doing a shift left word deposit.  Thus, we don't need to clip the
      upper 32 bits of this argument on 64-bit kernels.
      
      Tested with a gcc testsuite run with a 64-bit kernel.  The gcc atomic
      code in libgcc is the only direct user of the new CAS implementation
      that I am aware of.
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Cc: stable@vger.kernel.org # 3.13+
      Signed-off-by: NHelge Deller <deller@gmx.de>
      05f016d2
  2. 11 11月, 2017 1 次提交
  3. 10 11月, 2017 2 次提交
  4. 09 11月, 2017 2 次提交
    • J
      x86/mm: Unbreak modules that rely on external PAGE_KERNEL availability · 87df2617
      Jiri Kosina 提交于
      Commit 7744ccdb ("x86/mm: Add Secure Memory Encryption (SME)
      support") as a side-effect made PAGE_KERNEL all of a sudden unavailable
      to modules which can't make use of EXPORT_SYMBOL_GPL() symbols.
      
      This is because once SME is enabled, sme_me_mask (which is introduced as
      EXPORT_SYMBOL_GPL) makes its way to PAGE_KERNEL through _PAGE_ENC,
      causing imminent build failure for all the modules which make use of all
      the EXPORT-SYMBOL()-exported API (such as vmap(), __vmalloc(),
      remap_pfn_range(), ...).
      
      Exporting (as EXPORT_SYMBOL()) interfaces (and having done so for ages)
      that take pgprot_t argument, while making it impossible to -- all of a
      sudden -- pass PAGE_KERNEL to it, feels rather incosistent.
      
      Restore the original behavior and make it possible to pass PAGE_KERNEL
      to all its EXPORT_SYMBOL() consumers.
      
      [ This is all so not wonderful. We shouldn't need that "sme_me_mask"
        access at all in all those places that really don't care about that
        level of detail, and just want _PAGE_KERNEL or whatever.
      
        We have some similar issues with _PAGE_CACHE_WP and _PAGE_NOCACHE,
        both of which hide a "cachemode2protval()" call, and which also ends
        up using another EXPORT_SYMBOL(), but at least that only triggers for
        the much more rare cases.
      
        Maybe we could move these dynamic page table bits to be generated much
        deeper down in the VM layer, instead of hiding them in the macros that
        everybody uses.
      
        So this all would merit some cleanup. But not today.   - Linus ]
      
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Despised-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      87df2617
    • Y
      x86/idt: Remove X86_TRAP_BP initialization in idt_setup_traps() · d0cd64b0
      Yonghong Song 提交于
      Commit b70543a0("x86/idt: Move regular trap init to tables") moves
      regular trap init for each trap vector into a table based
      initialization. It introduced the initialization for vector X86_TRAP_BP
      which was not in the code which it replaced. This breaks uprobe
      functionality for x86_32; the probed program segfaults instead of handling
      the probe proper.
      
      The reason for this is that TRAP_BP is set up as system interrupt gate
      (DPL3) in the early IDT and then replaced by a regular interrupt gate
      (DPL0) in idt_setup_traps(). The DPL0 restriction causes the int3 trap
      to fail with a #GP resulting in a SIGSEGV of the probed program.
      
      On 64bit this does not cause a problem because the IDT entry is replaced
      with a system interrupt gate (DPL3) with interrupt stack afterwards.
      
      Remove X86_TRAP_BP from the def_idts table which is used in
      idt_setup_traps(). Remove a redundant entry for X86_TRAP_NMI in def_idts
      while at it. Tested on both x86_64 and x86_32.
      
      [ tglx: Amended changelog with a description of the root cause ]
      
      Fixes: b70543a0("x86/idt: Move regular trap init to tables")
      Reported-and-tested-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: a.p.zijlstra@chello.nl
      Cc: ast@fb.com
      Cc: oleg@redhat.com
      Cc: luto@kernel.org
      Cc: kernel-team@fb.com
      Link: https://lkml.kernel.org/r/20171108192845.552709-1-yhs@fb.com
      d0cd64b0
  5. 08 11月, 2017 6 次提交
    • O
      MIPS: AR7: Ensure that serial ports are properly set up · b084116f
      Oswald Buddenhagen 提交于
      Without UPF_FIXED_TYPE, the data from the PORT_AR7 uart_config entry is
      never copied, resulting in a dead port.
      
      Fixes: 154615d5 ("MIPS: AR7: Use correct UART port type")
      Signed-off-by: NOswald Buddenhagen <oswald.buddenhagen@gmx.de>
      [jonas.gorski: add Fixes tag]
      Signed-off-by: NJonas Gorski <jonas.gorski@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com>
      Cc: Nicolas Schichan <nschichan@freebox.fr>
      Cc: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
      Cc: linux-mips@linux-mips.org
      Cc: linux-serial@vger.kernel.org
      Cc: <stable@vger.kernel.org>
      Patchwork: https://patchwork.linux-mips.org/patch/17543/Signed-off-by: NJames Hogan <jhogan@kernel.org>
      b084116f
    • J
      MIPS: AR7: Defer registration of GPIO · e6b03ab6
      Jonas Gorski 提交于
      When called from prom init code, ar7_gpio_init() will fail as it will
      call gpiochip_add() which relies on a working kmalloc() to alloc
      the gpio_desc array and kmalloc is not useable yet at prom init time.
      
      Move ar7_gpio_init() to ar7_register_devices() (a device_initcall)
      where kmalloc works.
      
      Fixes: 14e85c0e ("gpio: remove gpio_descs global array")
      Signed-off-by: NJonas Gorski <jonas.gorski@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com>
      Cc: Nicolas Schichan <nschichan@freebox.fr>
      Cc: linux-mips@linux-mips.org
      Cc: linux-serial@vger.kernel.org
      Cc: <stable@vger.kernel.org> # 3.19+
      Patchwork: https://patchwork.linux-mips.org/patch/17542/Signed-off-by: NJames Hogan <jhogan@kernel.org>
      e6b03ab6
    • B
      x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context · a743bbee
      Borislav Petkov 提交于
      The warning below says it all:
      
        BUG: using __this_cpu_read() in preemptible [00000000] code: swapper/0/1
        caller is __this_cpu_preempt_check
        CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-rc8 #4
        Call Trace:
         dump_stack
         check_preemption_disabled
         ? do_early_param
         __this_cpu_preempt_check
         arch_perfmon_init
         op_nmi_init
         ? alloc_pci_root_info
         oprofile_arch_init
         oprofile_init
         do_one_initcall
         ...
      
      These accessors should not have been used in the first place: it is PPro so
      no mixed silicon revisions and thus it can simply use boot_cpu_data.
      Reported-by: NFengguang Wu <fengguang.wu@intel.com>
      Tested-by: NFengguang Wu <fengguang.wu@intel.com>
      Fix-creation-mandated-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Robert Richter <rric@kernel.org>
      Cc: x86@kernel.org
      Cc: stable@vger.kernel.org
      a743bbee
    • J
      x86/unwind: Disable KASAN checking in the ORC unwinder · 881125bf
      Josh Poimboeuf 提交于
      Fengguang reported a KASAN warning:
      
        Kprobe smoke test: started
        ==================================================================
        BUG: KASAN: stack-out-of-bounds in deref_stack_reg+0xb5/0x11a
        Read of size 8 at addr ffff8800001c7cd8 by task swapper/1
      
        CPU: 0 PID: 1 Comm: swapper Not tainted 4.14.0-rc8 #26
        Call Trace:
         <#DB>
         ...
         save_trace+0xd9/0x1d3
         mark_lock+0x5f7/0xdc3
         __lock_acquire+0x6b4/0x38ef
         lock_acquire+0x1a1/0x2aa
         _raw_spin_lock_irqsave+0x46/0x55
         kretprobe_table_lock+0x1a/0x42
         pre_handler_kretprobe+0x3f5/0x521
         kprobe_int3_handler+0x19c/0x25f
         do_int3+0x61/0x142
         int3+0x30/0x60
        [...]
      
      The ORC unwinder got confused by some kprobes changes, which isn't
      surprising since the runtime code no longer matches vmlinux and the
      stack was modified for kretprobes.
      
      Until we have a way for generated code to register changes with the
      unwinder, these types of warnings are inevitable.  So just disable KASAN
      checks for stack accesses in the ORC unwinder.
      Reported-by: NFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20171108021934.zbl6unh5hpugybc5@trebleSigned-off-by: NIngo Molnar <mingo@kernel.org>
      881125bf
    • P
      KVM: PPC: Book3S HV: Fix exclusion between HPT resizing and other HPT updates · 38c53af8
      Paul Mackerras 提交于
      Commit 5e985969 ("KVM: PPC: Book3S HV: Outline of KVM-HV HPT resizing
      implementation", 2016-12-20) added code that tries to exclude any use
      or update of the hashed page table (HPT) while the HPT resizing code
      is iterating through all the entries in the HPT.  It does this by
      taking the kvm->lock mutex, clearing the kvm->arch.hpte_setup_done
      flag and then sending an IPI to all CPUs in the host.  The idea is
      that any VCPU task that tries to enter the guest will see that the
      hpte_setup_done flag is clear and therefore call kvmppc_hv_setup_htab_rma,
      which also takes the kvm->lock mutex and will therefore block until
      we release kvm->lock.
      
      However, any VCPU that is already in the guest, or is handling a
      hypervisor page fault or hypercall, can re-enter the guest without
      rechecking the hpte_setup_done flag.  The IPI will cause a guest exit
      of any VCPUs that are currently in the guest, but does not prevent
      those VCPU tasks from immediately re-entering the guest.
      
      The result is that after resize_hpt_rehash_hpte() has made a HPTE
      absent, a hypervisor page fault can occur and make that HPTE present
      again.  This includes updating the rmap array for the guest real page,
      meaning that we now have a pointer in the rmap array which connects
      with pointers in the old rev array but not the new rev array.  In
      fact, if the HPT is being reduced in size, the pointer in the rmap
      array could point outside the bounds of the new rev array.  If that
      happens, we can get a host crash later on such as this one:
      
      [91652.628516] Unable to handle kernel paging request for data at address 0xd0000000157fb10c
      [91652.628668] Faulting instruction address: 0xc0000000000e2640
      [91652.628736] Oops: Kernel access of bad area, sig: 11 [#1]
      [91652.628789] LE SMP NR_CPUS=1024 NUMA PowerNV
      [91652.628847] Modules linked in: binfmt_misc vhost_net vhost tap xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables ses enclosure scsi_transport_sas i2c_opal ipmi_powernv ipmi_devintf i2c_core ipmi_msghandler powernv_op_panel nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc kvm_hv kvm_pr kvm scsi_dh_alua dm_service_time dm_multipath tg3 ptp pps_core [last unloaded: stap_552b612747aec2da355051e464fa72a1_14259]
      [91652.629566] CPU: 136 PID: 41315 Comm: CPU 21/KVM Tainted: G           O    4.14.0-1.rc4.dev.gitb27fc5c.el7.centos.ppc64le #1
      [91652.629684] task: c0000007a419e400 task.stack: c0000000028d8000
      [91652.629750] NIP:  c0000000000e2640 LR: d00000000c36e498 CTR: c0000000000e25f0
      [91652.629829] REGS: c0000000028db5d0 TRAP: 0300   Tainted: G           O     (4.14.0-1.rc4.dev.gitb27fc5c.el7.centos.ppc64le)
      [91652.629932] MSR:  900000010280b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]>  CR: 44022422  XER: 00000000
      [91652.630034] CFAR: d00000000c373f84 DAR: d0000000157fb10c DSISR: 40000000 SOFTE: 1
      [91652.630034] GPR00: d00000000c36e498 c0000000028db850 c000000001403900 c0000007b7960000
      [91652.630034] GPR04: d0000000117fb100 d000000007ab00d8 000000000033bb10 0000000000000000
      [91652.630034] GPR08: fffffffffffffe7f 801001810073bb10 d00000000e440000 d00000000c373f70
      [91652.630034] GPR12: c0000000000e25f0 c00000000fdb9400 f000000003b24680 0000000000000000
      [91652.630034] GPR16: 00000000000004fb 00007ff7081a0000 00000000000ec91a 000000000033bb10
      [91652.630034] GPR20: 0000000000010000 00000000001b1190 0000000000000001 0000000000010000
      [91652.630034] GPR24: c0000007b7ab8038 d0000000117fb100 0000000ec91a1190 c000001e6a000000
      [91652.630034] GPR28: 00000000033bb100 000000000073bb10 c0000007b7960000 d0000000157fb100
      [91652.630735] NIP [c0000000000e2640] kvmppc_add_revmap_chain+0x50/0x120
      [91652.630806] LR [d00000000c36e498] kvmppc_book3s_hv_page_fault+0xbb8/0xc40 [kvm_hv]
      [91652.630884] Call Trace:
      [91652.630913] [c0000000028db850] [c0000000028db8b0] 0xc0000000028db8b0 (unreliable)
      [91652.630996] [c0000000028db8b0] [d00000000c36e498] kvmppc_book3s_hv_page_fault+0xbb8/0xc40 [kvm_hv]
      [91652.631091] [c0000000028db9e0] [d00000000c36a078] kvmppc_vcpu_run_hv+0xdf8/0x1300 [kvm_hv]
      [91652.631179] [c0000000028dbb30] [d00000000c2248c4] kvmppc_vcpu_run+0x34/0x50 [kvm]
      [91652.631266] [c0000000028dbb50] [d00000000c220d54] kvm_arch_vcpu_ioctl_run+0x114/0x2a0 [kvm]
      [91652.631351] [c0000000028dbbd0] [d00000000c2139d8] kvm_vcpu_ioctl+0x598/0x7a0 [kvm]
      [91652.631433] [c0000000028dbd40] [c0000000003832e0] do_vfs_ioctl+0xd0/0x8c0
      [91652.631501] [c0000000028dbde0] [c000000000383ba4] SyS_ioctl+0xd4/0x130
      [91652.631569] [c0000000028dbe30] [c00000000000b8e0] system_call+0x58/0x6c
      [91652.631635] Instruction dump:
      [91652.631676] fba1ffe8 fbc1fff0 fbe1fff8 f8010010 f821ffa1 2fa70000 793d0020 e9432110
      [91652.631814] 7bbf26e4 7c7e1b78 7feafa14 409e0094 <807f000c> 786326e4 7c6a1a14 93a40008
      [91652.631959] ---[ end trace ac85ba6db72e5b2e ]---
      
      To fix this, we tighten up the way that the hpte_setup_done flag is
      checked to ensure that it does provide the guarantee that the resizing
      code needs.  In kvmppc_run_core(), we check the hpte_setup_done flag
      after disabling interrupts and refuse to enter the guest if it is
      clear (for a HPT guest).  The code that checks hpte_setup_done and
      calls kvmppc_hv_setup_htab_rma() is moved from kvmppc_vcpu_run_hv()
      to a point inside the main loop in kvmppc_run_vcpu(), ensuring that
      we don't just spin endlessly calling kvmppc_run_core() while
      hpte_setup_done is clear, but instead have a chance to block on the
      kvm->lock mutex.
      
      Finally we also check hpte_setup_done inside the region in
      kvmppc_book3s_hv_page_fault() where the HPTE is locked and we are about
      to update the HPTE, and bail out if it is clear.  If another CPU is
      inside kvm_vm_ioctl_resize_hpt_commit) and has cleared hpte_setup_done,
      then we know that either we are looking at a HPTE
      that resize_hpt_rehash_hpte() has not yet processed, which is OK,
      or else we will see hpte_setup_done clear and refuse to update it,
      because of the full barrier formed by the unlock of the HPTE in
      resize_hpt_rehash_hpte() combined with the locking of the HPTE
      in kvmppc_book3s_hv_page_fault().
      
      Fixes: 5e985969 ("KVM: PPC: Book3S HV: Outline of KVM-HV HPT resizing implementation")
      Cc: stable@vger.kernel.org # v4.10+
      Reported-by: NSatheesh Rajendran <satheera@in.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@ozlabs.org>
      38c53af8
    • J
      MIPS: BMIPS: Fix missing cbr address · ea4b3afe
      Jaedon Shin 提交于
      Fix NULL pointer access in BMIPS3300 RAC flush.
      
      Fixes: 738a3f79 ("MIPS: BMIPS: Add early CPU initialization code")
      Signed-off-by: NJaedon Shin <jaedon.shin@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Cc: Kevin Cernekee <cernekee@gmail.com>
      Cc: linux-mips@linux-mips.org
      Cc: <stable@vger.kernel.org> # 4.7+
      Patchwork: https://patchwork.linux-mips.org/patch/16423/Signed-off-by: NJames Hogan <jhogan@kernel.org>
      ea4b3afe
  6. 07 11月, 2017 1 次提交
  7. 06 11月, 2017 1 次提交
    • M
      ARM: 8720/1: ensure dump_instr() checks addr_limit · b9dd05c7
      Mark Rutland 提交于
      When CONFIG_DEBUG_USER is enabled, it's possible for a user to
      deliberately trigger dump_instr() with a chosen kernel address.
      
      Let's avoid problems resulting from this by using get_user() rather than
      __get_user(), ensuring that we don't erroneously access kernel memory.
      
      So that we can use the same code to dump user instructions and kernel
      instructions, the common dumping code is factored out to __dump_instr(),
      with the fs manipulated appropriately in dump_instr() around calls to
      this.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      b9dd05c7
  8. 05 11月, 2017 1 次提交
  9. 04 11月, 2017 3 次提交
    • A
      Revert "x86/mm: Stop calling leave_mm() in idle code" · 67535736
      Andy Lutomirski 提交于
      This reverts commit 43858b4f.
      
      The reason I removed the leave_mm() calls in question is because the
      heuristic wasn't needed after that patch.  With the original version
      of my PCID series, we never flushed a "lazy cpu" (i.e. a CPU running
      kernel thread) due a flush on the loaded mm.
      
      Unfortunately, that caused architectural issues, so now I've
      reinstated these flushes on non-PCID systems in:
      
          commit b956575b ("x86/mm: Flush more aggressively in lazy TLB mode").
      
      That, in turn, gives us a power management and occasionally
      performance regression as compared to old kernels: a process that
      goes into a deep idle state on a given CPU and gets its mm flushed
      due to activity on a different CPU will wake the idle CPU.
      
      Reinstate the old ugly heuristic: if a CPU goes into ACPI C3 or an
      intel_idle state that is likely to cause a TLB flush gets its mm
      switched to init_mm before going idle.
      
      FWIW, this heuristic is lousy.  Whether we should change CR3 before
      idle isn't a good hint except insofar as the performance hit is a bit
      lower if the TLB is getting flushed by the idle code anyway.  What we
      really want to know is whether we anticipate being idle long enough
      that the mm is likely to be flushed before we wake up.  This is more a
      matter of the expected latency than the idle state that gets chosen.
      This heuristic also completely fails on systems that don't know
      whether the TLB will be flushed (e.g. AMD systems?).  OTOH it may be a
      bit obsolete anyway -- PCID systems don't presently benefit from this
      heuristic at all.
      
      We also shouldn't do this callback from innermost bit of the idle code
      due to the RCU nastiness it causes.  All the information need is
      available before rcu_idle_enter() needs to happen.
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bpetkov@suse.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: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 43858b4f "x86/mm: Stop calling leave_mm() in idle code"
      Link: http://lkml.kernel.org/r/c513bbd4e653747213e05bc7062de000bf0202a5.1509793738.git.luto@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      67535736
    • C
      arch/tile: Implement ->set_state_oneshot_stopped() · 777a45b4
      Chris Metcalf 提交于
      set_state_oneshot_stopped() is called by the clkevt core, when the
      next event is required at an expiry time of 'KTIME_MAX'. This normally
      happens with NO_HZ_{IDLE|FULL} in both LOWRES/HIGHRES modes.
      
      This patch makes the clockevent device to stop on such an event, to
      avoid spurious interrupts, as explained by: commit 8fff52fd
      ("clockevents: Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED state").
      Signed-off-by: NChris Metcalf <cmetcalf@mellanox.com>
      777a45b4
    • P
      Update MIPS email addresses · fb615d61
      Paul Burton 提交于
      MIPS will soon not be a part of Imagination Technologies, and as such
      many @imgtec.com email addresses will no longer be valid. This patch
      updates the addresses for those who:
      
       - Have 10 or more patches in mainline authored using an @imgtec.com
         email address, or any patches dated within the past year.
      
       - Are still with Imagination but leaving as part of the MIPS business
         unit, as determined from an internal email address list.
      
       - Haven't already updated their email address (ie. JamesH) or expressed
         a desire to be excluded (ie. Maciej).
      
       - Acked v2 or earlier of this patch, which leaves Deng-Cheng, Matt &
         myself.
      
      New addresses are of the form firstname.lastname@mips.com, and all
      verified against an internal email address list.  An entry is added to
      .mailmap for each person such that get_maintainer.pl will report the new
      addresses rather than @imgtec.com addresses which will soon be dead.
      
      Instances of the affected addresses throughout the tree are then
      mechanically replaced with the new @mips.com address.
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@imgtec.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@mips.com>
      Acked-by: NDengcheng Zhu <dengcheng.zhu@mips.com>
      Cc: Matt Redfearn <matt.redfearn@imgtec.com>
      Cc: Matt Redfearn <matt.redfearn@mips.com>
      Acked-by: NMatt Redfearn <matt.redfearn@mips.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: trivial@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fb615d61
  10. 03 11月, 2017 9 次提交
    • R
      x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo · 941f5f0f
      Rafael J. Wysocki 提交于
      Commit 890da9cf (Revert "x86: do not use cpufreq_quick_get() for
      /proc/cpuinfo "cpu MHz"") is not sufficient to restore the previous
      behavior of "cpu MHz" in /proc/cpuinfo on x86 due to some changes
      made after the commit it has reverted.
      
      To address this, make the code in question use arch_freq_get_on_cpu()
      which also is used by cpufreq for reporting the current frequency of
      CPUs and since that function doesn't really depend on cpufreq in any
      way, drop the CONFIG_CPU_FREQ dependency for the object file
      containing it.
      
      Also refactor arch_freq_get_on_cpu() somewhat to avoid IPIs and
      return cached values right away if it is called very often over a
      short time (to prevent user space from triggering IPI storms through
      it).
      
      Fixes: 890da9cf (Revert "x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"")
      Cc: stable@kernel.org   # 4.13 - together with 890da9cfSigned-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      941f5f0f
    • A
      crypto: x86/sha1-mb - fix panic due to unaligned access · d041b557
      Andrey Ryabinin 提交于
      struct sha1_ctx_mgr allocated in sha1_mb_mod_init() via kzalloc()
      and later passed in sha1_mb_flusher_mgr_flush_avx2() function where
      instructions vmovdqa used to access the struct. vmovdqa requires
      16-bytes aligned argument, but nothing guarantees that struct
      sha1_ctx_mgr will have that alignment. Unaligned vmovdqa will
      generate GP fault.
      
      Fix this by replacing vmovdqa with vmovdqu which doesn't have alignment
      requirements.
      
      Fixes: 2249cbb5 ("crypto: sha-mb - SHA1 multibuffer submit and flush routines for AVX2")
      Signed-off-by: NAndrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      d041b557
    • A
      crypto: x86/sha256-mb - fix panic due to unaligned access · 5dfeaac1
      Andrey Ryabinin 提交于
      struct sha256_ctx_mgr allocated in sha256_mb_mod_init() via kzalloc()
      and later passed in sha256_mb_flusher_mgr_flush_avx2() function where
      instructions vmovdqa used to access the struct. vmovdqa requires
      16-bytes aligned argument, but nothing guarantees that struct
      sha256_ctx_mgr will have that alignment. Unaligned vmovdqa will
      generate GP fault.
      
      Fix this by replacing vmovdqa with vmovdqu which doesn't have alignment
      requirements.
      
      Fixes: a377c6b1 ("crypto: sha256-mb - submit/flush routines for AVX2")
      Reported-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: NAndrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: <stable@vger.kernel.org>
      Acked-by: Tim Chen
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      5dfeaac1
    • M
      powerpc/perf: Fix core-imc hotplug callback failure during imc initialization · 7ecb37f6
      Madhavan Srinivasan 提交于
      Call trace observed during boot:
      
        nest_capp0_imc performance monitor hardware support registered
        nest_capp1_imc performance monitor hardware support registered
        core_imc memory allocation for cpu 56 failed
        Unable to handle kernel paging request for data at address 0xffa400010
        Faulting instruction address: 0xc000000000bf3294
        0:mon> e
        cpu 0x0: Vector: 300 (Data Access) at [c000000ff38ff8d0]
            pc: c000000000bf3294: mutex_lock+0x34/0x90
            lr: c000000000bf3288: mutex_lock+0x28/0x90
            sp: c000000ff38ffb50
           msr: 9000000002009033
           dar: ffa400010
         dsisr: 80000
          current = 0xc000000ff383de00
          paca    = 0xc000000007ae0000	 softe: 0	 irq_happened: 0x01
            pid   = 13, comm = cpuhp/0
        Linux version 4.11.0-39.el7a.ppc64le (mockbuild@ppc-058.build.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC) ) #1 SMP Tue Oct 3 07:42:44 EDT 2017
        0:mon> t
        [c000000ff38ffb80] c0000000002ddfac perf_pmu_migrate_context+0xac/0x470
        [c000000ff38ffc40] c00000000011385c ppc_core_imc_cpu_offline+0x1ac/0x1e0
        [c000000ff38ffc90] c000000000125758 cpuhp_invoke_callback+0x198/0x5d0
        [c000000ff38ffd00] c00000000012782c cpuhp_thread_fun+0x8c/0x3d0
        [c000000ff38ffd60] c0000000001678d0 smpboot_thread_fn+0x290/0x2a0
        [c000000ff38ffdc0] c00000000015ee78 kthread+0x168/0x1b0
        [c000000ff38ffe30] c00000000000b368 ret_from_kernel_thread+0x5c/0x74
      
      While registering the cpuhoplug callbacks for core-imc, if we fails
      in the cpuhotplug online path for any random core (either because opal call to
      initialize the core-imc counters fails or because memory allocation fails for
      that core), ppc_core_imc_cpu_offline() will get invoked for other cpus who
      successfully returned from cpuhotplug online path.
      
      But in the ppc_core_imc_cpu_offline() path we are trying to migrate the event
      context, when core-imc counters are not even initialized. Thus creating the
      above stack dump.
      
      Add a check to see if core-imc counters are enabled or not in the cpuhotplug
      offline path before migrating the context to handle this failing scenario.
      
      Fixes: 885dcd70 ("powerpc/perf: Add nest IMC PMU support")
      Signed-off-by: NMadhavan Srinivasan <maddy@linux.vnet.ibm.com>
      Signed-off-by: NAnju T Sudhakar <anju@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      7ecb37f6
    • L
      Revert "x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"" · 890da9cf
      Linus Torvalds 提交于
      This reverts commit 51204e06.
      
      There wasn't really any good reason for it, and people are complaining
      (rightly) that it broke existing practice.
      
      Cc: Len Brown <len.brown@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      890da9cf
    • M
      arm64: ensure __dump_instr() checks addr_limit · 7a7003b1
      Mark Rutland 提交于
      It's possible for a user to deliberately trigger __dump_instr with a
      chosen kernel address.
      
      Let's avoid problems resulting from this by using get_user() rather than
      __get_user(), ensuring that we don't erroneously access kernel memory.
      
      Where we use __dump_instr() on kernel text, we already switch to
      KERNEL_DS, so this shouldn't adversely affect those cases.
      
      Fixes: 60ffc30d ("arm64: Exception handling")
      Cc: stable@vger.kernel.org
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      7a7003b1
    • J
      KVM: x86: Update APICv on APIC reset · 4191db26
      Jan H. Schönherr 提交于
      In kvm_apic_set_state() we update the hardware virtualized APIC after
      the full APIC state has been overwritten. Do the same, when the full
      APIC state has been reset in kvm_lapic_reset().
      
      This updates some hardware state that was previously forgotten, as
      far as I can tell. Also, this allows removing some APIC-related reset
      code from vmx_vcpu_reset().
      Signed-off-by: NJan H. Schönherr <jschoenh@amazon.de>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      4191db26
    • J
      KVM: VMX: Do not fully reset PI descriptor on vCPU reset · a4888486
      Jan H. Schönherr 提交于
      Parts of the posted interrupt descriptor configure host behavior,
      such as the notification vector and destination. Overwriting them
      with zero as done during vCPU reset breaks posted interrupts.
      KVM (re-)writes these fields on certain occasions and belatedly fixes
      the situation in many cases. However, if you have a guest configured
      with "idle=poll", for example, the fields might stay zero forever.
      
      Do not reset the full descriptor in vmx_vcpu_reset(). Instead,
      reset only the outstanding notifications and leave everything
      else untouched.
      Signed-off-by: NJan H. Schönherr <jschoenh@amazon.de>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      a4888486
    • J
      kvm: Return -ENODEV from update_persistent_clock · 00875520
      Jason Gunthorpe 提交于
      kvm does not support setting the RTC, so the correct result is -ENODEV.
      Returning -1 will cause sync_cmos_clock to keep trying to set the RTC
      every second.
      Signed-off-by: NJason Gunthorpe <jgg@ziepe.ca>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      00875520
  11. 02 11月, 2017 10 次提交
    • M
      MIPS: Update email address for Marcin Nowakowski · ca208b5f
      Marcin Nowakowski 提交于
      MIPS is no longer part of Imagination Technologies and my @imgtec.com
      address will soon stop working. Update any files containing my address
      as well as the .mailmap to point to my new @mips.com address.
      Signed-off-by: NMarcin Nowakowski <marcin.nowakowski@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/17579/Signed-off-by: NJames Hogan <jhogan@kernel.org>
      ca208b5f
    • G
      License cleanup: add SPDX license identifier to uapi header files with a license · e2be04c7
      Greg Kroah-Hartman 提交于
      Many user space API headers have licensing information, which is either
      incomplete, badly formatted or just a shorthand for referring to the
      license under which the file is supposed to be.  This makes it hard for
      compliance tools to determine the correct license.
      
      Update these files with an SPDX license identifier.  The identifier was
      chosen based on the license information in the file.
      
      GPL/LGPL licensed headers get the matching GPL/LGPL SPDX license
      identifier with the added 'WITH Linux-syscall-note' exception, which is
      the officially assigned exception identifier for the kernel syscall
      exception:
      
         NOTE! This copyright does *not* cover user programs that use kernel
         services by normal system calls - this is merely considered normal use
         of the kernel, and does *not* fall under the heading of "derived work".
      
      This exception makes it possible to include GPL headers into non GPL
      code, without confusing license compliance tools.
      
      Headers which have either explicit dual licensing or are just licensed
      under a non GPL license are updated with the corresponding SPDX
      identifier and the GPLv2 with syscall exception identifier.  The format
      is:
              ((GPL-2.0 WITH Linux-syscall-note) OR SPDX-ID-OF-OTHER-LICENSE)
      
      SPDX license identifiers are a legally binding shorthand, which can be
      used instead of the full boiler plate text.  The update does not remove
      existing license information as this has to be done on a case by case
      basis and the copyright holders might have to be consulted. This will
      happen in a separate step.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.  See the previous patch in this series for the
      methodology of how this patch was researched.
      Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e2be04c7
    • G
      License cleanup: add SPDX license identifier to uapi header files with no license · 6f52b16c
      Greg Kroah-Hartman 提交于
      Many user space API headers are missing licensing information, which
      makes it hard for compliance tools to determine the correct license.
      
      By default are files without license information under the default
      license of the kernel, which is GPLV2.  Marking them GPLV2 would exclude
      them from being included in non GPLV2 code, which is obviously not
      intended. The user space API headers fall under the syscall exception
      which is in the kernels COPYING file:
      
         NOTE! This copyright does *not* cover user programs that use kernel
         services by normal system calls - this is merely considered normal use
         of the kernel, and does *not* fall under the heading of "derived work".
      
      otherwise syscall usage would not be possible.
      
      Update the files which contain no license information with an SPDX
      license identifier.  The chosen identifier is 'GPL-2.0 WITH
      Linux-syscall-note' which is the officially assigned identifier for the
      Linux syscall exception.  SPDX license identifiers are a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.  See the previous patch in this series for the
      methodology of how this patch was researched.
      Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f52b16c
    • G
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman 提交于
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
    • R
      ARM: add debug ".edata_real" symbol · dad46753
      Russell King 提交于
      Add an additional symbol to the decompressor image, which will allow
      future debugging of non-bootable problems similar to the one encountered
      with the EFI stub.
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      dad46753
    • J
      MIPS: smp-cmp: Fix vpe_id build error · 7e7bf0ec
      James Hogan 提交于
      The smp-cmp build has been (further) broken since commit 856fbcee
      ("MIPS: Store core & VP IDs in GlobalNumber-style variable") in
      v4.14-rc1 like so:
      
      arch/mips/kernel/smp-cmp.c: In function ‘cmp_init_secondary’:
      arch/mips/kernel/smp-cmp.c:53:4: error: ‘struct cpuinfo_mips’ has no member named ‘vpe_id’
         c->vpe_id = (read_c0_tcbind() >> TCBIND_CURVPE_SHIFT) &
          ^
      
      Fix by replacing vpe_id with cpu_set_vpe_id().
      
      Fixes: 856fbcee ("MIPS: Store core & VP IDs in GlobalNumber-style variable")
      Signed-off-by: NJames Hogan <jhogan@kernel.org>
      Reviewed-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/17569/Signed-off-by: NJames Hogan <jhogan@kernel.org>
      7e7bf0ec
    • J
      MIPS: smp-cmp: Use right include for task_struct · f677b770
      Jason A. Donenfeld 提交于
      When task_struct was moved, this MIPS code was neglected. Evidently
      nobody is using it anymore. This fixes this build error:
      
      In file included from ./arch/mips/include/asm/thread_info.h:15:0,
                       from ./include/linux/thread_info.h:37,
                       from ./include/asm-generic/current.h:4,
                       from ./arch/mips/include/generated/asm/current.h:1,
                       from ./include/linux/sched.h:11,
                       from arch/mips/kernel/smp-cmp.c:22:
      arch/mips/kernel/smp-cmp.c: In function ‘cmp_boot_secondary’:
      ./arch/mips/include/asm/processor.h:384:41: error: implicit declaration
      of function ‘task_stack_page’ [-Werror=implicit-function-declaration]
       #define __KSTK_TOS(tsk) ((unsigned long)task_stack_page(tsk) + \
                                               ^
      arch/mips/kernel/smp-cmp.c:84:21: note: in expansion of macro ‘__KSTK_TOS’
        unsigned long sp = __KSTK_TOS(idle);
                           ^~~~~~~~~~
      
      Fixes: f3ac6067 ("sched/headers: Move task-stack related APIs from <linux/sched.h> to <linux/sched/task_stack.h>")
      Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
      Cc: <stable@vger.kernel.org> # 4.11+
      Patchwork: https://patchwork.linux-mips.org/patch/17522/Signed-off-by: NJames Hogan <jhogan@kernel.org>
      f677b770
    • M
      MIPS: CPS: Fix use of current_cpu_data in preemptible code · 8a46f71d
      Matt Redfearn 提交于
      Commit 1ec9dd80 ("MIPS: CPS: Detect CPUs in secondary clusters")
      added a check in cps_boot_secondary() that the secondary being booted is
      in the same cluster as the CPU running this code. This check is
      performed using current_cpu_data without disabling preemption. As such
      when CONFIG_PREEMPT=y, a BUG is triggered:
      
      [   57.991693] BUG: using smp_processor_id() in preemptible [00000000] code: hotplug/1749
      <snip>
      [   58.063077] Call Trace:
      [   58.065842] [<8040cdb4>] show_stack+0x84/0x114
      [   58.070830] [<80b11b38>] dump_stack+0xf8/0x140
      [   58.075796] [<8079b12c>] check_preemption_disabled+0xec/0x118
      [   58.082204] [<80415110>] cps_boot_secondary+0x84/0x44c
      [   58.087935] [<80413a14>] __cpu_up+0x34/0x98
      [   58.092624] [<80434240>] bringup_cpu+0x38/0x114
      [   58.097680] [<80434af0>] cpuhp_invoke_callback+0x168/0x8f0
      [   58.103801] [<804362d0>] _cpu_up+0x154/0x1c8
      [   58.108565] [<804363dc>] do_cpu_up+0x98/0xa8
      [   58.113333] [<808261f8>] device_online+0x84/0xc0
      [   58.118481] [<80826294>] online_store+0x60/0x98
      [   58.123562] [<8062261c>] kernfs_fop_write+0x158/0x1d4
      [   58.129196] [<805a2ae4>] __vfs_write+0x4c/0x168
      [   58.134247] [<805a2dc8>] vfs_write+0xe0/0x190
      [   58.139095] [<805a2fe0>] SyS_write+0x68/0xc4
      [   58.143854] [<80415d58>] syscall_common+0x34/0x58
      
      In reality we don't currently support running the kernel on CPUs not in
      cluster 0, so the answer to cpu_cluster(&current_cpu_data) will always
      be 0, even if this task being preempted and continues running on a
      different CPU. Regardless, the BUG should not be triggered, so fix this
      by switching to raw_current_cpu_data. When multicluster support lands
      upstream this check will need removing or changing anyway.
      
      Fixes: 1ec9dd80 ("MIPS: CPS: Detect CPUs in secondary clusters")
      Signed-off-by: NMatt Redfearn <matt.redfearn@mips.com>
      Reviewed-by: NPaul Burton <paul.burton@mips.com>
      CC: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/17563/Signed-off-by: NJames Hogan <jhogan@kernel.org>
      8a46f71d
    • B
      x86/mcelog: Get rid of RCU remnants · 7298f08e
      Borislav Petkov 提交于
      Jeremy reported a suspicious RCU usage warning in mcelog.
      
      /dev/mcelog is called in process context now as part of the notifier
      chain and doesn't need any of the fancy RCU and lockless accesses which
      it did in atomic context.
      
      Axe it all in favor of a simple mutex synchronization which cures the
      problem reported.
      
      Fixes: 5de97c9f ("x86/mce: Factor out and deprecate the /dev/mcelog driver")
      Reported-by: NJeremy Cline <jcline@redhat.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-and-tested-by: NTony Luck <tony.luck@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: linux-edac@vger.kernel.org
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20171101164754.xzzmskl4ngrqc5br@pd.tnic
      Link: https://bugzilla.redhat.com/show_bug.cgi?id=1498969
      7298f08e
    • L
      ARM: 8716/1: pass endianness info to sparse · ff0c6eec
      Luc Van Oostenryck 提交于
      ARM depends on the macros '__ARMEL__' & '__ARMEB__' being defined
      or not to correctly select or define endian-specific macros,
      structures or pieces of code.
      
      These macros are predefined by the compiler but sparse knows
      nothing about them and thus may pre-process files differently
      from what gcc would.
      
      Fix this by passing '-D__ARMEL__' or '-D__ARMEB__' to sparse,
      depending on the endianness of the kernel, like defined by GCC.
      
      Note: In most case it won't change anything since most ARMs use
            little-endian (but an allyesconfig would use big-endian!).
      
      To: Russell King <linux@armlinux.org.uk>
      
      Cc: linux-arm-kernel@lists.infradead.org
      Signed-off-by: NLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      ff0c6eec
  12. 01 11月, 2017 2 次提交
    • V
      x86/mm: fix use-after-free of vma during userfaultfd fault · cb0631fd
      Vlastimil Babka 提交于
      Syzkaller with KASAN has reported a use-after-free of vma->vm_flags in
      __do_page_fault() with the following reproducer:
      
        mmap(&(0x7f0000000000/0xfff000)=nil, 0xfff000, 0x3, 0x32, 0xffffffffffffffff, 0x0)
        mmap(&(0x7f0000011000/0x3000)=nil, 0x3000, 0x1, 0x32, 0xffffffffffffffff, 0x0)
        r0 = userfaultfd(0x0)
        ioctl$UFFDIO_API(r0, 0xc018aa3f, &(0x7f0000002000-0x18)={0xaa, 0x0, 0x0})
        ioctl$UFFDIO_REGISTER(r0, 0xc020aa00, &(0x7f0000019000)={{&(0x7f0000012000/0x2000)=nil, 0x2000}, 0x1, 0x0})
        r1 = gettid()
        syz_open_dev$evdev(&(0x7f0000013000-0x12)="2f6465762f696e7075742f6576656e742300", 0x0, 0x0)
        tkill(r1, 0x7)
      
      The vma should be pinned by mmap_sem, but handle_userfault() might (in a
      return to userspace scenario) release it and then acquire again, so when
      we return to __do_page_fault() (with other result than VM_FAULT_RETRY),
      the vma might be gone.
      
      Specifically, per Andrea the scenario is
       "A return to userland to repeat the page fault later with a
        VM_FAULT_NOPAGE retval (potentially after handling any pending signal
        during the return to userland). The return to userland is identified
        whenever FAULT_FLAG_USER|FAULT_FLAG_KILLABLE are both set in
        vmf->flags"
      
      However, since commit a3c4fb7c ("x86/mm: Fix fault error path using
      unsafe vma pointer") there is a vma_pkey() read of vma->vm_flags after
      that point, which can thus become use-after-free.  Fix this by moving
      the read before calling handle_mm_fault().
      Reported-by: Nsyzbot <bot+6a5269ce759a7bb12754ed9622076dc93f65a1f6@syzkaller.appspotmail.com>
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Suggested-by: NKirill A. Shutemov <kirill@shutemov.name>
      Fixes: 3c4fb7c9c2e ("x86/mm: Fix fault error path using unsafe vma pointer")
      Reviewed-by: NAndrea Arcangeli <aarcange@redhat.com>
      Signed-off-by: NVlastimil Babka <vbabka@suse.cz>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cb0631fd
    • N
      powerpc/kprobes: Dereference function pointers only if the address does not belong to kernel text · e6c4dcb3
      Naveen N. Rao 提交于
      This makes the changes introduced in commit 83e840c7
      ("powerpc64/elfv1: Only dereference function descriptor for non-text
      symbols") to be specific to the kprobe subsystem.
      
      We previously changed ppc_function_entry() to always check the provided
      address to confirm if it needed to be dereferenced. This is actually
      only an issue for kprobe blacklisted asm labels (through use of
      _ASM_NOKPROBE_SYMBOL) and can cause other issues with ftrace. Also, the
      additional checks are not really necessary for our other uses.
      
      As such, move this check to the kprobes subsystem.
      
      Fixes: 83e840c7 ("powerpc64/elfv1: Only dereference function descriptor for non-text symbols")
      Cc: stable@vger.kernel.org # v4.13+
      Signed-off-by: NNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      e6c4dcb3
反馈
建议
客服 返回
顶部