2020-04-25 12:53:55

by Xiyu Yang

[permalink] [raw]
Subject: [PATCH] ASoC: davinci-mcasp: Fix dma_chan refcnt leak when getting dma type

davinci_mcasp_get_dma_type() invokes dma_request_chan(), which returns a
reference of the specified dma_chan object to "chan" with increased
refcnt.

When davinci_mcasp_get_dma_type() returns, local variable "chan" becomes
invalid, so the refcount should be decreased to keep refcount balanced.

The reference counting issue happens in one exception handling path of
davinci_mcasp_get_dma_type(). When chan device is NULL, the function
forgets to decrease the refcnt increased by dma_request_chan(), causing
a refcnt leak.

Fix this issue by calling dma_release_channel() when chan device is
NULL.

Signed-off-by: Xiyu Yang <[email protected]>
Signed-off-by: Xin Tan <[email protected]>
---
sound/soc/ti/davinci-mcasp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/sound/soc/ti/davinci-mcasp.c b/sound/soc/ti/davinci-mcasp.c
index 734ffe925c4d..7a7db743dc5b 100644
--- a/sound/soc/ti/davinci-mcasp.c
+++ b/sound/soc/ti/davinci-mcasp.c
@@ -1896,8 +1896,10 @@ static int davinci_mcasp_get_dma_type(struct davinci_mcasp *mcasp)
PTR_ERR(chan));
return PTR_ERR(chan);
}
- if (WARN_ON(!chan->device || !chan->device->dev))
+ if (WARN_ON(!chan->device || !chan->device->dev)) {
+ dma_release_channel(chan);
return -EINVAL;
+ }

if (chan->device->dev->of_node)
ret = of_property_read_string(chan->device->dev->of_node,
--
2.7.4


2020-04-28 08:17:48

by Peter Ujfalusi

[permalink] [raw]
Subject: Re: [PATCH] ASoC: davinci-mcasp: Fix dma_chan refcnt leak when getting dma type



On 25/04/2020 15.48, Xiyu Yang wrote:
> davinci_mcasp_get_dma_type() invokes dma_request_chan(), which returns a
> reference of the specified dma_chan object to "chan" with increased
> refcnt.
>
> When davinci_mcasp_get_dma_type() returns, local variable "chan" becomes
> invalid, so the refcount should be decreased to keep refcount balanced.
>
> The reference counting issue happens in one exception handling path of
> davinci_mcasp_get_dma_type(). When chan device is NULL, the function
> forgets to decrease the refcnt increased by dma_request_chan(), causing
> a refcnt leak.
>
> Fix this issue by calling dma_release_channel() when chan device is
> NULL.
>
> Signed-off-by: Xiyu Yang <[email protected]>
> Signed-off-by: Xin Tan <[email protected]>
> ---
> sound/soc/ti/davinci-mcasp.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/sound/soc/ti/davinci-mcasp.c b/sound/soc/ti/davinci-mcasp.c
> index 734ffe925c4d..7a7db743dc5b 100644
> --- a/sound/soc/ti/davinci-mcasp.c
> +++ b/sound/soc/ti/davinci-mcasp.c
> @@ -1896,8 +1896,10 @@ static int davinci_mcasp_get_dma_type(struct davinci_mcasp *mcasp)
> PTR_ERR(chan));
> return PTR_ERR(chan);
> }
> - if (WARN_ON(!chan->device || !chan->device->dev))
> + if (WARN_ON(!chan->device || !chan->device->dev)) {
> + dma_release_channel(chan);
> return -EINVAL;
> + }

If we get a channel then chan->device and chan->device->dev never NULL,
it can not be.
I think the reason why this is here is that static checkers tends to
scream at us.

Acked-by: Peter Ujfalusi <[email protected]>

>
> if (chan->device->dev->of_node)
> ret = of_property_read_string(chan->device->dev->of_node,
>

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

2020-04-28 15:43:10

by Mark Brown

[permalink] [raw]
Subject: Re: [PATCH] ASoC: davinci-mcasp: Fix dma_chan refcnt leak when getting dma type

On Sat, 25 Apr 2020 20:48:35 +0800, Xiyu Yang wrote:
> davinci_mcasp_get_dma_type() invokes dma_request_chan(), which returns a
> reference of the specified dma_chan object to "chan" with increased
> refcnt.
>
> When davinci_mcasp_get_dma_type() returns, local variable "chan" becomes
> invalid, so the refcount should be decreased to keep refcount balanced.
>
> [...]

Applied to

https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.7

Thanks!

[1/1] ASoC: davinci-mcasp: Fix dma_chan refcnt leak when getting dma type
commit: a697ae6ea56e23397341b027098c1b11d9ab13da

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark