Re: [PATCH] resource: export iomem_get_mapping() for loadable modules

[Ravi Kumar Bandi]

On 5/13/26, Dan Williams (nvidia) wrote:
> I took a look and there are some problems here.
>
> My first thought was, "why does the endpoint driver need to do this? The
> PCI core device removal should be responsible for zapping mappings."
>
> 2 things defeat this:
>
> 1/ for sysfs bar mappings, the unmap_mapping_range() in
> kernfs_drain_open_files() misses mappings established against
> the shared iomem_get_mapping().
>
> 2/ procfs access to BAR space has never unmapped on device removal
>
> The practical implication of this is that userspace mappings of BARs can
> survive past device removal. As for mitigations, with IO_STRICT_DEVMEM
> the kernel will zap them before use, with LOCKDOWN the mappings can not
> be established, and CAP_SYS_RAWIO is required (for procfs) to create
> these mappings.

Hello Dan, thank you for the review and guidance.

>
> I recall that Sima added support for ioport mmap revoke support in:
>
> 636b21b50152 PCI: Revoke mappings like devmem
>
> ...but given revoke_iomem() only evacuates at request_mem_region() time,
> I do not see how that ever worked.
>
> We could do something like the following for kernfs regression in the
> near term, or just proceed with making revoke_iomem() something that the
> PCI core does unconditionally by physical address on device removal.
> That would also fix the procfs gap.
>
> Ravi, I think your time is best spent getting the PCI core to handle the
> unmap on device removal.

Agree. Thank you for the pointers, I will work on it and get back here.

>
> -- >8 --
> Subject: resource: Fix PCI/sysfs mmap revocation vs CONFIG_IO_STRICT_DEVMEM=n
>
> From: Dan Williams <djbw@xxxxxxxxxx>