Re: [PATCH] dma-mapping: remove bogus test for pfn_valid from dma_map_resource

[Robin Murphy <robin.murphy@arm.com>]

On 2026-05-08 12:31 pm, Jason Gunthorpe wrote:
> On Fri, May 08, 2026 at 06:01:01PM +0800, Jianpeng Chang wrote:
>>> As I said last time, I think pfn_valid() && !PageReserved(pfn_to_page())
>>> would be enough for what we want here, although now it's strictly under
>>> CONFIG_DMA_API_DEBUG, perhaps the overhead of memblock_is_map_memory()
>>> might be less of an issue. Either way though, now that it's all
>>> channelled through the single dma_map_phys() path, it would probably
>>> make sense to consolidate any MMIO sanity-checking into
>>> dma_debug_map_phys() anyway :/
> 
>> Thanks for the suggestion. Move the check into debug_dma_map_phys() is
>> indeed better, and I will replace pfn_valid() with pfn_valid() &&
>> !PageReserved() as you suggested.
> 
> I'm not sure that is right. IIRC pfn_valid() is true for ZONE_DEVICE
> P2P pages that are used with map_phys but never with map_resource.
> 
> PageReserved isn't enough to fix it.

It fixes the false-positive on non-reserved pages, which is the 
important thing. Yes, we'll get false-negatives on reserved ZONE_DEVICE 
pages and similar, but that's still an improvement over getting 
false-negatives on _everything_ by not checking at all. Realistically, 
dma-debug can never be exhaustive and 100% accurate, but there's still 
value in catching as much obvious misuse as is straightforward to do.

In the long term, perhaps we could add some kind of "DMAable 
memory/P2Pable MMIO/neither" attribute to our wishlist of physical 
address range properties along with CoCO shared/private, such that 
dma_map_phys() could then do the right thing all by itself and we 
wouldn't even need DMA_ATTR_MMIO any more...

Thanks,
Robin.