1. 12 Jan, 2017 11 commits
  2. 09 Jan, 2017 29 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.41 · cdd86b97
      Greg Kroah-Hartman authored
      cdd86b97
    • Thomas Petazzoni's avatar
      net: mvpp2: fix dma unmapping of TX buffers for fragments · 9f11a0ab
      Thomas Petazzoni authored
      commit 8354491c upstream.
      
      Since commit 71ce391d ("net: mvpp2: enable proper per-CPU TX
      buffers unmapping"), we are not correctly DMA unmapping TX buffers for
      fragments.
      
      Indeed, the mvpp2_txq_inc_put() function only stores in the
      txq_cpu->tx_buffs[] array the physical address of the buffer to be
      DMA-unmapped when skb != NULL. In addition, when DMA-unmapping, we use
      skb_headlen(skb) to get the size to be unmapped. Both of this works fine
      for TX descriptors that are associated directly to a SKB, but not the
      ones that are used for fragments, with a NULL pointer as skb:
      
       - We have a NULL physical address when calling DMA unmap
       - skb_headlen(skb) crashes because skb is NULL
      
      This causes random crashes when fragments are used.
      
      To solve this problem, we need to:
      
       - Store the physical address of the buffer to be unmapped
         unconditionally, regardless of whether it is tied to a SKB or not.
      
       - Store the length of the buffer to be unmapped, which requires a new
         field.
      
      Instead of adding a third array to store the length of the buffer to be
      unmapped, and as suggested by David Miller, this commit refactors the
      tx_buffs[] and tx_skb[] arrays of 'struct mvpp2_txq_pcpu' into a
      separate structure 'mvpp2_txq_pcpu_buf', to which a 'size' field is
      added. Therefore, instead of having three arrays to allocate/free, we
      have a single one, which also improve data locality, reducing the
      impact on the CPU cache.
      
      Fixes: 71ce391d ("net: mvpp2: enable proper per-CPU TX buffers unmapping")
      Reported-by: default avatarRaphael G <raphael.glon@corp.ovh.com>
      Cc: Raphael G <raphael.glon@corp.ovh.com>
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9f11a0ab
    • Al Viro's avatar
      sg_write()/bsg_write() is not fit to be called under KERNEL_DS · d8572736
      Al Viro authored
      commit 128394ef upstream.
      
      Both damn things interpret userland pointers embedded into the payload;
      worse, they are actually traversing those.  Leaving aside the bad
      API design, this is very much _not_ safe to call with KERNEL_DS.
      Bail out early if that happens.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d8572736
    • Ben Hutchings's avatar
      kconfig/nconf: Fix hang when editing symbol with a long prompt · 7fb5a936
      Ben Hutchings authored
      commit 79e51b5c upstream.
      
      Currently it is impossible to edit the value of a config symbol with a
      prompt longer than (terminal width - 2) characters.  dialog_inputbox()
      calculates a negative x-offset for the input window and newwin() fails
      as this is invalid.  It also doesn't check for this failure, so it
      busy-loops calling wgetch(NULL) which immediately returns -1.
      
      The additions in the offset calculations also don't match the intended
      size of the window.
      
      Limit the window size and calculate the offset similarly to
      show_scroll_win().
      
      Fixes: 692d97c3 ("kconfig: new configuration interface (nconfig)")
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7fb5a936
    • Andy Grover's avatar
      target/user: Fix use-after-free of tcmu_cmds if they are expired · e321f384
      Andy Grover authored
      commit d0905ca7 upstream.
      
      Don't free the cmd in tcmu_check_expired_cmd, it's still referenced by
      an entry in our cmd_id->cmd idr. If userspace ever resumes processing,
      tcmu_handle_completions() will use the now-invalid cmd pointer.
      
      Instead, don't free cmd. It will be freed by tcmu_handle_completion() if
      userspace ever recovers, or tcmu_free_device if not.
      Reported-by: default avatarBryant G Ly <bgly@us.ibm.com>
      Tested-by: default avatarBryant G Ly <bgly@us.ibm.com>
      Signed-off-by: default avatarAndy Grover <agrover@redhat.com>
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e321f384
    • Segher Boessenkool's avatar
      powerpc: Convert cmp to cmpd in idle enter sequence · e5de1c72
      Segher Boessenkool authored
      commit 80f23935 upstream.
      
      PowerPC's "cmp" instruction has four operands. Normally people write
      "cmpw" or "cmpd" for the second cmp operand 0 or 1. But, frequently
      people forget, and write "cmp" with just three operands.
      
      With older binutils this is silently accepted as if this was "cmpw",
      while often "cmpd" is wanted. With newer binutils GAS will complain
      about this for 64-bit code. For 32-bit code it still silently assumes
      "cmpw" is what is meant.
      
      In this instance the code comes directly from ISA v2.07, including the
      cmp, but cmpd is correct. Backport to stable so that new toolchains can
      build old kernels.
      
      Fixes: 948cf67c ("powerpc: Add NAP mode support on Power7 in HV mode")
      Reviewed-by: default avatarVaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
      Signed-off-by: default avatarSegher Boessenkool <segher@kernel.crashing.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarJoel Stanley <joel@jms.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      e5de1c72
    • Geoff Levand's avatar
      powerpc/ps3: Fix system hang with GCC 5 builds · cadaba83
      Geoff Levand authored
      commit 6dff5b67 upstream.
      
      GCC 5 generates different code for this bootwrapper null check that
      causes the PS3 to hang very early in its bootup. This check is of
      limited value, so just get rid of it.
      Signed-off-by: default avatarGeoff Levand <geoff@infradead.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cadaba83
    • Al Viro's avatar
      nfs_write_end(): fix handling of short copies · 8a2bcaae
      Al Viro authored
      commit c0cf3ef5 upstream.
      
      What matters when deciding if we should make a page uptodate is
      not how much we _wanted_ to copy, but how much we actually have
      copied.  As it is, on architectures that do not zero tail on
      short copy we can leave uninitialized data in page marked uptodate.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8a2bcaae
    • Ilya Dryomov's avatar
      libceph: verify authorize reply on connect · b66e3126
      Ilya Dryomov authored
      commit 5c056fdc upstream.
      
      After sending an authorizer (ceph_x_authorize_a + ceph_x_authorize_b),
      the client gets back a ceph_x_authorize_reply, which it is supposed to
      verify to ensure the authenticity and protect against replay attacks.
      The code for doing this is there (ceph_x_verify_authorizer_reply(),
      ceph_auth_verify_authorizer_reply() + plumbing), but it is never
      invoked by the the messenger.
      
      AFAICT this goes back to 2009, when ceph authentication protocols
      support was added to the kernel client in 4e7a5dcd ("ceph:
      negotiate authentication protocol; implement AUTH_NONE protocol").
      
      The second param of ceph_connection_operations::verify_authorizer_reply
      is unused all the way down.  Pass 0 to facilitate backporting, and kill
      it in the next commit.
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b66e3126
    • Alan Stern's avatar
      PCI: Check for PME in targeted sleep state · edfe6a79
      Alan Stern authored
      commit 6496ebd7 upstream.
      
      One some systems, the firmware does not allow certain PCI devices to be put
      in deep D-states.  This can cause problems for wakeup signalling, if the
      device does not support PME# in the deepest allowed suspend state.  For
      example, Pierre reports that on his system, ACPI does not permit his xHCI
      host controller to go into D3 during runtime suspend -- but D3 is the only
      state in which the controller can generate PME# signals.  As a result, the
      controller goes into runtime suspend but never wakes up, so it doesn't work
      properly.  USB devices plugged into the controller are never detected.
      
      If the device relies on PME# for wakeup signals but is not capable of
      generating PME# in the target state, the PCI core should accurately report
      that it cannot do wakeup from runtime suspend.  This patch modifies the
      pci_dev_run_wake() routine to add this check.
      Reported-by: default avatarPierre de Villemereuil <flyos@mailoo.org>
      Tested-by: default avatarPierre de Villemereuil <flyos@mailoo.org>
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      CC: Lukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      edfe6a79
    • Jingkui Wang's avatar
      Input: drv260x - fix input device's parent assignment · 8db00756
      Jingkui Wang authored
      commit 5a8a6b89 upstream.
      
      We were assigning I2C bus controller instead of client as parent device.
      Besides being logically wrong, it messed up with devm handling of input
      device. As a result we were leaving input device and event node behind
      after rmmod-ing the driver, which lead to a kernel oops if one were to
      access the event node later.
      
      Let's remove the assignment and rely on devm_input_allocate_device() to
      set it up properly for us.
      Signed-off-by: default avatarJingkui Wang <jkwang@google.com>
      Fixes: 7132fe4f ("Input: drv260x - add TI drv260x haptics driver")
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8db00756
    • Andrey Utkin's avatar
      media: solo6x10: fix lockup by avoiding delayed register write · 44685f03
      Andrey Utkin authored
      commit 5fc4b067 upstream.
      
      This fixes a lockup at device probing which happens on some solo6010
      hardware samples. This is a regression introduced by commit e1ceb25a
      ("[media] SOLO6x10: remove unneeded register locking and barriers")
      
      The observed lockup happens in solo_set_motion_threshold() called from
      solo_motion_config().
      
      This extra "flushing" is not fundamentally needed for every write, but
      apparently the code in driver assumes such behaviour at last in some
      places.
      
      Actual fix was proposed by Hans Verkuil.
      
      Fixes: e1ceb25a ("[media] SOLO6x10: remove unneeded register locking and barriers")
      Signed-off-by: default avatarAndrey Utkin <andrey.utkin@corp.bluecherry.net>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      44685f03
    • Bart Van Assche's avatar
      IB/cma: Fix a race condition in iboe_addr_get_sgid() · 952a9f5a
      Bart Van Assche authored
      commit fba332b0 upstream.
      
      Code that dereferences the struct net_device ip_ptr member must be
      protected with an in_dev_get() / in_dev_put() pair. Hence insert
      calls to these functions.
      
      Fixes: commit 7b85627b ("IB/cma: IBoE (RoCE) IP-based GID addressing")
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Reviewed-by: default avatarMoni Shoua <monis@mellanox.com>
      Cc: Or Gerlitz <ogerlitz@mellanox.com>
      Cc: Roland Dreier <roland@purestorage.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      952a9f5a
    • Bart Van Assche's avatar
      IB/multicast: Check ib_find_pkey() return value · b7f73ada
      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>
      b7f73ada
    • Bart Van Assche's avatar
      IPoIB: Avoid reading an uninitialized member variable · 7b136921
      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>
      7b136921
    • Bart Van Assche's avatar
      IB/mad: Fix an array index check · 0de381ca
      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>
      0de381ca
    • Steven Rostedt (Red Hat)'s avatar
      fgraph: Handle a case where a tracer ignores set_graph_notrace · e945df4c
      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>
      e945df4c
    • Marcos Paulo de Souza's avatar
      platform/x86: asus-nb-wmi.c: Add X45U quirk · 88e41441
      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>
      88e41441
    • Steven Rostedt (Red Hat)'s avatar
      ftrace/x86_32: Set ftrace_stub to weak to prevent gcc from using short jumps to it · 2ef502e8
      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>
      2ef502e8
    • Jim Mattson's avatar
      kvm: nVMX: Allow L1 to intercept software exceptions (#BP and #OF) · 19aa9c14
      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>
      19aa9c14
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Don't lose hardware R/C bit updates in H_PROTECT · 129e4323
      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>
      129e4323
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Save/restore XER in checkpointed register state · ddf5718a
      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>
      ddf5718a
    • Konstantin Khlebnikov's avatar
      md/raid5: limit request size according to implementation limits · 1c8841c9
      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>
      1c8841c9
    • Josh Cartwright's avatar
      sc16is7xx: Drop bogus use of IRQF_ONESHOT · d78006d2
      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>
      d78006d2
    • Gerald Schaefer's avatar
      s390/vmlogrdr: fix IUCV buffer allocation · b988320d
      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>
      b988320d
    • Yves-Alexis Perez's avatar
      firmware: fix usermode helper fallback loading · 656c9abd
      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>
      656c9abd
    • Vineet Gupta's avatar
      ARC: mm: arc700: Don't assume 2 colours for aliasing VIPT dcache · 429a533a
      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>
      429a533a
    • Wei Fang's avatar
      scsi: avoid a permanent stop of the scsi device's request queue · dbb67e1d
      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>
      dbb67e1d
    • Steffen Maier's avatar
      scsi: zfcp: fix rport unblock race with LUN recovery · 565ae61d
      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>
      565ae61d