From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Petr Kulhavy <petr@barix.com>, vinod.koul@intel.com
Cc: dan.j.williams@intel.com, dmaengine@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
trivial@kernel.org,
Russell King - ARM Linux <linux@arm.linux.org.uk>
Subject: Re: [PATCH] EDMA: TI: fixed memory leak when terminating running transfers
Date: Tue, 24 Mar 2015 14:55:05 +0200 [thread overview]
Message-ID: <55115EA9.5020000@ti.com> (raw)
In-Reply-To: <1427122812-22657-1-git-send-email-petr@barix.com>
On 03/23/2015 05:00 PM, Petr Kulhavy wrote:
> 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.
It is another question if it is really correct to remove the the currently
running desc from the issued list in edma_execute().
Based on what I have seen some drivers using virt-dma does this while others not.
Russel, do you have any advice on this?
Will this work for you to fix the leak:
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 7b65633f495e..ea8544481245 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -162,7 +162,6 @@ static void edma_execute(struct edma_chan *echan)
echan->edesc = NULL;
return;
}
- list_del(&vdesc->node);
echan->edesc = to_edma_desc(&vdesc->tx);
}
@@ -760,6 +759,7 @@ static void edma_callback(unsigned ch_num, u16 ch_status, void *data)
dev_dbg(dev, "Transfer complete, stopping channel %d\n", ch_num);
edesc->residue = 0;
edma_stop(echan->ch_num);
+ list_del(&edesc->vdesc.node);
vchan_cookie_complete(&edesc->vdesc);
edma_execute(echan);
} else {
> 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.
>
> Signed-off-by: Petr Kulhavy <petr@barix.com>
> ---
> drivers/dma/edma.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index 276157f..1465610 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -260,6 +260,14 @@ static int edma_terminate_all(struct dma_chan *chan)
> */
> if (echan->edesc) {
> int cyclic = echan->edesc->cyclic;
> +
> + /*
> + * free the running request descriptor
> + * since it is on none of the vchan lists
> + * desc_submitted, desc_issued, desc_completed
> + */
> + kfree(echan->edesc);
If we do this I would prefer to have:
edma_desc_free(&echan->edesc->vdesc);
> +
> echan->edesc = NULL;
> edma_stop(echan->ch_num);
> /* Move the cyclic channel back to default queue */
>
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Petr Kulhavy <petr@barix.com>, <vinod.koul@intel.com>
Cc: <dan.j.williams@intel.com>, <dmaengine@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-omap@vger.kernel.org>,
<trivial@kernel.org>,
Russell King - ARM Linux <linux@arm.linux.org.uk>
Subject: Re: [PATCH] EDMA: TI: fixed memory leak when terminating running transfers
Date: Tue, 24 Mar 2015 14:55:05 +0200 [thread overview]
Message-ID: <55115EA9.5020000@ti.com> (raw)
In-Reply-To: <1427122812-22657-1-git-send-email-petr@barix.com>
On 03/23/2015 05:00 PM, Petr Kulhavy wrote:
> 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.
It is another question if it is really correct to remove the the currently
running desc from the issued list in edma_execute().
Based on what I have seen some drivers using virt-dma does this while others not.
Russel, do you have any advice on this?
Will this work for you to fix the leak:
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 7b65633f495e..ea8544481245 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -162,7 +162,6 @@ static void edma_execute(struct edma_chan *echan)
echan->edesc = NULL;
return;
}
- list_del(&vdesc->node);
echan->edesc = to_edma_desc(&vdesc->tx);
}
@@ -760,6 +759,7 @@ static void edma_callback(unsigned ch_num, u16 ch_status, void *data)
dev_dbg(dev, "Transfer complete, stopping channel %d\n", ch_num);
edesc->residue = 0;
edma_stop(echan->ch_num);
+ list_del(&edesc->vdesc.node);
vchan_cookie_complete(&edesc->vdesc);
edma_execute(echan);
} else {
> 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.
>
> Signed-off-by: Petr Kulhavy <petr@barix.com>
> ---
> drivers/dma/edma.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index 276157f..1465610 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -260,6 +260,14 @@ static int edma_terminate_all(struct dma_chan *chan)
> */
> if (echan->edesc) {
> int cyclic = echan->edesc->cyclic;
> +
> + /*
> + * free the running request descriptor
> + * since it is on none of the vchan lists
> + * desc_submitted, desc_issued, desc_completed
> + */
> + kfree(echan->edesc);
If we do this I would prefer to have:
edma_desc_free(&echan->edesc->vdesc);
> +
> echan->edesc = NULL;
> edma_stop(echan->ch_num);
> /* Move the cyclic channel back to default queue */
>
--
Péter
next prev parent reply other threads:[~2015-03-24 12:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-23 15:00 [PATCH] EDMA: TI: fixed memory leak when terminating running transfers Petr Kulhavy
2015-03-24 12:55 ` Peter Ujfalusi [this message]
2015-03-24 12:55 ` Peter Ujfalusi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55115EA9.5020000@ti.com \
--to=peter.ujfalusi@ti.com \
--cc=dan.j.williams@intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=petr@barix.com \
--cc=trivial@kernel.org \
--cc=vinod.koul@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.