Hi,

I have found a memory leak in the TI EDMA driver, which happens every time a DMA transfer is performed. The leak is in kernel 3.17, however the same problem seems to exist also in 3.19.

In particular this was found on our custom TI AM1808 based hardware while accessing the MMC/SD card interface. When extensively using the SD card (e.g. downloading files to it) you can virtually see the "SUnreclaim" memory in /proc/meminfo growing few kB every few seconds. After few days of operation a device with 128MB of RAM renders unusable (lack of memory, system slow, processes being killed, etc.), the unreclaimed SLAB memory is over 50MB.

The kernel memory leak debug mechanism revealed the leak to happen in edma_prep_slave_sg(), however the same pattern repeats all over the edma.c file (see below).

unreferenced object 0xc5abe3c0 (size 128):
  comm "mmcqd/0", pid 1099, jiffies 4294948151 (age 5865.330s)
  hex dump (first 32 bytes):
    b7 02 00 00 03 00 00 00 00 00 00 00 80 bb 81 c7  ................
    18 b4 23 c0 00 00 00 00 00 00 00 00 00 00 00 00  ..#.............
  backtrace:
    [<c023c8d0>] edma_prep_slave_sg+0x98/0x344
    [<c030b350>] mmc_davinci_request+0x3d4/0x53c
    [<c02f86c8>] mmc_start_request+0xc4/0xe8
    [<c02f9654>] mmc_start_req+0x18c/0x354
    [<c0307c84>] mmc_blk_issue_rw_rq+0xc0/0xc94
    [<c0308a0c>] mmc_blk_issue_rq+0x1b4/0x4f4
    [<c0309648>] mmc_queue_thread+0xb8/0x168
    [<c0034930>] kthread+0xb4/0xd0
    [<c0009730>] ret_from_fork+0x14/0x24
    [<ffffffff>] 0xffffffff


The structure edma_desc is allocated using kzalloc in the edma_prep_slave_sg() function, then a pointer to a member of its substructure (dma_async_tx_descriptor) is returned. Therefore the edma_desc structure cannot be freed since the allocated address is nowhere stored and therefore lost. I also haven't found that the dma_async_tx_descriptor would be freed, but not sure whether the kernel does this in some other place?

Basically every time there is edma_prep_slave_sg 128 bytes of memory is allocated but it's never freed. I'm not sure what is the right way to fix this issue, but it seems to me that the driver needs a more significant change to keep e.g. a pool of resources which is reused and eventually freed, like some other EDMA drivers do.

Could you please advise what to do.

Thank you
Petr


--
Petr Kulhavy, MSc
System Architect
Barix AG, Zürich, Switzerland


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to