1. 27 10月, 2015 3 次提交
  2. 14 10月, 2015 18 次提交
  3. 05 8月, 2015 1 次提交
  4. 07 5月, 2015 1 次提交
  5. 01 4月, 2015 1 次提交
  6. 31 3月, 2015 1 次提交
    • P
      dmaengine: edma: fix memory leak when terminating running transfers · 5ca9e7ce
      Petr Kulhavy 提交于
      If edma_terminate_all() was called while a transfer was running (i.e. after
      edma_execute() but before edma_callback()) the echan->edesc was not freed.
      
      This was due to the fact that a running transfer is on none of the
      vchan lists: desc_submitted, desc_issued, desc_completed (edma_execute()
      removes it from the desc_issued list), so the vchan_dma_desc_free_list()
      called at the end of edma_terminate_all() didn't find it and didn't free it.
      
      This bug was found on an AM1808 based hardware (very similar to da850evm,
      however using the second MMC/SD controller), where intense operations on the SD
      card wasted the device 128MB RAM within a couple of days.
      
      Peter Ujfalusi:
      The issue is even more severe since it affects cyclic (audio) transfers as
      well. In this case starting/stopping audio will results memory leak.
      Signed-off-by: NPetr Kulhavy <petr@barix.com>
      Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      CC: <stable@vger.kernel.org>
      CC: <linux-omap@vger.kernel.org>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      5ca9e7ce
  7. 16 2月, 2015 1 次提交
  8. 22 12月, 2014 3 次提交
  9. 06 11月, 2014 1 次提交
  10. 20 10月, 2014 1 次提交
  11. 15 10月, 2014 1 次提交
    • S
      dmaengine: edma: check for echan->edesc => NULL in edma_dma_pause() · 639559ad
      Sebastian Andrzej Siewior 提交于
      I added book keeping of whether or not the 8250-dma driver has an RX
      transfer pending or not so we don't BUG here if it calls
      dmaengine_pause() on a channel which has not a pending transfer. Guess
      what, this is not enough.
      The following can be triggered with a busy RX channel and hackbench in
      background:
      - DMA transfer completes. The callback is delayed via
        vchan_cookie_complete() into a tasklet so it das not happen asap.
      - hackbench keeps the system busy so the tasklet does not run "soon".
      - the UART collected enough data and generates an "timeout"-interrupt.
        Since 8250-dma *thinks* the DMA-transfer is still pending it tries to
        cancel it via invoking dmaengine_pause() first. This causes the segfault
        because echan->edesc is NULL now that the transfer completed (however
        the callback did not run yet).
      
      With this patch we don't BUG in the scenario described.
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      639559ad
  12. 04 8月, 2014 1 次提交
  13. 31 7月, 2014 2 次提交
  14. 28 7月, 2014 3 次提交
  15. 05 7月, 2014 1 次提交
  16. 30 4月, 2014 1 次提交