1. 11 Jan, 2019 5 commits
    • David Hildenbrand's avatar
      s390/smp: Fix calling smp_call_ipl_cpu() from ipl CPU · 60f1bf29
      David Hildenbrand authored
      When calling smp_call_ipl_cpu() from the IPL CPU, we will try to read
      from pcpu_devices->lowcore. However, due to prefixing, that will result
      in reading from absolute address 0 on that CPU. We have to go via the
      actual lowcore instead.
      
      This means that right now, we will read lc->nodat_stack == 0 and
      therfore work on a very wrong stack.
      
      This BUG essentially broke rebooting under QEMU TCG (which will report
      a low address protection exception). And checking under KVM, it is
      also broken under KVM. With 1 VCPU it can be easily triggered.
      
      :/# echo 1 > /proc/sys/kernel/sysrq
      :/# echo b > /proc/sysrq-trigger
      [   28.476745] sysrq: SysRq : Resetting
      [   28.476793] Kernel stack overflow.
      [   28.476817] CPU: 0 PID: 424 Comm: sh Not tainted 5.0.0-rc1+ #13
      [   28.476820] Hardware name: IBM 2964 NE1 716 (KVM/Linux)
      [   28.476826] Krnl PSW : 0400c00180000000 0000000000115c0c (pcpu_delegate+0x12c/0x140)
      [   28.476861]            R:0 T:1 IO:0 EX:0 Key:0 M:0 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
      [   28.476863] Krnl GPRS: ffffffffffffffff 0000000000000000 000000000010dff8 0000000000000000
      [   28.476864]            0000000000000000 0000000000000000 0000000000ab7090 000003e0006efbf0
      [   28.476864]            000000000010dff8 0000000000000000 0000000000000000 0000000000000000
      [   28.476865]            000000007fffc000 0000000000730408 000003e0006efc58 0000000000000000
      [   28.476887] Krnl Code: 0000000000115bfe: 4170f000            la      %r7,0(%r15)
      [   28.476887]            0000000000115c02: 41f0a000            la      %r15,0(%r10)
      [   28.476887]           #0000000000115c06: e370f0980024        stg     %r7,152(%r15)
      [   28.476887]           >0000000000115c0c: c0e5fffff86e        brasl   %r14,114ce8
      [   28.476887]            0000000000115c12: 41f07000            la      %r15,0(%r7)
      [   28.476887]            0000000000115c16: a7f4ffa8            brc     15,115b66
      [   28.476887]            0000000000115c1a: 0707                bcr     0,%r7
      [   28.476887]            0000000000115c1c: 0707                bcr     0,%r7
      [   28.476901] Call Trace:
      [   28.476902] Last Breaking-Event-Address:
      [   28.476920]  [<0000000000a01c4a>] arch_call_rest_init+0x22/0x80
      [   28.476927] Kernel panic - not syncing: Corrupt kernel stack, can't continue.
      [   28.476930] CPU: 0 PID: 424 Comm: sh Not tainted 5.0.0-rc1+ #13
      [   28.476932] Hardware name: IBM 2964 NE1 716 (KVM/Linux)
      [   28.476932] Call Trace:
      
      Fixes: 2f859d0d ("s390/smp: reduce size of struct pcpu")
      Cc: stable@vger.kernel.org # 4.0+
      Reported-by: default avatarCornelia Huck <cohuck@redhat.com>
      Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      60f1bf29
    • Vasily Gorbik's avatar
      s390/vdso: correct vdso mapping for compat tasks · 190f056f
      Vasily Gorbik authored
      While "s390/vdso: avoid 64-bit vdso mapping for compat tasks" fixed
      64-bit vdso mapping for compat tasks under gdb it introduced another
      problem. "compat_mm" flag is not inherited during fork and when
      31-bit process forks a child (but does not perform exec) it ends up
      with 64-bit vdso. To address that, init_new_context (which is called
      during fork and exec) now initialize compat_mm based on thread TIF_31BIT
      flag. Later compat_mm is adjusted in arch_setup_additional_pages, which
      is called during exec.
      
      Fixes: d1befa65 ("s390/vdso: avoid 64-bit vdso mapping for compat tasks")
      Reported-by: default avatarStefan Liebler <stli@linux.ibm.com>
      Reviewed-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Cc: <stable@vger.kernel.org> # v4.20+
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      190f056f
    • Gerald Schaefer's avatar
      s390/smp: fix CPU hotplug deadlock with CPU rescan · b7cb707c
      Gerald Schaefer authored
      smp_rescan_cpus() is called without the device_hotplug_lock, which can lead
      to a dedlock when a new CPU is found and immediately set online by a udev
      rule.
      
      This was observed on an older kernel version, where the cpu_hotplug_begin()
      loop was still present, and it resulted in hanging chcpu and systemd-udev
      processes. This specific deadlock will not show on current kernels. However,
      there may be other possible deadlocks, and since smp_rescan_cpus() can still
      trigger a CPU hotplug operation, the device_hotplug_lock should be held.
      
      For reference, this was the deadlock with the old cpu_hotplug_begin() loop:
      
              chcpu (rescan)                       systemd-udevd
      
       echo 1 > /sys/../rescan
       -> smp_rescan_cpus()
       -> (*) get_online_cpus()
          (increases refcount)
       -> smp_add_present_cpu()
          (new CPU found)
       -> register_cpu()
       -> device_add()
       -> udev "add" event triggered -----------> udev rule sets CPU online
                                               -> echo 1 > /sys/.../online
                                               -> lock_device_hotplug_sysfs()
                                                  (this is missing in rescan path)
                                               -> device_online()
                                               -> (**) device_lock(new CPU dev)
                                               -> cpu_up()
                                               -> cpu_hotplug_begin()
                                                  (loops until refcount == 0)
                                                  -> deadlock with (*)
       -> bus_probe_device()
       -> device_attach()
       -> device_lock(new CPU dev)
          -> deadlock with (**)
      
      Fix this by taking the device_hotplug_lock in the CPU rescan path.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarGerald Schaefer <gerald.schaefer@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      b7cb707c
    • Martin Schwidefsky's avatar
      s390/mm: always force a load of the primary ASCE on context switch · a3866208
      Martin Schwidefsky authored
      The ASCE of an mm_struct can be modified after a task has been created,
      e.g. via crst_table_downgrade for a compat process. The active_mm logic
      to avoid the switch_mm call if the next task is a kernel thread can
      lead to a situation where switch_mm is called where 'prev == next' is
      true but 'prev->context.asce == next->context.asce' is not.
      
      This can lead to a situation where a CPU uses the outdated ASCE to run
      a task. The result can be a crash, endless loops and really subtle
      problem due to TLBs being created with an invalid ASCE.
      
      Cc: stable@kernel.org # v3.15+
      Fixes: 53e857f3 ("s390/mm,tlb: race of lazy TLB flush vs. recreation")
      Reported-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Reviewed-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      a3866208
    • Christian Borntraeger's avatar
      s390/early: improve machine detection · 03aa047e
      Christian Borntraeger authored
      Right now the early machine detection code check stsi 3.2.2 for "KVM"
      and set MACHINE_IS_VM if this is different. As the console detection
      uses diagnose 8 if MACHINE_IS_VM returns true this will crash Linux
      early for any non z/VM system that sets a different value than KVM.
      So instead of assuming z/VM, do not set any of MACHINE_IS_LPAR,
      MACHINE_IS_VM, or MACHINE_IS_KVM.
      
      CC: stable@vger.kernel.org
      Reviewed-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      03aa047e
  2. 10 Jan, 2019 5 commits
  3. 09 Jan, 2019 19 commits
  4. 08 Jan, 2019 10 commits
    • Amadeusz Sławiński's avatar
      ALSA: usb-audio: fix CM6206 register definitions · f5c9571e
      Amadeusz Sławiński authored
      fix typo after a recent commit causing headphones to have no sound
      
      Fixes: ad43d528 (ALSA: usb-audio: Define registers for CM6206)
      Signed-off-by: default avatarAmadeusz Sławiński <amade@asmblr.net>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f5c9571e
    • David Herrmann's avatar
      fork: record start_time late · 7b558513
      David Herrmann authored
      This changes the fork(2) syscall to record the process start_time after
      initializing the basic task structure but still before making the new
      process visible to user-space.
      
      Technically, we could record the start_time anytime during fork(2).  But
      this might lead to scenarios where a start_time is recorded long before
      a process becomes visible to user-space.  For instance, with
      userfaultfd(2) and TLS, user-space can delay the execution of fork(2)
      for an indefinite amount of time (and will, if this causes network
      access, or similar).
      
      By recording the start_time late, it much closer reflects the point in
      time where the process becomes live and can be observed by other
      processes.
      
      Lastly, this makes it much harder for user-space to predict and control
      the start_time they get assigned.  Previously, user-space could fork a
      process and stall it in copy_thread_tls() before its pid is allocated,
      but after its start_time is recorded.  This can be misused to later-on
      cycle through PIDs and resume the stalled fork(2) yielding a process
      that has the same pid and start_time as a process that existed before.
      This can be used to circumvent security systems that identify processes
      by their pid+start_time combination.
      
      Even though user-space was always aware that start_time recording is
      flaky (but several projects are known to still rely on start_time-based
      identification), changing the start_time to be recorded late will help
      mitigate existing attacks and make it much harder for user-space to
      control the start_time a process gets assigned.
      Reported-by: default avatarJann Horn <jannh@google.com>
      Signed-off-by: default avatarTom Gundersen <teg@jklm.no>
      Signed-off-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7b558513
    • Alex Williamson's avatar
      vfio/type1: Fix unmap overflow off-by-one · 58fec830
      Alex Williamson authored
      The below referenced commit adds a test for integer overflow, but in
      doing so prevents the unmap ioctl from ever including the last page of
      the address space.  Subtract one to compare to the last address of the
      unmap to avoid the overflow and wrap-around.
      
      Fixes: 71a7d3d7 ("vfio/type1: silence integer overflow warning")
      Link: https://bugzilla.redhat.com/show_bug.cgi?id=1662291
      Cc: stable@vger.kernel.org # v4.15+
      Reported-by: default avatarPei Zhang <pezhang@redhat.com>
      Debugged-by: default avatarPeter Xu <peterx@redhat.com>
      Reviewed-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: default avatarPeter Xu <peterx@redhat.com>
      Tested-by: default avatarPeter Xu <peterx@redhat.com>
      Reviewed-by: default avatarCornelia Huck <cohuck@redhat.com>
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      58fec830
    • Guo Ren's avatar
      irqchip/csky: fixup handle_irq_perbit break irq · 56752b21
      Guo Ren authored
      The handle_irq_perbit function loop every bit in hwirq local variable.
      
      handle_irq_perbit(hwirq) {
        for_everyt_bit_in(hwirq) {
      	handle_domain_irq()
      		->irq_exit()
      		->invoke_softirq()
      		->__do_softirq()
      		->local_irq_enable() // Here will cause new interrupt.
        }
      }
      
      When new interrupt coming at local_irq_enable, it will finish another
      interrupt handler and pull down the interrupt source. But hwirq is the
      local variable for handle_irq_perbit(), it can't get new interrupt
      controller pending reg status. So we need update hwirq with pending reg
      in every loop.
      
      Also change write_relax to writel could prevent stw from fast retire.
      When local_irq is enabled, intc regs is really set-in.
      Signed-off-by: default avatarGuo Ren <ren_guo@c-sky.com>
      Cc: Lu Baoquan <lu.baoquan@intellif.com>
      56752b21
    • Guo Ren's avatar
      csky: fixup compile error with pte_alloc · 2a60aa14
      Guo Ren authored
      Commit: 4cf58924 remove the address argument of pte_alloc without
      modify csky related code. linux-5.0-rc1 compile failed with csky.
      
      Remove the unnecessary address testing in pte_alloc().
      Signed-off-by: default avatarGuo Ren <ren_guo@c-sky.com>
      Cc: Joel Fernandes (Google) <joel@joelfernandes.org>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      2a60aa14
    • Masahiro Yamada's avatar
      vfio/pci: set TRACE_INCLUDE_PATH to fix the build error · d1fc1176
      Masahiro Yamada authored
      drivers/vfio/pci/vfio_pci_nvlink2.c cannot be compiled for in-tree
      building.
      
          CC      drivers/vfio/pci/vfio_pci_nvlink2.o
        In file included from drivers/vfio/pci/trace.h:102,
                         from drivers/vfio/pci/vfio_pci_nvlink2.c:29:
        ./include/trace/define_trace.h:89:42: fatal error: ./trace.h: No such file or directory
         #include TRACE_INCLUDE(TRACE_INCLUDE_FILE)
                                                ^
        compilation terminated.
        make[1]: *** [scripts/Makefile.build;277: drivers/vfio/pci/vfio_pci_nvlink2.o] Error 1
      
      To fix the build error, let's tell include/trace/define_trace.h the
      location of drivers/vfio/pci/trace.h
      
      Fixes: 7f928917 ("vfio_pci: Add NVIDIA GV100GL [Tesla V100 SXM2] subdriver")
      Reported-by: default avatarLaura Abbott <labbott@redhat.com>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: default avatarCornelia Huck <cohuck@redhat.com>
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      d1fc1176
    • Guo Ren's avatar
      csky: fixup CACHEV1 store instruction fast retire · 96354ad7
      Guo Ren authored
      For I/O access, 810/807 store instruction fast retire will cause wrong
      primitive. For example:
      
      	stw (clear interrupt source)
      	stw (unmask interrupt controller)
      	enable interrupt
      
      stw is fast retire instruction. When PC is run at enable interrupt
      stage, the clear interrupt source hasn't finished. It will cause another
      wrong irq-enter.
      
      So use mb() to prevent above.
      Signed-off-by: default avatarGuo Ren <ren_guo@c-sky.com>
      Cc: Lu Baoquan <lu.baoquan@intellif.com>
      96354ad7
    • Guo Ren's avatar
      csky: fixup relocation error with 807 & 860 · f553aa1c
      Guo Ren authored
      810 doesn't support jsri instruction and csky-as will leave
      jsri + nop for relocation. Module-probe need replace them with
      lrw + jsr.
      Signed-off-by: default avatarGuo Ren <ren_guo@c-sky.com>
      Cc: Hui Kai <huikai@acoinfo.com>
      f553aa1c
    • Christian Lamparter's avatar
      mtd: rawnand: qcom: fix memory corruption that causes panic · 81d9bdf5
      Christian Lamparter authored
      This patch fixes a memory corruption that occurred in the
      qcom-nandc driver since it was converted to nand_scan().
      
      On boot, an affected device will panic from a NPE at a weird place:
      | Unable to handle kernel NULL pointer dereference at virtual address 0
      | pgd = (ptrval)
      | [00000000] *pgd=00000000
      | Internal error: Oops: 80000005 [#1] SMP ARM
      | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.9 #0
      | Hardware name: Generic DT based system
      | PC is at   (null)
      | LR is at nand_block_isbad+0x90/0xa4
      | pc : [<00000000>]    lr : [<c0592240>]    psr: 80000013
      | sp : cf839d40  ip : 00000000  fp : cfae9e20
      | r10: cf815810  r9 : 00000000  r8 : 00000000
      | r7 : 00000000  r6 : 00000000  r5 : 00000001  r4 : cf815810
      | r3 : 00000000  r2 : cfae9810  r1 : ffffffff  r0 : cf815810
      | Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      | Control: 10c5387d  Table: 8020406a  DAC: 00000051
      | Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
      | [<c0592240>] (nand_block_isbad) from [<c0580a94>]
      | [<c0580a94>] (allocate_partition) from [<c05811e4>]
      | [<c05811e4>] (add_mtd_partitions) from [<c0581164>]
      | [<c0581164>] (parse_mtd_partitions) from [<c057def4>]
      | [<c057def4>] (mtd_device_parse_register) from [<c059d274>]
      | [<c059d274>] (qcom_nandc_probe) from [<c0567f00>]
      
      The problem is that the nand_scan()'s qcom_nand_attach_chip callback
      is updating the nandc->max_cwperpage from 1 to 4. This causes the
      sg_init_table of clear_bam_transaction() in the driver's
      qcom_nandc_block_bad() to memset much more than what was initially
      allocated by alloc_bam_transaction().
      
      This patch restores the old behavior by reallocating the shared bam
      transaction alloc_bam_transaction() after the chip was identified,
      but before mtd_device_parse_register() (which is an alias for
      mtd_device_register() - see panic) gets called. This fixes the
      corruption and the driver is working again.
      
      Cc: stable@vger.kernel.org
      Fixes: 6a3cec64 ("mtd: rawnand: qcom: convert driver to nand_scan()")
      Signed-off-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      Acked-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: default avatarBoris Brezillon <bbrezillon@kernel.org>
      81d9bdf5
    • Dan Carpenter's avatar
      ALSA: cs46xx: Potential NULL dereference in probe · 1524f4e4
      Dan Carpenter authored
      The "chip->dsp_spos_instance" can be NULL on some of the ealier error
      paths in snd_cs46xx_create().
      Reported-by: default avatar"Yavuz, Tuba" <tuba@ece.ufl.edu>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      1524f4e4
  5. 07 Jan, 2019 1 commit
    • Guo Ren's avatar
      Documentation/features: Add csky kernel features · 8a5aaf97
      Guo Ren authored
            core/ cBPF-JIT             : TODO |
            core/ eBPF-JIT             : TODO |
            core/ generic-idle-thread  :  ok  |
            core/ jump-labels          : TODO |
            core/ tracehook            :  ok  |
           debug/ KASAN                : TODO |
           debug/ gcov-profile-all     : TODO |
           debug/ kgdb                 : TODO |
           debug/ kprobes-on-ftrace    : TODO |
           debug/ kprobes              : TODO |
           debug/ kretprobes           : TODO |
           debug/ optprobes            : TODO |
           debug/ stackprotector       : TODO |
           debug/ uprobes              : TODO |
           debug/ user-ret-profiler    : TODO |
              io/ dma-contiguous       :  ok  |
         locking/ cmpxchg-local        : TODO |
         locking/ lockdep              : TODO |
         locking/ queued-rwlocks       :  ok  |
         locking/ queued-spinlocks     : TODO |
         locking/ rwsem-optimized      : TODO |
            perf/ kprobes-event        : TODO |
            perf/ perf-regs            : TODO |
            perf/ perf-stackdump       : TODO |
           sched/ membarrier-sync-core : TODO |
           sched/ numa-balancing       :  ..  |
         seccomp/ seccomp-filter       : TODO |
            time/ arch-tick-broadcast  : TODO |
            time/ clockevents          :  ok  |
            time/ context-tracking     : TODO |
            time/ irq-time-acct        : TODO |
            time/ modern-timekeeping   :  ok  |
            time/ virt-cpuacct         : TODO |
              vm/ ELF-ASLR             : TODO |
              vm/ PG_uncached          : TODO |
              vm/ THP                  :  ..  |
              vm/ batch-unmap-tlb-flush: TODO |
              vm/ huge-vmap            : TODO |
              vm/ ioremap_prot         : TODO |
              vm/ numa-memblock        :  ..  |
              vm/ pte_special          : TODO |
      Signed-off-by: default avatarGuo Ren <ren_guo@c-sky.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      8a5aaf97