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

[Matt Evans <mattev@meta.com>]

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