1. 23 Mar, 2015 9 commits
    • Alexander Sverdlin's avatar
      spi: pl022: Fix race in giveback() leading to driver lock-up · b973ad9a
      Alexander Sverdlin authored
      commit cd6fa8d2 upstream.
      
      Commit fd316941 ("spi/pl022: disable port when unused") introduced a race,
      which leads to possible driver lock up (easily reproducible on SMP).
      
      The problem happens in giveback() function where the completion of the transfer
      is signalled to SPI subsystem and then the HW SPI controller is disabled. Another
      transfer might be setup in between, which brings driver in locked-up state.
      
      Exact event sequence on SMP:
      
      core0                                   core1
      
                                              => pump_transfers()
                                              /* message->state == STATE_DONE */
                                                => giveback()
                                                  => spi_finalize_current_message()
      
      => pl022_unprepare_transfer_hardware()
      => pl022_transfer_one_message
        => flush()
        => do_interrupt_dma_transfer()
          => set_up_next_transfer()
          /* Enable SSP, turn on interrupts */
          writew((readw(SSP_CR1(pl022->virtbase)) |
                 SSP_CR1_MASK_SSE), SSP_CR1(pl022->virtbase));
      
      ...
      
      => pl022_interrupt_handler()
        => readwriter()
      
                                              /* disable the SPI/SSP operation */
                                              => writew((readw(SSP_CR1(pl022->virtbase)) &
                                                        (~SSP_CR1_MASK_SSE)), SSP_CR1(pl022->virtbase));
      
      Lockup! SPI controller is disabled and the data will never be received. Whole
      SPI subsystem is waiting for transfer ACK and blocked.
      
      So, only signal transfer completion after disabling the controller.
      
      Fixes: fd316941 (spi/pl022: disable port when unused)
      Signed-off-by: default avatarAlexander Sverdlin <alexander.sverdlin@nokia.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b973ad9a
    • Juergen Gross's avatar
      xen/events: avoid NULL pointer dereference in dom0 on large machines · a922ccc2
      Juergen Gross authored
      commit 85e40b05 upstream.
      
      Using the pvops kernel a NULL pointer dereference was detected on a
      large machine (144 processors) when booting as dom0 in
      evtchn_fifo_unmask() during assignment of a pirq.
      
      The event channel in question was the first to need a new entry in
      event_array[] in events_fifo.c. Unfortunately xen_irq_info_pirq_setup()
      is called with evtchn being 0 for a new pirq and the real event channel
      number is assigned to the pirq only during __startup_pirq().
      
      It is mandatory to call xen_evtchn_port_setup() after assigning the
      event channel number to the pirq to make sure all memory needed for the
      event channel is allocated.
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a922ccc2
    • Brian King's avatar
      bnx2x: Force fundamental reset for EEH recovery · ef3112c8
      Brian King authored
      commit da293700 upstream.
      
      EEH recovery for bnx2x based adapters is not reliable on all Power
      systems using the default hot reset, which can result in an
      unrecoverable EEH error. Forcing the use of fundamental reset
      during EEH recovery fixes this.
      Signed-off-by: default avatarBrian King <brking@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ef3112c8
    • Tejun Heo's avatar
      workqueue: fix hang involving racing cancel[_delayed]_work_sync()'s for PREEMPT_NONE · 1264f1e3
      Tejun Heo authored
      commit 8603e1b3 upstream.
      
      cancel[_delayed]_work_sync() are implemented using
      __cancel_work_timer() which grabs the PENDING bit using
      try_to_grab_pending() and then flushes the work item with PENDING set
      to prevent the on-going execution of the work item from requeueing
      itself.
      
      try_to_grab_pending() can always grab PENDING bit without blocking
      except when someone else is doing the above flushing during
      cancelation.  In that case, try_to_grab_pending() returns -ENOENT.  In
      this case, __cancel_work_timer() currently invokes flush_work().  The
      assumption is that the completion of the work item is what the other
      canceling task would be waiting for too and thus waiting for the same
      condition and retrying should allow forward progress without excessive
      busy looping
      
      Unfortunately, this doesn't work if preemption is disabled or the
      latter task has real time priority.  Let's say task A just got woken
      up from flush_work() by the completion of the target work item.  If,
      before task A starts executing, task B gets scheduled and invokes
      __cancel_work_timer() on the same work item, its try_to_grab_pending()
      will return -ENOENT as the work item is still being canceled by task A
      and flush_work() will also immediately return false as the work item
      is no longer executing.  This puts task B in a busy loop possibly
      preventing task A from executing and clearing the canceling state on
      the work item leading to a hang.
      
      task A			task B			worker
      
      						executing work
      __cancel_work_timer()
        try_to_grab_pending()
        set work CANCELING
        flush_work()
          block for work completion
      						completion, wakes up A
      			__cancel_work_timer()
      			while (forever) {
      			  try_to_grab_pending()
      			    -ENOENT as work is being canceled
      			  flush_work()
      			    false as work is no longer executing
      			}
      
      This patch removes the possible hang by updating __cancel_work_timer()
      to explicitly wait for clearing of CANCELING rather than invoking
      flush_work() after try_to_grab_pending() fails with -ENOENT.
      
      Link: http://lkml.kernel.org/g/20150206171156.GA8942@axis.com
      
      v3: bit_waitqueue() can't be used for work items defined in vmalloc
          area.  Switched to custom wake function which matches the target
          work item and exclusive wait and wakeup.
      
      v2: v1 used wake_up() on bit_waitqueue() which leads to NULL deref if
          the target bit waitqueue has wait_bit_queue's on it.  Use
          DEFINE_WAIT_BIT() and __wake_up_bit() instead.  Reported by Tomeu
          Vizoso.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarRabin Vincent <rabin.vincent@axis.com>
      Cc: Tomeu Vizoso <tomeu.vizoso@gmail.com>
      Tested-by: default avatarJesper Nilsson <jesper.nilsson@axis.com>
      Tested-by: default avatarRabin Vincent <rabin.vincent@axis.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      1264f1e3
    • Jason Low's avatar
      cpuset: Fix cpuset sched_relax_domain_level · 6efeedf2
      Jason Low authored
      commit 283cb41f upstream.
      
      The cpuset.sched_relax_domain_level can control how far we do
      immediate load balancing on a system. However, it was found on recent
      kernels that echo'ing a value into cpuset.sched_relax_domain_level
      did not reduce any immediate load balancing.
      
      The reason this occurred was because the update_domain_attr_tree() traversal
      did not update for the "top_cpuset". This resulted in nothing being changed
      when modifying the sched_relax_domain_level parameter.
      
      This patch is able to address that problem by having update_domain_attr_tree()
      allow updates for the root in the cpuset traversal.
      
      Fixes: fc560a26 ("cpuset: replace cpuset->stack_list with cpuset_for_each_descendant_pre()")
      Signed-off-by: default avatarJason Low <jason.low2@hp.com>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Tested-by: default avatarSerge Hallyn <serge.hallyn@canonical.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6efeedf2
    • Maxime Ripard's avatar
      mtd: nand: pxa3xx: Fix PIO FIFO draining · 41ba1af9
      Maxime Ripard authored
      commit 8dad0386 upstream.
      
      The NDDB register holds the data that are needed by the read and write
      commands.
      
      However, during a read PIO access, the datasheet specifies that after each 32
      bytes read in that register, when BCH is enabled, we have to make sure that the
      RDDREQ bit is set in the NDSR register.
      
      This fixes an issue that was seen on the Armada 385, and presumably other mvebu
      SoCs, when a read on a newly erased page would end up in the driver reporting a
      timeout from the NAND.
      Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Reviewed-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Acked-by: default avatarEzequiel Garcia <ezequiel.garcia@free-electrons.com>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      41ba1af9
    • Torsten Fleischer's avatar
      spi: atmel: Fix interrupt setup for PDC transfers · 293a6372
      Torsten Fleischer authored
      commit 76e1d14b upstream.
      
      Additionally to the current DMA transfer the PDC allows to set up a next DMA
      transfer. This is useful for larger SPI transfers.
      
      The driver currently waits for ENDRX as end of the transfer. But ENDRX is set
      when the current DMA transfer is done (RCR = 0), i.e. it doesn't include the
      next DMA transfer.
      Thus a subsequent SPI transfer could be started although there is currently a
      transfer in progress. This can cause invalid accesses to the SPI slave devices
      and to SPI transfer errors.
      
      This issue has been observed on a hardware with a M25P128 SPI NOR flash.
      
      So instead of ENDRX we should wait for RXBUFF. This flag is set if there is
      no more DMA transfer in progress (RCR = RNCR = 0).
      Signed-off-by: default avatarTorsten Fleischer <torfl6749@gmail.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      293a6372
    • Andy Shevchenko's avatar
      spi: dw: revisit FIFO size detection again · e44ea338
      Andy Shevchenko authored
      commit 9d239d35 upstream.
      
      The commit d297933c (spi: dw: Fix detecting FIFO depth) tries to fix the
      logic of the FIFO detection based on the description on the comments. However,
      there is a slight difference between numbers in TX Level and TX FIFO size.
      
      So, by specification the FIFO size would be in a range 2-256 bytes. From TX
      Level prospective it means we can set threshold in the range 0-(FIFO size - 1)
      bytes. Hence there are currently two issues:
        a) FIFO size 2 bytes is actually skipped since TX Level is 1 bit and could be
           either 0 or 1 byte;
        b) FIFO size is incorrectly decreased by 1 which already done by meaning of
           TX Level register.
      
      This patch fixes it eventually right.
      
      Fixes: d297933c (spi: dw: Fix detecting FIFO depth)
      Reviewed-by: default avatarAxel Lin <axel.lin@ingics.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e44ea338
    • Sasha Levin's avatar
      PCI: Don't read past the end of sysfs "driver_override" buffer · d81b1275
      Sasha Levin authored
      commit 4efe874a upstream.
      
      When printing the driver_override parameter when it is 4095 and 4094 bytes
      long, the printing code would access invalid memory because we need count+1
      bytes for printing.
      
      Fixes: 782a985d ("PCI: Introduce new device binding path using pci_dev.driver_override")
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      CC: Alexander Graf <agraf@suse.de>
      CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d81b1275
  2. 20 Mar, 2015 4 commits
  3. 18 Mar, 2015 27 commits