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

[Robin Murphy]

On 2026-05-08 4:18 pm, Jason Gunthorpe wrote:
> 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.

But surely anything with a ZONE_DEVICE page is "memory" to the degree 
that mapping it with DMA_ATTR_MMIO would be wrong, no? However, IIRC 
ZONE_DEVICE pages _are_ reserved, so still wouldn't warn whether we'd 
like it or not. I'm confused as to what you're objecting to...

Robin.