Re: [PATCH 1/2] dma-mapping: make dma_max_mapping_size() return 0 for no DMA capability

[John Garry <john.g.garry@oracle.com>]

On 29/06/2026 11:11, Robin Murphy wrote:
> On 29/06/2026 9:53 am, John Garry wrote:
>> For when a device is not DMA capable, the max mapping size would be 0, so
>> make dma_max_mapping_size() reflect that.
> 
> Seems logical.
> 
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>

Thanks, but sashiko has been reviewing this and has a few things to say.

I don't know how it chooses recipients.

On 29/06/2026 10:10, sashiko-bot@kernel.org wrote:
 >>
 >> +	if (!dev->dma_mask)
 >> +		return 0;
 > [Severity: High]
 > Could this new return value of 0 cause a division by zero in callers that
 > expect a strictly positive maximum mapping size?
 >
 > For instance, in drivers/accel/amdxdna/amdxdna_cbuf.c:amdxdna_cbuf_map(),
 > the returned size is used directly as a divisor:
 >
 >          max_seg = min_t(size_t, UINT_MAX, dma_max_mapping_size(dev));
 >          n_entries = (cbuf->node.size + max_seg - 1) / max_seg;

Later in amdxdna_cbuf_map() we call dma_map_resource() (-> 
dma_map_phys()) and this would fail and WARN for !dev->dma_mask. Indeed 
amdxdna_cbuf_map() is used as a callback for .map_dma_buf, so highly 
unrealistic to have !dev->dma_mask ever.

 >
 > If a device lacking a dma_mask maps the attachment, max_seg becomes 0,
 > which would result in an immediate kernel panic.
 >
 > Additionally, could this cause invalid zero-sized block layer queue 
limits
 > in MMC drivers? In drivers/mmc/host/bcm2835.c:bcm2835_add_host(), the
 > return value clamps max_req_size:
 >
 >          mmc->max_req_size = min_t(size_t, 524288, 
dma_max_mapping_size(dev));

bcm2835.c is a platform device driver, and platform devices have their 
dev->dma_mask set in setup_pdev_dma_masks()

Indeed, that driver does have a non-DMA mode of operation, but that 
looks to be selected independent of whether dev->dma_mask is set.

 >
 > If the device lacks DMA support, max_req_size becomes 0, which propagates
 > to the block layer and can trigger panics when processing requests.

All other users of dma_max_mapping_size() are drivers for real/virtio 
HW, so should be no issues.

> 
>> Signed-off-by: John Garry <john.g.garry@oracle.com>
>> ---
>>   kernel/dma/mapping.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
>> index 4fe04669e5e66..7e576e5c6b8be 100644
>> --- a/kernel/dma/mapping.c
>> +++ b/kernel/dma/mapping.c
>> @@ -979,6 +979,9 @@ size_t dma_max_mapping_size(struct device *dev)
>>       const struct dma_map_ops *ops = get_dma_ops(dev);
>>       size_t size = SIZE_MAX;
>> +    if (!dev->dma_mask)
>> +        return 0;
>> +
>>       if (dma_map_direct(dev, ops))
>>           size = dma_direct_max_mapping_size(dev);
>>       else if (use_dma_iommu(dev))
>