1. 09 Jan, 2017 40 commits
    • Bart Van Assche's avatar
      IB/multicast: Check ib_find_pkey() return value · 5984423b
      Bart Van Assche authored
      commit d3a2418e upstream.
      
      This patch avoids that Coverity complains about not checking the
      ib_find_pkey() return value.
      
      Fixes: commit 547af765 ("IB/multicast: Report errors on multicast groups if P_key changes")
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Sean Hefty <sean.hefty@intel.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5984423b
    • Bart Van Assche's avatar
      IPoIB: Avoid reading an uninitialized member variable · 4187dfa6
      Bart Van Assche authored
      commit 11b642b8 upstream.
      
      This patch avoids that Coverity reports the following:
      
          Using uninitialized value port_attr.state when calling printk
      
      Fixes: commit 94232d9c ("IPoIB: Start multicast join process only on active ports")
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Erez Shitrit <erezsh@mellanox.com>
      Reviewed-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4187dfa6
    • Bart Van Assche's avatar
      IB/mad: Fix an array index check · 382072e0
      Bart Van Assche authored
      commit 2fe2f378 upstream.
      
      The array ib_mad_mgmt_class_table.method_table has MAX_MGMT_CLASS
      (80) elements. Hence compare the array index with that value instead
      of with IB_MGMT_MAX_METHODS (128). This patch avoids that Coverity
      reports the following:
      
      Overrunning array class->method_table of 80 8-byte elements at element index 127 (byte offset 1016) using index convert_mgmt_class(mad_hdr->mgmt_class) (which evaluates to 127).
      
      Fixes: commit b7ab0b19 ("IB/mad: Verify mgmt class in received MADs")
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Sean Hefty <sean.hefty@intel.com>
      Reviewed-by: default avatarHal Rosenstock <hal@mellanox.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      382072e0
    • Steven Rostedt (Red Hat)'s avatar
      fgraph: Handle a case where a tracer ignores set_graph_notrace · 239b40eb
      Steven Rostedt (Red Hat) authored
      commit 794de08a upstream.
      
      Both the wakeup and irqsoff tracers can use the function graph tracer when
      the display-graph option is set. The problem is that they ignore the notrace
      file, and record the entry of functions that would be ignored by the
      function_graph tracer. This causes the trace->depth to be recorded into the
      ring buffer. The set_graph_notrace uses a trick by adding a large negative
      number to the trace->depth when a graph function is to be ignored.
      
      On trace output, the graph function uses the depth to record a stack of
      functions. But since the depth is negative, it accesses the array with a
      negative number and causes an out of bounds access that can cause a kernel
      oops or corrupt data.
      
      Have the print functions handle cases where a tracer still records functions
      even when they are in set_graph_notrace.
      
      Also add warnings if the depth is below zero before accessing the array.
      
      Note, the function graph logic will still prevent the return of these
      functions from being recorded, which means that they will be left hanging
      without a return. For example:
      
         # echo '*spin*' > set_graph_notrace
         # echo 1 > options/display-graph
         # echo wakeup > current_tracer
         # cat trace
         [...]
            _raw_spin_lock() {
              preempt_count_add() {
              do_raw_spin_lock() {
            update_rq_clock();
      
      Where it should look like:
      
            _raw_spin_lock() {
              preempt_count_add();
              do_raw_spin_lock();
            }
            update_rq_clock();
      
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Fixes: 29ad23b0 ("ftrace: Add set_graph_notrace filter")
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      239b40eb
    • Thomas Gleixner's avatar
      x86/smpboot: Make logical package management more robust · a035dc67
      Thomas Gleixner authored
      commit 9d85eb91 upstream.
      
      The logical package management has several issues:
      
       - The APIC ids provided by ACPI are not required to be the same as the
         initial APIC id which can be retrieved by CPUID. The APIC ids provided
         by ACPI are those which are written by the BIOS into the APIC. The
         initial id is set by hardware and can not be changed. The hardware
         provided ids contain the real hardware package information.
      
         Especially AMD sets the effective APIC id different from the hardware id
         as they need to reserve space for the IOAPIC ids starting at id 0.
      
         As a consequence those machines trigger the currently active firmware
         bug printouts in dmesg, These are obviously wrong.
      
       - Virtual machines have their own interesting of enumerating APICs and
         packages which are not reliably covered by the current implementation.
      
      The sizing of the mapping array has been tweaked to be generously large to
      handle systems which provide a wrong core count when HT is disabled so the
      whole magic which checks for space in the physical hotplug case is not
      needed anymore.
      
      Simplify the whole machinery and do the mapping when the CPU starts and the
      CPUID derived physical package information is available. This solves the
      observed problems on AMD machines and works for the virtualization issues
      as well.
      
      Remove the extra call from XEN cpu bringup code as it is not longer
      required.
      
      Fixes: d49597fd ("x86/cpu: Deal with broken firmware (VMWare/XEN)")
      Reported-and-tested-by: default avatarBorislav Petkov <bp@suse.de>
      Tested-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: M. Vefa Bicakci <m.v.b@runbox.com>
      Cc: xen-devel <xen-devel@lists.xen.org>
      Cc: Charles (Chas) Williams <ciwillia@brocade.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Alok Kataria <akataria@vmware.com>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1612121102260.3429@nanosSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a035dc67
    • Marcos Paulo de Souza's avatar
      platform/x86: asus-nb-wmi.c: Add X45U quirk · 3168762e
      Marcos Paulo de Souza authored
      commit e74e2599 upstream.
      
      Without this patch, the Asus X45U wireless card can't be turned
      on (hard-blocked), but after a suspend/resume it just starts working.
      
      Following this bug report[1], there are other cases like this one, but
      this Asus is the only model that I can test.
      
      [1] https://ubuntuforums.org/showthread.php?t=2181558Signed-off-by: default avatarMarcos Paulo de Souza <marcos.souza.org@gmail.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3168762e
    • Steven Rostedt (Red Hat)'s avatar
      ftrace/x86_32: Set ftrace_stub to weak to prevent gcc from using short jumps to it · 21be088c
      Steven Rostedt (Red Hat) authored
      commit 847fa1a6 upstream.
      
      With new binutils, gcc may get smart with its optimization and change a jmp
      from a 5 byte jump to a 2 byte one even though it was jumping to a global
      function. But that global function existed within a 2 byte radius, and gcc
      was able to optimize it. Unfortunately, that jump was also being modified
      when function graph tracing begins. Since ftrace expected that jump to be 5
      bytes, but it was only two, it overwrote code after the jump, causing a
      crash.
      
      This was fixed for x86_64 with commit 8329e818, with the same subject as
      this commit, but nothing was done for x86_32.
      
      Fixes: d61f82d0 ("ftrace: use dynamic patching for updating mcount calls")
      Reported-by: default avatarColin Ian King <colin.king@canonical.com>
      Tested-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      21be088c
    • Michael S. Tsirkin's avatar
      vsock/virtio: fix src/dst cid format · e80ceb2d
      Michael S. Tsirkin authored
      commit f83f12d6 upstream.
      
      These fields are 64 bit, using le32_to_cpu and friends
      on these will not do the right thing.
      Fix this up.
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e80ceb2d
    • Jan Kara's avatar
      fsnotify: Fix possible use-after-free in inode iteration on umount · d06485e0
      Jan Kara authored
      commit 5716863e upstream.
      
      fsnotify_unmount_inodes() plays complex tricks to pin next inode in the
      sb->s_inodes list when iterating over all inodes. Furthermore the code has a
      bug that if the current inode is the last on i_sb_list that does not have e.g.
      I_FREEING set, then we leave next_i pointing to inode which may get removed
      from the i_sb_list once we drop s_inode_list_lock thus resulting in
      use-after-free issues (usually manifesting as infinite looping in
      fsnotify_unmount_inodes()).
      
      Fix the problem by keeping current inode pinned somewhat longer. Then we can
      make the code much simpler and standard.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d06485e0
    • Jim Mattson's avatar
      kvm: nVMX: Allow L1 to intercept software exceptions (#BP and #OF) · 3f618a0b
      Jim Mattson authored
      commit ef85b673 upstream.
      
      When L2 exits to L0 due to "exception or NMI", software exceptions
      (#BP and #OF) for which L1 has requested an intercept should be
      handled by L1 rather than L0. Previously, only hardware exceptions
      were forwarded to L1.
      Signed-off-by: default avatarJim Mattson <jmattson@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3f618a0b
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Don't lose hardware R/C bit updates in H_PROTECT · 94107133
      Paul Mackerras authored
      commit f064a0de upstream.
      
      The hashed page table MMU in POWER processors can update the R
      (reference) and C (change) bits in a HPTE at any time until the
      HPTE has been invalidated and the TLB invalidation sequence has
      completed.  In kvmppc_h_protect, which implements the H_PROTECT
      hypercall, we read the HPTE, modify the second doubleword,
      invalidate the HPTE in memory, do the TLB invalidation sequence,
      and then write the modified value of the second doubleword back
      to memory.  In doing so we could overwrite an R/C bit update done
      by hardware between when we read the HPTE and when the TLB
      invalidation completed.  To fix this we re-read the second
      doubleword after the TLB invalidation and OR in the (possibly)
      new values of R and C.  We can use an OR since hardware only ever
      sets R and C, never clears them.
      
      This race was found by code inspection.  In principle this bug could
      cause occasional guest memory corruption under host memory pressure.
      
      Fixes: a8606e20 ("KVM: PPC: Handle some PAPR hcalls in the kernel", 2011-06-29)
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      94107133
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Save/restore XER in checkpointed register state · 75b1053c
      Paul Mackerras authored
      commit 0d808df0 upstream.
      
      When switching from/to a guest that has a transaction in progress,
      we need to save/restore the checkpointed register state.  Although
      XER is part of the CPU state that gets checkpointed, the code that
      does this saving and restoring doesn't save/restore XER.
      
      This fixes it by saving and restoring the XER.  To allow userspace
      to read/write the checkpointed XER value, we also add a new ONE_REG
      specifier.
      
      The visible effect of this bug is that the guest may see its XER
      value being corrupted when it uses transactions.
      
      Fixes: e4e38121 ("KVM: PPC: Book3S HV: Add transactional memory support")
      Fixes: 0a8eccef ("KVM: PPC: Book3S HV: Add missing code for transaction reclaim on guest exit")
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Reviewed-by: default avatarThomas Huth <thuth@redhat.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      75b1053c
    • Kevin Barnett's avatar
      scsi: aacraid: remove wildcard for series 9 controllers · 483eeca2
      Kevin Barnett authored
      commit ae2aae24 upstream.
      
      Controllers with this PCI ID never shipped outside of
      PMCS/Microsemi. Remove the ID from the aacraid driver. smartpqi is the
      correct driver for these controllers.
      
      [mkp: patch description]
      Reviewed-by: default avatarScott Teel <scott.teel@microsemi.com>
      Signed-off-by: default avatarKevin Barnett <kevin.barnett@microsemi.com>
      Signed-off-by: default avatarDon Brace <don.brace@microsemi.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      483eeca2
    • Konstantin Khlebnikov's avatar
      md/raid5: limit request size according to implementation limits · 8beb252f
      Konstantin Khlebnikov authored
      commit e8d7c332 upstream.
      
      Current implementation employ 16bit counter of active stripes in lower
      bits of bio->bi_phys_segments. If request is big enough to overflow
      this counter bio will be completed and freed too early.
      
      Fortunately this not happens in default configuration because several
      other limits prevent that: stripe_cache_size * nr_disks effectively
      limits count of active stripes. And small max_sectors_kb at lower
      disks prevent that during normal read/write operations.
      
      Overflow easily happens in discard if it's enabled by module parameter
      "devices_handle_discard_safely" and stripe_cache_size is set big enough.
      
      This patch limits requests size with 256Mb - 8Kb to prevent overflows.
      Signed-off-by: default avatarKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Cc: Shaohua Li <shli@kernel.org>
      Cc: Neil Brown <neilb@suse.com>
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8beb252f
    • Josh Cartwright's avatar
      sc16is7xx: Drop bogus use of IRQF_ONESHOT · a0357979
      Josh Cartwright authored
      commit 04da7380 upstream.
      
      The use of IRQF_ONESHOT when registering an interrupt handler with
      request_irq() is non-sensical.
      
      Not only that, it also prevents the handler from being threaded when it
      otherwise should be w/ IRQ_FORCED_THREADING is enabled.  This causes the
      following deadlock observed by Sean Nyekjaer on -rt:
      
      Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
      [..]
         rt_spin_lock_slowlock from queue_kthread_work
         queue_kthread_work from sc16is7xx_irq
         sc16is7xx_irq [sc16is7xx] from handle_irq_event_percpu
         handle_irq_event_percpu from handle_irq_event
         handle_irq_event from handle_level_irq
         handle_level_irq from generic_handle_irq
         generic_handle_irq from mxc_gpio_irq_handler
         mxc_gpio_irq_handler from mx3_gpio_irq_handler
         mx3_gpio_irq_handler from generic_handle_irq
         generic_handle_irq from __handle_domain_irq
         __handle_domain_irq from gic_handle_irq
         gic_handle_irq from __irq_svc
         __irq_svc from rt_spin_unlock
         rt_spin_unlock from kthread_worker_fn
         kthread_worker_fn from kthread
         kthread from ret_from_fork
      
      Fixes: 9e6f4ca3 ("sc16is7xx: use kthread_worker for tx_work and irq")
      Reported-by: default avatarSean Nyekjaer <sean.nyekjaer@prevas.dk>
      Signed-off-by: default avatarJosh Cartwright <joshc@ni.com>
      Cc: linux-rt-users@vger.kernel.org
      Cc: Jakub Kicinski <moorray3@wp.pl>
      Cc: linux-serial@vger.kernel.org
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarJulia Cartwright <julia@ni.com>
      Acked-by: default avatarJakub Kicinski <kubakici@wp.pl>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a0357979
    • Kees Cook's avatar
      latent_entropy: fix ARM build error on earlier gcc · 7d5ec9eb
      Kees Cook authored
      commit 9988f4d5 upstream.
      
      This fixes build errors seen on gcc-4.9.3 or gcc-5.3.1 for an ARM:
      
      arm-soc/init/initramfs.c: In function 'error':
      arm-soc/init/initramfs.c:50:1: error: unrecognizable insn:
       }
       ^
      (insn 26 25 27 5 (set (reg:SI 111 [ local_entropy.243 ])
              (rotatert:SI (reg:SI 116 [ local_entropy.243 ])
                  (const_int -30 [0xffffffffffffffe2]))) -1
           (nil))
      
      Patch from PaX Team <pageexec@freemail.hu>
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reported-by: default avatarBrad Spengler <spender@grsecurity.net>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7d5ec9eb
    • Marc Zyngier's avatar
      arm64: KVM: pmu: Reset PMSELR_EL0.SEL to a sane value before entering the guest · 959e9530
      Marc Zyngier authored
      commit 21cbe3cc upstream.
      
      The ARMv8 architecture allows the cycle counter to be configured
      by setting PMSELR_EL0.SEL==0x1f and then accessing PMXEVTYPER_EL0,
      hence accessing PMCCFILTR_EL0. But it disallows the use of
      PMSELR_EL0.SEL==0x1f to access the cycle counter itself through
      PMXEVCNTR_EL0.
      
      Linux itself doesn't violate this rule, but we may end up with
      PMSELR_EL0.SEL being set to 0x1f when we enter a guest. If that
      guest accesses PMXEVCNTR_EL0, the access may UNDEF at EL1,
      despite the guest not having done anything wrong.
      
      In order to avoid this unfortunate course of events (haha!), let's
      sanitize PMSELR_EL0 on guest entry. This ensures that the guest
      won't explode unexpectedly.
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      959e9530
    • Heiko Carstens's avatar
      s390/kexec: use node 0 when re-adding crash kernel memory · 111e0cca
      Heiko Carstens authored
      commit 9f88eb4d upstream.
      
      When re-adding crash kernel memory within setup_resources() the
      function memblock_add() is used. That function will add memory by
      default to node "MAX_NUMNODES" instead of node 0, like the memory
      detection code does. In case of !NUMA this will trigger this warning
      when the kernel generates the vmemmap:
      
      Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead
      WARNING: CPU: 0 PID: 0 at mm/memblock.c:1261 memblock_virt_alloc_internal+0x76/0x220
      CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.0-rc6 #16
      Call Trace:
       [<0000000000d0b2e8>] memblock_virt_alloc_try_nid+0x88/0xc8
       [<000000000083c8ea>] __earlyonly_bootmem_alloc.constprop.1+0x42/0x50
       [<000000000083e7f4>] vmemmap_populate+0x1ac/0x1e0
       [<0000000000840136>] sparse_mem_map_populate+0x46/0x68
       [<0000000000d0c59c>] sparse_init+0x184/0x238
       [<0000000000cf45f6>] paging_init+0xbe/0xf8
       [<0000000000cf1d4a>] setup_arch+0xa02/0xae0
       [<0000000000ced75a>] start_kernel+0x72/0x450
       [<0000000000100020>] _stext+0x20/0x80
      
      If NUMA is selected numa_setup_memory() will fix the node assignments
      before the vmemmap will be populated; so this warning will only appear
      if NUMA is not selected.
      
      To fix this simply use memblock_add_node() and re-add crash kernel
      memory explicitly to node 0.
      Reported-and-tested-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Fixes: 4e042af4 ("s390/kexec: fix crash on resize of reserved memory")
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      111e0cca
    • Gerald Schaefer's avatar
      s390/vmlogrdr: fix IUCV buffer allocation · 53bbee33
      Gerald Schaefer authored
      commit 5457e03d upstream.
      
      The buffer for iucv_message_receive() needs to be below 2 GB. In
      __iucv_message_receive(), the buffer address is casted to an u32, which
      would result in either memory corruption or an addressing exception when
      using addresses >= 2 GB.
      
      Fix this by using GFP_DMA for the buffer allocation.
      Signed-off-by: default avatarGerald Schaefer <gerald.schaefer@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      53bbee33
    • Yves-Alexis Perez's avatar
      firmware: fix usermode helper fallback loading · b3854cef
      Yves-Alexis Perez authored
      commit 2e700f8d upstream.
      
      When you use the firmware usermode helper fallback with a timeout value set to a
      value greater than INT_MAX (2147483647) a cast overflow issue causes the
      timeout value to go negative and breaks all usermode helper loading. This
      regression was introduced through commit 68ff2a00 ("firmware_loader:
      handle timeout via wait_for_completion_interruptible_timeout()") on kernel
      v4.0.
      
      The firmware_class drivers relies on the firmware usermode helper
      fallback as a mechanism to look for firmware if the direct filesystem
      search failed only if:
      
        a) You've enabled CONFIG_FW_LOADER_USER_HELPER_FALLBACK (not many distros):
      
        Then all of these callers will rely on the fallback mechanism in case
        the firmware is not found through an initial direct filesystem lookup:
      
        o request_firmware()
        o request_firmware_into_buf()
        o request_firmware_nowait()
      
        b) If you've only enabled CONFIG_FW_LOADER_USER_HELPER (most distros):
      
        Then only callers using request_firmware_nowait() with the second
        argument set to false, this explicitly is requesting the UMH firmware
        fallback to be relied on in case the first filesystem lookup fails.
      
        Using Coccinelle SmPL grammar we have identified only two drivers
        explicitly requesting the UMH firmware fallback mechanism:
      
        - drivers/firmware/dell_rbu.c
        - drivers/leds/leds-lp55xx-common.c
      
      Since most distributions only enable CONFIG_FW_LOADER_USER_HELPER the
      biggest impact of this regression are users of the dell_rbu and
      leds-lp55xx-common device driver which required the UMH to find their
      respective needed firmwares.
      
      The default timeout for the UMH is set to 60 seconds always, as of
      commit 68ff2a00 ("firmware_loader: handle timeout via
      wait_for_completion_interruptible_timeout()") the timeout was bumped
      to MAX_JIFFY_OFFSET ((LONG_MAX >> 1)-1). Additionally the MAX_JIFFY_OFFSET
      value was also used if the timeout was configured by a user to 0.
      
      The following works:
      
      echo 2147483647 > /sys/class/firmware/timeout
      
      But both of the following set the timeout to MAX_JIFFY_OFFSET even if
      we display 0 back to userspace:
      
      echo 2147483648 > /sys/class/firmware/timeout
      cat /sys/class/firmware/timeout
      0
      
      echo 0> /sys/class/firmware/timeout
      cat /sys/class/firmware/timeout
      0
      
      A max value of INT_MAX (2147483647) seconds is therefore implicit due to the
      another cast with simple_strtol().
      
      This fixes the secondary cast (the first one is simple_strtol() but its an
      issue only by forcing an implicit limit) by re-using the timeout variable and
      only setting retval in appropriate cases.
      
      Lastly worth noting systemd had ripped out the UMH firmware fallback
      mechanism from udev since udev 2014 via commit be2ea723b1d023b3d
      ("udev: remove userspace firmware loading support"), so as of systemd v217.
      Signed-off-by: default avatarYves-Alexis Perez <corsac@corsac.net>
      Fixes: 68ff2a00 "firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()"
      Cc: Luis R. Rodriguez <mcgrof@kernel.org>
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Reviewed-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      [mcgrof@kernel.org: gave commit log a whole lot of love]
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b3854cef
    • Vineet Gupta's avatar
      ARC: mm: arc700: Don't assume 2 colours for aliasing VIPT dcache · ce7ec3d7
      Vineet Gupta authored
      commit 08fe0079 upstream.
      
      An ARC700 customer reported linux boot crashes when upgrading to bigger
      L1 dcache (64K from 32K). Turns out they had an aliasing VIPT config and
      current code only assumed 2 colours, while theirs had 4. So default to 4
      colours and complain if there are fewer. Ideally this needs to be a
      Kconfig option, but heck that's too much of hassle for a single user.
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ce7ec3d7
    • Wei Fang's avatar
      scsi: avoid a permanent stop of the scsi device's request queue · 9d33a399
      Wei Fang authored
      commit d2a14525 upstream.
      
      A race between scanning and fc_remote_port_delete() may result in a
      permanent stop if the device gets blocked before scsi_sysfs_add_sdev()
      and unblocked after.  The reason is that blocking a device sets both the
      SDEV_BLOCKED state and the QUEUE_FLAG_STOPPED.  However,
      scsi_sysfs_add_sdev() unconditionally sets SDEV_RUNNING which causes the
      device to be ignored by scsi_target_unblock() and thus never have its
      QUEUE_FLAG_STOPPED cleared leading to a device which is apparently
      running but has a stopped queue.
      
      We actually have two places where SDEV_RUNNING is set: once in
      scsi_add_lun() which respects the blocked flag and once in
      scsi_sysfs_add_sdev() which doesn't.  Since the second set is entirely
      spurious, simply remove it to fix the problem.
      Reported-by: default avatarZengxi Chen <chenzengxi@huawei.com>
      Signed-off-by: default avatarWei Fang <fangwei1@huawei.com>
      Reviewed-by: default avatarEwan D. Milne <emilne@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9d33a399
    • Steffen Maier's avatar
      scsi: zfcp: fix rport unblock race with LUN recovery · 2a940b85
      Steffen Maier authored
      commit 6f2ce1c6 upstream.
      
      It is unavoidable that zfcp_scsi_queuecommand() has to finish requests
      with DID_IMM_RETRY (like fc_remote_port_chkready()) during the time
      window when zfcp detected an unavailable rport but
      fc_remote_port_delete(), which is asynchronous via
      zfcp_scsi_schedule_rport_block(), has not yet blocked the rport.
      
      However, for the case when the rport becomes available again, we should
      prevent unblocking the rport too early.  In contrast to other FCP LLDDs,
      zfcp has to open each LUN with the FCP channel hardware before it can
      send I/O to a LUN.  So if a port already has LUNs attached and we
      unblock the rport just after port recovery, recoveries of LUNs behind
      this port can still be pending which in turn force
      zfcp_scsi_queuecommand() to unnecessarily finish requests with
      DID_IMM_RETRY.
      
      This also opens a time window with unblocked rport (until the followup
      LUN reopen recovery has finished).  If a scsi_cmnd timeout occurs during
      this time window fc_timed_out() cannot work as desired and such command
      would indeed time out and trigger scsi_eh. This prevents a clean and
      timely path failover.  This should not happen if the path issue can be
      recovered on FC transport layer such as path issues involving RSCNs.
      
      Fix this by only calling zfcp_scsi_schedule_rport_register(), to
      asynchronously trigger fc_remote_port_add(), after all LUN recoveries as
      children of the rport have finished and no new recoveries of equal or
      higher order were triggered meanwhile.  Finished intentionally includes
      any recovery result no matter if successful or failed (still unblock
      rport so other successful LUNs work).  For simplicity, we check after
      each finished LUN recovery if there is another LUN recovery pending on
      the same port and then do nothing.  We handle the special case of a
      successful recovery of a port without LUN children the same way without
      changing this case's semantics.
      
      For debugging we introduce 2 new trace records written if the rport
      unblock attempt was aborted due to still unfinished or freshly triggered
      recovery. The records are only written above the default trace level.
      
      Benjamin noticed the important special case of new recovery that can be
      triggered between having given up the erp_lock and before calling
      zfcp_erp_action_cleanup() within zfcp_erp_strategy().  We must avoid the
      following sequence:
      
      ERP thread                 rport_work      other context
      -------------------------  --------------  --------------------------------
      port is unblocked, rport still blocked,
       due to pending/running ERP action,
       so ((port->status & ...UNBLOCK) != 0)
       and (port->rport == NULL)
      unlock ERP
      zfcp_erp_action_cleanup()
      case ZFCP_ERP_ACTION_REOPEN_LUN:
      zfcp_erp_try_rport_unblock()
      ((status & ...UNBLOCK) != 0) [OLD!]
                                                 zfcp_erp_port_reopen()
                                                 lock ERP
                                                 zfcp_erp_port_block()
                                                 port->status clear ...UNBLOCK
                                                 unlock ERP
                                                 zfcp_scsi_schedule_rport_block()
                                                 port->rport_task = RPORT_DEL
                                                 queue_work(rport_work)
                                 zfcp_scsi_rport_work()
                                 (port->rport_task != RPORT_ADD)
                                 port->rport_task = RPORT_NONE
                                 zfcp_scsi_rport_block()
                                 if (!port->rport) return
      zfcp_scsi_schedule_rport_register()
      port->rport_task = RPORT_ADD
      queue_work(rport_work)
                                 zfcp_scsi_rport_work()
                                 (port->rport_task == RPORT_ADD)
                                 port->rport_task = RPORT_NONE
                                 zfcp_scsi_rport_register()
                                 (port->rport == NULL)
                                 rport = fc_remote_port_add()
                                 port->rport = rport;
      
      Now the rport was erroneously unblocked while the zfcp_port is blocked.
      This is another situation we want to avoid due to scsi_eh
      potential. This state would at least remain until the new recovery from
      the other context finished successfully, or potentially forever if it
      failed.  In order to close this race, we take the erp_lock inside
      zfcp_erp_try_rport_unblock() when checking the status of zfcp_port or
      LUN.  With that, the possible corresponding rport state sequences would
      be: (unblock[ERP thread],block[other context]) if the ERP thread gets
      erp_lock first and still sees ((port->status & ...UNBLOCK) != 0),
      (block[other context],NOP[ERP thread]) if the ERP thread gets erp_lock
      after the other context has already cleard ...UNBLOCK from port->status.
      
      Since checking fields of struct erp_action is unsafe because they could
      have been overwritten (re-used for new recovery) meanwhile, we only
      check status of zfcp_port and LUN since these are only changed under
      erp_lock elsewhere. Regarding the check of the proper status flags (port
      or port_forced are similar to the shown adapter recovery):
      
      [zfcp_erp_adapter_shutdown()]
      zfcp_erp_adapter_reopen()
       zfcp_erp_adapter_block()
        * clear UNBLOCK ---------------------------------------+
       zfcp_scsi_schedule_rports_block()                       |
       write_lock_irqsave(&adapter->erp_lock, flags);-------+  |
       zfcp_erp_action_enqueue()                            |  |
        zfcp_erp_setup_act()                                |  |
         * set ERP_INUSE -----------------------------------|--|--+
       write_unlock_irqrestore(&adapter->erp_lock, flags);--+  |  |
      .context-switch.                                         |  |
      zfcp_erp_thread()                                        |  |
       zfcp_erp_strategy()                                     |  |
        write_lock_irqsave(&adapter->erp_lock, flags);------+  |  |
        ...                                                 |  |  |
        zfcp_erp_strategy_check_target()                    |  |  |
         zfcp_erp_strategy_check_adapter()                  |  |  |
          zfcp_erp_adapter_unblock()                        |  |  |
           * set UNBLOCK -----------------------------------|--+  |
        zfcp_erp_action_dequeue()                           |     |
         * clear ERP_INUSE ---------------------------------|-----+
        ...                                                 |
        write_unlock_irqrestore(&adapter->erp_lock, flags);-+
      
      Hence, we should check for both UNBLOCK and ERP_INUSE because they are
      interleaved.  Also we need to explicitly check ERP_FAILED for the link
      down case which currently does not clear the UNBLOCK flag in
      zfcp_fsf_link_down_info_eval().
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: 8830271c ("[SCSI] zfcp: Dont fail SCSI commands when transitioning to blocked fc_rport")
      Fixes: a2fa0aed ("[SCSI] zfcp: Block FC transport rports early on errors")
      Fixes: 5f852be9 ("[SCSI] zfcp: Fix deadlock between zfcp ERP and SCSI")
      Fixes: 338151e0 ("[SCSI] zfcp: make use of fc_remote_port_delete when target port is unavailable")
      Fixes: 3859f6a2 ("[PATCH] zfcp: add rports to enable scsi_add_device to work again")
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2a940b85
    • Steffen Maier's avatar
      scsi: zfcp: do not trace pure benign residual HBA responses at default level · 744807cb
      Steffen Maier authored
      commit 56d23ed7 upstream.
      
      Since quite a while, Linux issues enough SCSI commands per scsi_device
      which successfully return with FCP_RESID_UNDER, FSF_FCP_RSP_AVAILABLE,
      and SAM_STAT_GOOD.  This floods the HBA trace area and we cannot see
      other and important HBA trace records long enough.
      
      Therefore, do not trace HBA response errors for pure benign residual
      under counts at the default trace level.
      
      This excludes benign residual under count combined with other validity
      bits set in FCP_RSP_IU, such as FCP_SNS_LEN_VAL.  For all those other
      cases, we still do want to see both the HBA record and the corresponding
      SCSI record by default.
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: a54ca0f6 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      744807cb
    • Benjamin Block's avatar
      scsi: zfcp: fix use-after-"free" in FC ingress path after TMF · 2ce34d9d
      Benjamin Block authored
      commit dac37e15 upstream.
      
      When SCSI EH invokes zFCP's callbacks for eh_device_reset_handler() and
      eh_target_reset_handler(), it expects us to relent the ownership over
      the given scsi_cmnd and all other scsi_cmnds within the same scope - LUN
      or target - when returning with SUCCESS from the callback ('release'
      them).  SCSI EH can then reuse those commands.
      
      We did not follow this rule to release commands upon SUCCESS; and if
      later a reply arrived for one of those supposed to be released commands,
      we would still make use of the scsi_cmnd in our ingress tasklet. This
      will at least result in undefined behavior or a kernel panic because of
      a wrong kernel pointer dereference.
      
      To fix this, we NULLify all pointers to scsi_cmnds (struct zfcp_fsf_req
      *)->data in the matching scope if a TMF was successful. This is done
      under the locks (struct zfcp_adapter *)->abort_lock and (struct
      zfcp_reqlist *)->lock to prevent the requests from being removed from
      the request-hashtable, and the ingress tasklet from making use of the
      scsi_cmnd-pointer in zfcp_fsf_fcp_cmnd_handler().
      
      For cases where a reply arrives during SCSI EH, but before we get a
      chance to NULLify the pointer - but before we return from the callback
      -, we assume that the code is protected from races via the CAS operation
      in blk_complete_request() that is called in scsi_done().
      
      The following stacktrace shows an example for a crash resulting from the
      previous behavior:
      
      Unable to handle kernel pointer dereference at virtual kernel address fffffee17a672000
      Oops: 0038 [#1] SMP
      CPU: 2 PID: 0 Comm: swapper/2 Not tainted
      task: 00000003f7ff5be0 ti: 00000003f3d38000 task.ti: 00000003f3d38000
      Krnl PSW : 0404d00180000000 00000000001156b0 (smp_vcpu_scheduled+0x18/0x40)
                 R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
      Krnl GPRS: 000000200000007e 0000000000000000 fffffee17a671fd8 0000000300000015
                 ffffffff80000000 00000000005dfde8 07000003f7f80e00 000000004fa4e800
                 000000036ce8d8f8 000000036ce8d9c0 00000003ece8fe00 ffffffff969c9e93
                 00000003fffffffd 000000036ce8da10 00000000003bf134 00000003f3b07918
      Krnl Code: 00000000001156a2: a7190000        lghi    %r1,0
                 00000000001156a6: a7380015        lhi    %r3,21
                #00000000001156aa: e32050000008    ag    %r2,0(%r5)
                >00000000001156b0: 482022b0        lh    %r2,688(%r2)
                 00000000001156b4: ae123000        sigp    %r1,%r2,0(%r3)
                 00000000001156b8: b2220020        ipm    %r2
                 00000000001156bc: 8820001c        srl    %r2,28
                 00000000001156c0: c02700000001    xilf    %r2,1
      Call Trace:
      ([<0000000000000000>] 0x0)
       [<000003ff807bdb8e>] zfcp_fsf_fcp_cmnd_handler+0x3de/0x490 [zfcp]
       [<000003ff807be30a>] zfcp_fsf_req_complete+0x252/0x800 [zfcp]
       [<000003ff807c0a48>] zfcp_fsf_reqid_check+0xe8/0x190 [zfcp]
       [<000003ff807c194e>] zfcp_qdio_int_resp+0x66/0x188 [zfcp]
       [<000003ff80440c64>] qdio_kick_handler+0xdc/0x310 [qdio]
       [<000003ff804463d0>] __tiqdio_inbound_processing+0xf8/0xcd8 [qdio]
       [<0000000000141fd4>] tasklet_action+0x9c/0x170
       [<0000000000141550>] __do_softirq+0xe8/0x258
       [<000000000010ce0a>] do_softirq+0xba/0xc0
       [<000000000014187c>] irq_exit+0xc4/0xe8
       [<000000000046b526>] do_IRQ+0x146/0x1d8
       [<00000000005d6a3c>] io_return+0x0/0x8
       [<00000000005d6422>] vtime_stop_cpu+0x4a/0xa0
      ([<0000000000000000>] 0x0)
       [<0000000000103d8a>] arch_cpu_idle+0xa2/0xb0
       [<0000000000197f94>] cpu_startup_entry+0x13c/0x1f8
       [<0000000000114782>] smp_start_secondary+0xda/0xe8
       [<00000000005d6efe>] restart_int_handler+0x56/0x6c
       [<0000000000000000>] 0x0
      Last Breaking-Event-Address:
       [<00000000003bf12e>] arch_spin_lock_wait+0x56/0xb0
      Suggested-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Fixes: ea127f97 ("[PATCH] s390 (7/7): zfcp host adapter.") (tglx/history.git)
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2ce34d9d
    • Varun Prakash's avatar
      iscsi-target: Return error if unable to add network portal · 8032a300
      Varun Prakash authored
      commit 83337e54 upstream.
      
      If iscsit_tpg_add_network_portal() fails then
      return error code instead of 0 to user space.
      
      If iscsi-target returns 0 then user space keeps
      on retrying same command infinitely, targetcli or
      echo hangs till command completes with non zero
      return value. In some cases it is possible that
      add network portal command never completes with
      success even after retrying multiple times,
      for example - cxgbit_setup_np() always returns
      -EINVAL if portal IP does not belong to Chelsio
      adapter interface.
      Signed-off-by: default avatarVarun Prakash <varun@chelsio.com>
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      [ bvanassche: Added "Fixes:" and "Cc: stable" tags ]
      Fixes: commit d4b3fa4b ("iscsi-target: Make iscsi_tpg_np driver show/store use generic code")
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8032a300
    • Kashyap Desai's avatar
      scsi: megaraid_sas: Do not set MPI2_TYPE_CUDA for JBOD FP path for FW which... · 113783ec
      Kashyap Desai authored
      scsi: megaraid_sas: Do not set MPI2_TYPE_CUDA for JBOD FP path for FW which does not support JBOD sequence map
      
      commit d5573584 upstream.
      Signed-off-by: default avatarSumit Saxena <sumit.saxena@broadcom.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Reviewed-by: default avatarTomas Henzl <thenzl@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      113783ec
    • Kashyap Desai's avatar
      scsi: megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset · 6089f871
      Kashyap Desai authored
      commit 18e1c7f6 upstream.
      
      For SRIOV enabled firmware, if there is a OCR(online controller reset)
      possibility driver set the convert flag to 1, which is not happening if
      there are outstanding commands even after 180 seconds.  As driver does
      not set convert flag to 1 and still making the OCR to run, VF(Virtual
      function) driver is directly writing on to the register instead of
      waiting for 30 seconds. Setting convert flag to 1 will cause VF driver
      will wait for 30 secs before going for reset.
      Signed-off-by: default avatarKiran Kumar Kasturi <kiran-kumar.kasturi@broadcom.com>
      Signed-off-by: default avatarSumit Saxena <sumit.saxena@broadcom.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Reviewed-by: default avatarTomas Henzl <thenzl@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6089f871
    • Johan Hovold's avatar
      stm class: Fix device leak in open error path · 2d291434
      Johan Hovold authored
      commit a0ebf519 upstream.
      
      Make sure to drop the reference taken by class_find_device() also on
      allocation errors in open().
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Fixes: 7bd1d409 ("stm class: Introduce an abstraction for...")
      Signed-off-by: default avatarAlexander Shishkin <alexander.shishkin@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2d291434
    • Maciej S. Szmigiero's avatar
      vt: fix Scroll Lock LED trigger name · fbb28e76
      Maciej S. Szmigiero authored
      commit 31b5929d upstream.
      
      There is a disagreement between drivers/tty/vt/keyboard.c and
      drivers/input/input-leds.c with regard to what is a Scroll Lock LED
      trigger name: input calls it "kbd-scrolllock", but vt calls it
      "kbd-scrollock" (two l's).
      This prevents Scroll Lock LED trigger from binding to this LED by default.
      
      Since it is a scroLL Lock LED, this interface was introduced only about a
      year ago and in an Internet search people seem to reference this trigger
      only to set it to this LED let's simply rename it to "kbd-scrolllock".
      
      Also, it looks like this was supposed to be changed before this code was
      merged: https://lkml.org/lkml/2015/6/9/697 but it was done only on
      the input side.
      Signed-off-by: default avatarMaciej S. Szmigiero <mail@maciej.szmigiero.name>
      Acked-by: default avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fbb28e76
    • Rabin Vincent's avatar
      block: protect iterate_bdevs() against concurrent close · 11aa5c10
      Rabin Vincent authored
      commit af309226 upstream.
      
      If a block device is closed while iterate_bdevs() is handling it, the
      following NULL pointer dereference occurs because bdev->b_disk is NULL
      in bdev_get_queue(), which is called from blk_get_backing_dev_info() (in
      turn called by the mapping_cap_writeback_dirty() call in
      __filemap_fdatawrite_range()):
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000508
       IP: [<ffffffff81314790>] blk_get_backing_dev_info+0x10/0x20
       PGD 9e62067 PUD 9ee8067 PMD 0
       Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
       Modules linked in:
       CPU: 1 PID: 2422 Comm: sync Not tainted 4.5.0-rc7+ #400
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
       task: ffff880009f4d700 ti: ffff880009f5c000 task.ti: ffff880009f5c000
       RIP: 0010:[<ffffffff81314790>]  [<ffffffff81314790>] blk_get_backing_dev_info+0x10/0x20
       RSP: 0018:ffff880009f5fe68  EFLAGS: 00010246
       RAX: 0000000000000000 RBX: ffff88000ec17a38 RCX: ffffffff81a4e940
       RDX: 7fffffffffffffff RSI: 0000000000000000 RDI: ffff88000ec176c0
       RBP: ffff880009f5fe68 R08: 0000000000000000 R09: 0000000000000000
       R10: 0000000000000001 R11: 0000000000000000 R12: ffff88000ec17860
       R13: ffffffff811b25c0 R14: ffff88000ec178e0 R15: ffff88000ec17a38
       FS:  00007faee505d700(0000) GS:ffff88000fb00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
       CR2: 0000000000000508 CR3: 0000000009e8a000 CR4: 00000000000006e0
       Stack:
        ffff880009f5feb8 ffffffff8112e7f5 0000000000000000 7fffffffffffffff
        0000000000000000 0000000000000000 7fffffffffffffff 0000000000000001
        ffff88000ec178e0 ffff88000ec17860 ffff880009f5fec8 ffffffff8112e81f
       Call Trace:
        [<ffffffff8112e7f5>] __filemap_fdatawrite_range+0x85/0x90
        [<ffffffff8112e81f>] filemap_fdatawrite+0x1f/0x30
        [<ffffffff811b25d6>] fdatawrite_one_bdev+0x16/0x20
        [<ffffffff811bc402>] iterate_bdevs+0xf2/0x130
        [<ffffffff811b2763>] sys_sync+0x63/0x90
        [<ffffffff815d4272>] entry_SYSCALL_64_fastpath+0x12/0x76
       Code: 0f 1f 44 00 00 48 8b 87 f0 00 00 00 55 48 89 e5 <48> 8b 80 08 05 00 00 5d
       RIP  [<ffffffff81314790>] blk_get_backing_dev_info+0x10/0x20
        RSP <ffff880009f5fe68>
       CR2: 0000000000000508
       ---[ end trace 2487336ceb3de62d ]---
      
      The crash is easily reproducible by running the following command, if an
      msleep(100) is inserted before the call to func() in iterate_devs():
      
       while :; do head -c1 /dev/nullb0; done > /dev/null & while :; do sync; done
      
      Fix it by holding the bd_mutex across the func() call and only calling
      func() if the bdev is opened.
      
      Fixes: 5c0d6b60 ("vfs: Create function for iterating over block devices")
      Reported-and-tested-by: default avatarWei Fang <fangwei1@huawei.com>
      Signed-off-by: default avatarRabin Vincent <rabinv@axis.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      11aa5c10
    • Tomas Winkler's avatar
      mei: me: add lewisburg device ids · 09c15492
      Tomas Winkler authored
      commit 9ff2007b upstream.
      
      Add MEI Lewisburg PCH IDs for Purley based workstations.
      Signed-off-by: default avatarAlexander Usyskin <alexander.usyskin@intel.com>
      Signed-off-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      09c15492
    • Alexander Usyskin's avatar
      mei: request async autosuspend at the end of enumeration · 0814c3ed
      Alexander Usyskin authored
      commit d5f8e166 upstream.
      
      pm_runtime_autosuspend can take synchronous or asynchronous
      paths, Because we are calling pm_runtime_mark_last_busy just before
      this most of the cases it takes the asynchronous way. However,
      when the FW or driver resets during already running runtime suspend,
      the call will result in calling to the driver's rpm callback and results
      in a deadlock on device_lock.
      The simplest fix is to replace pm_runtime_autosuspend with
      asynchronous pm_request_autosuspend.
      Signed-off-by: default avatarAlexander Usyskin <alexander.usyskin@intel.com>
      Signed-off-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0814c3ed
    • Russell Currey's avatar
      drivers/gpu/drm/ast: Fix infinite loop if read fails · 66469319
      Russell Currey authored
      commit 298360af upstream.
      
      ast_get_dram_info() configures a window in order to access BMC memory.
      A BMC register can be configured to disallow this, and if so, causes
      an infinite loop in the ast driver which renders the system unusable.
      
      Fix this by erroring out if an error is detected.  On powerpc systems with
      EEH, this leads to the device being fenced and the system continuing to
      operate.
      Signed-off-by: default avatarRussell Currey <ruscur@russell.cc>
      Reviewed-by: default avatarJoel Stanley <joel@jms.id.au>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161215051241.20815-1-ruscur@russell.ccSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      66469319
    • Rex Zhu's avatar
      drm/amdgpu: fix init save/restore list in gfx_v8.0 · 8dbd6f70
      Rex Zhu authored
      commit 202e0b22 upstream.
      
      set valid data to mmRLC_SRM_INDEX_CNTL_ADDRx/DATAx.
      Signed-off-by: default avatarRex Zhu <Rex.Zhu@amd.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8dbd6f70
    • Rex Zhu's avatar
      drm/amdgpu: fix enable_cp_power_gating in gfx_v8.0. · f2d3d7f8
      Rex Zhu authored
      commit eb584241 upstream.
      
      the CP_PG_DISABLE bit was reversed.
      Signed-off-by: default avatarRex Zhu <Rex.Zhu@amd.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f2d3d7f8
    • Hawking Zhang's avatar
      drm/amd/powerplay: bypass fan table setup if no fan connected · 326760ba
      Hawking Zhang authored
      commit 10e2ca34 upstream.
      
      If vBIOS noFan bit is set, the fan table parameters in thermal controller
      will not get initialized. The driver should avoid to use these uninitialized
      parameter to do calculation. Otherwise, it may trigger divide 0 error.
      Signed-off-by: default avatarHawking Zhang <Hawking.Zhang@amd.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      326760ba
    • Patrik Jakobsson's avatar
      drm/gma500: Add compat ioctl · aa286e88
      Patrik Jakobsson authored
      commit 0a97c81a upstream.
      
      Hook up drm_compat_ioctl to support 32-bit userspace on 64-bit kernels.
      It turns out that N2600 and N2800 comes with 64-bit enabled. We
      previously assumed there where no such systems out there.
      Signed-off-by: default avatarPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
      Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161101144315.2955-1-patrik.r.jakobsson@gmail.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aa286e88
    • Alex Deucher's avatar
      6187f21f
    • Alex Deucher's avatar
      drm/radeon: add additional pci revision to dpm workaround · 851bedd8
      Alex Deucher authored
      commit 8729675c upstream.
      
      New variant.
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      851bedd8