Re: [PATCH net-next v2 2/2] net: wwan: qcom_bam_dmux: Assign restricted DMA pool to remote processor

[Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>]

On 21-09-2026 08:33 am, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] wwan: qcom_bam_dmux: probe error path reclaims DMA pool before disabling IRQ
> --
>
> commit 4ad4e0793e663284df130f5d11d5a4f0bb1754cc
> Author: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
>
> net: wwan: qcom_bam_dmux: Assign restricted DMA pool to remote processor
>
> This commit introduces restricted DMA pool support to the BAM-DMUX WWAN
> network driver for Qualcomm SoCs. It assigns the pool to local and remote
> execution environments during probe and reclaims it on driver removal
> or probe failure.
>
>> diff --git a/drivers/net/wwan/qcom_bam_dmux.c b/drivers/net/wwan/qcom_bam_dmux.c
>> index cc6ace8d64371..c81e668d4e961 100644
>> --- a/drivers/net/wwan/qcom_bam_dmux.c
>> +++ b/drivers/net/wwan/qcom_bam_dmux.c
> [ ... ]
>
>> @@ -845,6 +938,7 @@ static int bam_dmux_probe(struct platform_device *pdev)
>>   err_disable_pm:
>>   	pm_runtime_disable(dev);
>>   	pm_runtime_dont_use_autosuspend(dev);
>> +	bam_dmux_reclaim_dma_pool(dmux);
>>   	return ret;
>>   }
> [Severity: High]
> Could reclaiming the DMA pool here lead to an XPU violation and resource
> leak if an interrupt fires concurrently?
>
> If probe fails late (for example, if irq_get_irqchip_state() returns an
> error), the code jumps to the err_disable_pm label. At this point, the
> pc_irq has already been requested via devm_request_threaded_irq() and
> is active.
>
> If the remote processor triggers this interrupt, the threaded handler
> (bam_dmux_pc_irq) could be executing bam_dmux_power_on() while we are
> calling bam_dmux_reclaim_dma_pool().
>
> This concurrent execution would cause the DMA pool to be reclaimed
> while the BAM DMA controller is actively using it, resulting in a system
> crash. Furthermore, when devres eventually frees the IRQ, any DMA
> channels or mappings allocated by the racing handler would leak because
> bam_dmux_power_off() is not called in this error path.

Makes sense. I plan to reuse bam_dmux_remove() for this, which disables the IRQ
and releases the DMA channels, mappings and any registered netdevs before
reclaiming the pool, in the same order as a regular remove. I will test
this and include it in the next revision.

Thanks,
Vishnu