Re: [PATCH] PCI/P2PDMA: Avoid returning a provider for non_mappable_bars

Matt Evans
2026-04-22T14:22:59Z

Hi Leon,

On 21/04/2026 20:49, Leon Romanovsky wrote:
>
> On Tue, Apr 21, 2026 at 10:43:51AM -0700, Matt Evans wrote:
>> Extend pcim_p2pdma_provider()'s checks to exclude functions that have
>> pdev->non_mappable_bars set.
>>
>> Consumers such as VFIO were previously able to map these for access by
>> the CPU or P2P. Update the comment on non_mappable_bars to show it
>> refers to any access, not just userspace CPU access.
>>
>> Fixes: 372d6d1b8ae3c ("PCI/P2PDMA: Refactor to separate core P2P functionality from memory allocation")
>
> I don't object to the patch, but this Fixes line doesn't look correct.
> non_mappable_bars applies only to s390, which doesn't support p2p. That
> wasn't prevented before 372d6d1b8ae3c refactoring too.

Thanks; I'd chosen that commit as it adds the function that the
additional test is being added to.

As an example consumer, vfio_pci_core_get_dmabuf_phys() added in
5d74781ebc86 ("vfio/pci: Add dma-buf export support for MMIO regions")
could do an export when it shouldn't. (And with my other mmap series, a
CPU could then access it, not even P2P.) I suppose this patch could
point to 5d74781ebc86 instead (which allows the naughty DMABUF export),
but I couldn't prove VFIO DMABUF export was the only thing using
pcim_p2pdma_provider() added in 372d6d1b8ae3c (especially as that
symbol's exported).

It still seems most watertight to treat this as a fix for anything
containing 372d6d1b8ae3c, but if you feel it's not right what would be a
better one?

Also, in the other thread (linked above) Alex made the point that whilst
_today_ non_mappable_bars is only set by one s390 device, he expects
future quirks or reasons to exclude mappings would also use
non_mappable_bars so we shouldn't consider it a s390-specific thing.

Cheers,

Matt