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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Fri, May 08, 2026 at 01:16:25PM +0100, Robin Murphy wrote:
> 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.

I'm saying I think the new expression still has a false positive for
the common case of map_phys with ZONE_DEVICE P2P, and I don't want to
see debugging logging for normal as-designed scenarios in map_phys.

So we either need to narrow the expression further somehow, or leave
it in map_resource which has fewer users and doesn't accept
ZONE_DEVICE anyhow.

Jason