Re: [PATCH 3.9-stable] dma: tegra: avoid channel lock up after free

Re: [PATCH 3.9-stable] dma: tegra: avoid channel lock up after free

[Dmitry Osipenko]

10.07.2013 16:44, Jonghwan Choi пишет:
> From: Dmitry Osipenko <digetx@gmail.com>
> 
> This patch looks like it should be in the 3.9-stable tree, should we apply
> it?
> 
> ------------------
> 
> From: "Dmitry Osipenko <digetx@gmail.com>"
> 
> commit 7bdc1e272a471062e8f310137c896e2355b46d13 upstream
> 
> Lock scenario: Channel 1 was allocated and prepared as slave_sg, used and freed.
> Now preparation of cyclic dma on channel 1 will fail with err "DMA configuration
> conflict" because tdc->isr_handler still setted to handle_once_dma_done.
> 
> This happens because tegra_dma_abort_all() won't be called on channel freeing
> if pending list is empty and channel not busy. We need to clear isr_handler
> on channel freeing to avoid locking.
> 
> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
> Acked-by: Stephen Warren <swarren@nvidia.com>
> Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
> Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
> ---
>  drivers/dma/tegra20-apb-dma.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
> index fcee27e..d464225 100644
> --- a/drivers/dma/tegra20-apb-dma.c
> +++ b/drivers/dma/tegra20-apb-dma.c
> @@ -1189,6 +1189,7 @@ static void tegra_dma_free_chan_resources(struct dma_chan *dc)
>  	list_splice_init(&tdc->free_dma_desc, &dma_desc_list);
>  	INIT_LIST_HEAD(&tdc->cb_desc);
>  	tdc->config_init = false;
> +	tdc->isr_handler = NULL;
>  	spin_unlock_irqrestore(&tdc->lock, flags);
>  
>  	while (!list_empty(&dma_desc_list)) {
> 

Currently the only dma user in upstream is sound. This should be more actual
after fixing serial tegra driver which has obvious deadlock issue and probably
some other issue that prevents correct data transfer (not possible to complete
large file transfer via bluetooth). I have fix for deadlock but data transfer
breakage looks much more difficult and I'm not fully sure yet that it's serial
issue.