summaryrefslogtreecommitdiffstats
path: root/drivers/acpi
diff options
context:
space:
mode:
authorPetr Kulhavy <petr@barix.com>2015-03-27 13:35:51 +0200
committerVinod Koul <vinod.koul@intel.com>2015-03-30 23:17:08 +0530
commit5ca9e7ce6eebec53362ff779264143860ccf68cd (patch)
tree94ad7f41a22047616a192c241459b2090213adb1 /drivers/acpi
parentca76683930a1c6acb8dd22867eca2bedaab998e3 (diff)
downloadlinux-stable-5ca9e7ce6eebec53362ff779264143860ccf68cd.tar.gz
linux-stable-5ca9e7ce6eebec53362ff779264143860ccf68cd.tar.bz2
linux-stable-5ca9e7ce6eebec53362ff779264143860ccf68cd.zip
dmaengine: edma: fix memory leak when terminating running transfers
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: Petr Kulhavy <petr@barix.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> CC: <stable@vger.kernel.org> CC: <linux-omap@vger.kernel.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Diffstat (limited to 'drivers/acpi')
0 files changed, 0 insertions, 0 deletions