1. 24 Jul, 2019 2 commits
  2. 21 Jul, 2019 11 commits
  3. 12 Jul, 2019 1 commit
  4. 11 Jul, 2019 1 commit
  5. 10 Jul, 2019 8 commits
    • Dmitry Korotin's avatar
      MIPS: Add missing EHB in mtc0 -> mfc0 sequence. · 377bea40
      Dmitry Korotin authored
      commit 0b24cae4d535045f4c9e177aa228d4e97bad212c upstream.
      
      Add a missing EHB (Execution Hazard Barrier) in mtc0 -> mfc0 sequence.
      Without this execution hazard barrier it's possible for the value read
      back from the KScratch register to be the value from before the mtc0.
      
      Reproducible on P5600 & P6600.
      
      The hazard is documented in the MIPS Architecture Reference Manual Vol.
      III: MIPS32/microMIPS32 Privileged Resource Architecture (MD00088), rev
      6.03 table 8.1 which includes:
      
         Producer | Consumer | Hazard
        ----------|----------|----------------------------
         mtc0     | mfc0     | any coprocessor 0 register
      Signed-off-by: default avatarDmitry Korotin <dkorotin@wavecomp.com>
      [paul.burton@mips.com:
        - Commit message tweaks.
        - Add Fixes tags.
        - Mark for stable back to v3.15 where P5600 support was introduced.]
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Fixes: 3d8bfdd0 ("MIPS: Use C0_KScratch (if present) to hold PGD pointer.")
      Fixes: 829dcc0a ("MIPS: Add MIPS P5600 probe support")
      Cc: linux-mips@vger.kernel.org
      Cc: stable@vger.kernel.org # v3.15+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      377bea40
    • Hauke Mehrtens's avatar
      MIPS: Fix bounds check virt_addr_valid · 7e9c43e0
      Hauke Mehrtens authored
      commit d6ed083f5cc621e15c15b56c3b585fd524dbcb0f upstream.
      
      The bounds check used the uninitialized variable vaddr, it should use
      the given parameter kaddr instead. When using the uninitialized value
      the compiler assumed it to be 0 and optimized this function to just
      return 0 in all cases.
      
      This should make the function check the range of the given address and
      only do the page map check in case it is in the expected range of
      virtual addresses.
      
      Fixes: 074a1e1167af ("MIPS: Bounds check virt_addr_valid")
      Cc: stable@vger.kernel.org # v4.12+
      Cc: Paul Burton <paul.burton@mips.com>
      Signed-off-by: default avatarHauke Mehrtens <hauke@hauke-m.de>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: ralf@linux-mips.org
      Cc: jhogan@kernel.org
      Cc: f4bug@amsat.org
      Cc: linux-mips@vger.kernel.org
      Cc: ysu@wavecomp.com
      Cc: jcristau@debian.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7e9c43e0
    • Wanpeng Li's avatar
      KVM: LAPIC: Fix pending interrupt in IRR blocked by software disable LAPIC · 3fd88195
      Wanpeng Li authored
      commit bb34e690e9340bc155ebed5a3d75fc63ff69e082 upstream.
      
      Thomas reported that:
      
       | Background:
       |
       |    In preparation of supporting IPI shorthands I changed the CPU offline
       |    code to software disable the local APIC instead of just masking it.
       |    That's done by clearing the APIC_SPIV_APIC_ENABLED bit in the APIC_SPIV
       |    register.
       |
       | Failure:
       |
       |    When the CPU comes back online the startup code triggers occasionally
       |    the warning in apic_pending_intr_clear(). That complains that the IRRs
       |    are not empty.
       |
       |    The offending vector is the local APIC timer vector who's IRR bit is set
       |    and stays set.
       |
       | It took me quite some time to reproduce the issue locally, but now I can
       | see what happens.
       |
       | It requires apicv_enabled=0, i.e. full apic emulation. With apicv_enabled=1
       | (and hardware support) it behaves correctly.
       |
       | Here is the series of events:
       |
       |     Guest CPU
       |
       |     goes down
       |
       |       native_cpu_disable()
       |
       | 			apic_soft_disable();
       |
       |     play_dead()
       |
       |     ....
       |
       |     startup()
       |
       |       if (apic_enabled())
       |         apic_pending_intr_clear()	<- Not taken
       |
       |      enable APIC
       |
       |         apic_pending_intr_clear()	<- Triggers warning because IRR is stale
       |
       | When this happens then the deadline timer or the regular APIC timer -
       | happens with both, has fired shortly before the APIC is disabled, but the
       | interrupt was not serviced because the guest CPU was in an interrupt
       | disabled region at that point.
       |
       | The state of the timer vector ISR/IRR bits:
       |
       |     	     	       	        ISR     IRR
       | before apic_soft_disable()    0	      1
       | after apic_soft_disable()     0	      1
       |
       | On startup		      		 0	      1
       |
       | Now one would assume that the IRR is cleared after the INIT reset, but this
       | happens only on CPU0.
       |
       | Why?
       |
       | Because our CPU0 hotplug is just for testing to make sure nothing breaks
       | and goes through an NMI wakeup vehicle because INIT would send it through
       | the boots-trap code which is not really working if that CPU was not
       | physically unplugged.
       |
       | Now looking at a real world APIC the situation in that case is:
       |
       |     	     	       	      	ISR     IRR
       | before apic_soft_disable()    0	      1
       | after apic_soft_disable()     0	      1
       |
       | On startup		      		 0	      0
       |
       | Why?
       |
       | Once the dying CPU reenables interrupts the pending interrupt gets
       | delivered as a spurious interupt and then the state is clear.
       |
       | While that CPU0 hotplug test case is surely an esoteric issue, the APIC
       | emulation is still wrong, Even if the play_dead() code would not enable
       | interrupts then the pending IRR bit would turn into an ISR .. interrupt
       | when the APIC is reenabled on startup.
      
      From SDM 10.4.7.2 Local APIC State After It Has Been Software Disabled
      * Pending interrupts in the IRR and ISR registers are held and require
        masking or handling by the CPU.
      
      In Thomas's testing, hardware cpu will not respect soft disable LAPIC
      when IRR has already been set or APICv posted-interrupt is in flight,
      so we can skip soft disable APIC checking when clearing IRR and set ISR,
      continue to respect soft disable APIC when attempting to set IRR.
      Reported-by: default avatarRong Chen <rong.a.chen@intel.com>
      Reported-by: default avatarFeng Tang <feng.tang@intel.com>
      Reported-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Rong Chen <rong.a.chen@intel.com>
      Cc: Feng Tang <feng.tang@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarWanpeng Li <wanpengli@tencent.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3fd88195
    • Paolo Bonzini's avatar
      KVM: x86: degrade WARN to pr_warn_ratelimited · 8b90c980
      Paolo Bonzini authored
      commit 3f16a5c318392cbb5a0c7a3d19dff8c8ef3c38ee upstream.
      
      This warning can be triggered easily by userspace, so it should certainly not
      cause a panic if panic_on_warn is set.
      
      Reported-by: syzbot+c03f30b4f4c46bdf8575@syzkaller.appspotmail.com
      Suggested-by: default avatarAlexander Potapenko <glider@google.com>
      Acked-by: default avatarAlexander Potapenko <glider@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8b90c980
    • Vineet Gupta's avatar
      ARC: handle gcc generated __builtin_trap for older compiler · 3b851f87
      Vineet Gupta authored
      commit af1be2e2 upstream.
      
      ARC gcc prior to GNU 2018.03 release didn't have a target specific
      __builtin_trap() implementation, generating default abort() call.
      
      Implement the abort() call - emulating what newer gcc does for the same,
      as suggested by Arnd.
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3b851f87
    • Petr Mladek's avatar
      ftrace/x86: Remove possible deadlock between register_kprobe() and ftrace_run_update_code() · 0c0b5477
      Petr Mladek authored
      commit d5b844a2cf507fc7642c9ae80a9d585db3065c28 upstream.
      
      The commit 9f255b632bf12c4dd7 ("module: Fix livepatch/ftrace module text
      permissions race") causes a possible deadlock between register_kprobe()
      and ftrace_run_update_code() when ftrace is using stop_machine().
      
      The existing dependency chain (in reverse order) is:
      
      -> #1 (text_mutex){+.+.}:
             validate_chain.isra.21+0xb32/0xd70
             __lock_acquire+0x4b8/0x928
             lock_acquire+0x102/0x230
             __mutex_lock+0x88/0x908
             mutex_lock_nested+0x32/0x40
             register_kprobe+0x254/0x658
             init_kprobes+0x11a/0x168
             do_one_initcall+0x70/0x318
             kernel_init_freeable+0x456/0x508
             kernel_init+0x22/0x150
             ret_from_fork+0x30/0x34
             kernel_thread_starter+0x0/0xc
      
      -> #0 (cpu_hotplug_lock.rw_sem){++++}:
             check_prev_add+0x90c/0xde0
             validate_chain.isra.21+0xb32/0xd70
             __lock_acquire+0x4b8/0x928
             lock_acquire+0x102/0x230
             cpus_read_lock+0x62/0xd0
             stop_machine+0x2e/0x60
             arch_ftrace_update_code+0x2e/0x40
             ftrace_run_update_code+0x40/0xa0
             ftrace_startup+0xb2/0x168
             register_ftrace_function+0x64/0x88
             klp_patch_object+0x1a2/0x290
             klp_enable_patch+0x554/0x980
             do_one_initcall+0x70/0x318
             do_init_module+0x6e/0x250
             load_module+0x1782/0x1990
             __s390x_sys_finit_module+0xaa/0xf0
             system_call+0xd8/0x2d0
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(text_mutex);
                                     lock(cpu_hotplug_lock.rw_sem);
                                     lock(text_mutex);
        lock(cpu_hotplug_lock.rw_sem);
      
      It is similar problem that has been solved by the commit 2d1e38f5
      ("kprobes: Cure hotplug lock ordering issues"). Many locks are involved.
      To be on the safe side, text_mutex must become a low level lock taken
      after cpu_hotplug_lock.rw_sem.
      
      This can't be achieved easily with the current ftrace design.
      For example, arm calls set_all_modules_text_rw() already in
      ftrace_arch_code_modify_prepare(), see arch/arm/kernel/ftrace.c.
      This functions is called:
      
        + outside stop_machine() from ftrace_run_update_code()
        + without stop_machine() from ftrace_module_enable()
      
      Fortunately, the problematic fix is needed only on x86_64. It is
      the only architecture that calls set_all_modules_text_rw()
      in ftrace path and supports livepatching at the same time.
      
      Therefore it is enough to move text_mutex handling from the generic
      kernel/trace/ftrace.c into arch/x86/kernel/ftrace.c:
      
         ftrace_arch_code_modify_prepare()
         ftrace_arch_code_modify_post_process()
      
      This patch basically reverts the ftrace part of the problematic
      commit 9f255b632bf12c4dd7 ("module: Fix livepatch/ftrace module
      text permissions race"). And provides x86_64 specific-fix.
      
      Some refactoring of the ftrace code will be needed when livepatching
      is implemented for arm or nds32. These architectures call
      set_all_modules_text_rw() and use stop_machine() at the same time.
      
      Link: http://lkml.kernel.org/r/20190627081334.12793-1-pmladek@suse.com
      
      Fixes: 9f255b632bf12c4dd7 ("module: Fix livepatch/ftrace module text permissions race")
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reported-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Reviewed-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Reviewed-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      [
        As reviewed by Miroslav Benes <mbenes@suse.cz>, removed return value of
        ftrace_run_update_code() as it is a void function.
      ]
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0c0b5477
    • Ard Biesheuvel's avatar
      arm64: kaslr: keep modules inside module region when KASAN is enabled · 3fd5ca35
      Ard Biesheuvel authored
      commit 6f496a555d93db7a11d4860b9220d904822f586a upstream.
      
      When KASLR and KASAN are both enabled, we keep the modules where they
      are, and randomize the placement of the kernel so it is within 2 GB
      of the module region. The reason for this is that putting modules in
      the vmalloc region (like we normally do when KASLR is enabled) is not
      possible in this case, given that the entire vmalloc region is already
      backed by KASAN zero shadow pages, and so allocating dedicated KASAN
      shadow space as required by loaded modules is not possible.
      
      The default module allocation window is set to [_etext - 128MB, _etext]
      in kaslr.c, which is appropriate for KASLR kernels booted without a
      seed or with 'nokaslr' on the command line. However, as it turns out,
      it is not quite correct for the KASAN case, since it still intersects
      the vmalloc region at the top, where attempts to allocate shadow pages
      will collide with the KASAN zero shadow pages, causing a WARN() and all
      kinds of other trouble. So cap the top end to MODULES_END explicitly
      when running with KASAN.
      
      Cc: <stable@vger.kernel.org> # 4.9+
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Tested-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3fd5ca35
    • Paul Burton's avatar
      MIPS: netlogic: xlr: Remove erroneous check in nlm_fmn_send() · dbcbf7dd
      Paul Burton authored
      [ Upstream commit 02eec6c9 ]
      
      In nlm_fmn_send() we have a loop which attempts to send a message
      multiple times in order to handle the transient failure condition of a
      lack of available credit. When examining the status register to detect
      the failure we check for a condition that can never be true, which falls
      foul of gcc 8's -Wtautological-compare:
      
        In file included from arch/mips/netlogic/common/irq.c:65:
        ./arch/mips/include/asm/netlogic/xlr/fmn.h: In function 'nlm_fmn_send':
        ./arch/mips/include/asm/netlogic/xlr/fmn.h:304:22: error: bitwise
          comparison always evaluates to false [-Werror=tautological-compare]
           if ((status & 0x2) == 1)
                              ^~
      
      If the path taken if this condition were true all we do is print a
      message to the kernel console. Since failures seem somewhat expected
      here (making the console message questionable anyway) and the condition
      has clearly never evaluated true we simply remove it, rather than
      attempting to fix it to check status correctly.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20174/
      Cc: Ganesan Ramalingam <ganesanr@broadcom.com>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Jayachandran C <jnair@caviumnetworks.com>
      Cc: John Crispin <john@phrozen.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      dbcbf7dd
  6. 03 Jul, 2019 7 commits
  7. 25 Jun, 2019 10 commits