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

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

[Ravi Kumar Bandi]

Loadable PCIe driver modules that handle surprise removal or link-down
events need to zap userspace mappings of PCI BAR resources to deliver
SIGBUS on next access, rather than leaving stale mappings to a dead
device.

The correct way to do this is via unmap_mapping_range() on the iomem
address space, which is already exported via EXPORT_SYMBOL.
However, iomem_get_mapping() which returns the iomem address space
is not exported, making it impossible to use unmap_mapping_range()
correctly from a loadable module without resorting to workarounds
such as walking all process VMAs or opening /dev/mem.

Export iomem_get_mapping() via EXPORT_SYMBOL_GPL to complete the
existing exported API and allow loadable modules to properly zap
PCI BAR mappings on device removal.

Signed-off-by: Ravi Kumar Bandi <ravib@amazon.com>
---
 kernel/resource.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/resource.c b/kernel/resource.c
index d02a53fb95d8..8801e390fe2e 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -1311,6 +1311,7 @@ struct address_space *iomem_get_mapping(void)
 	 */
 	return smp_load_acquire(&iomem_inode)->i_mapping;
 }
+EXPORT_SYMBOL_GPL(iomem_get_mapping);
 
 static int __request_region_locked(struct resource *res, struct resource *parent,
 				   resource_size_t start, resource_size_t n,
-- 
2.47.3

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

[David Hildenbrand (Arm)]

On 5/11/26 08:56, Ravi Kumar Bandi wrote:
> Loadable PCIe driver modules that handle surprise removal or link-down
> events need to zap userspace mappings of PCI BAR resources to deliver
> SIGBUS on next access, rather than leaving stale mappings to a dead
> device.
> 
> The correct way to do this is via unmap_mapping_range() on the iomem
> address space, which is already exported via EXPORT_SYMBOL.
> However, iomem_get_mapping() which returns the iomem address space
> is not exported, making it impossible to use unmap_mapping_range()
> correctly from a loadable module without resorting to workarounds
> such as walking all process VMAs or opening /dev/mem.
> 
> Export iomem_get_mapping() via EXPORT_SYMBOL_GPL to complete the
> existing exported API and allow loadable modules to properly zap
> PCI BAR mappings on device removal.
> 
> Signed-off-by: Ravi Kumar Bandi <ravib@amazon.com>
> ---
>  kernel/resource.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/kernel/resource.c b/kernel/resource.c
> index d02a53fb95d8..8801e390fe2e 100644
> --- a/kernel/resource.c
> +++ b/kernel/resource.c
> @@ -1311,6 +1311,7 @@ struct address_space *iomem_get_mapping(void)
>  	 */
>  	return smp_load_acquire(&iomem_inode)->i_mapping;
>  }
> +EXPORT_SYMBOL_GPL(iomem_get_mapping);
>  
>  static int __request_region_locked(struct resource *res, struct resource *parent,
>  				   resource_size_t start, resource_size_t n,

Which in-tree driver wants to make use of this?

-- 
Cheers,

David

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

[Christoph Hellwig]

On Mon, May 11, 2026 at 09:14:04AM +0200, David Hildenbrand (Arm) wrote:
> >  
> >  static int __request_region_locked(struct resource *res, struct resource *parent,
> >  				   resource_size_t start, resource_size_t n,
> 
> Which in-tree driver wants to make use of this?

And why?

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

[Ravi Kumar Bandi]

On Mon, May 11, 2026 at 00:17:45 -0700, Christoph Hellwig wrote:
> And why?

On Mon, May 11, 2026 at 09:14:04 +0200, David Hildenbrand wrote:
> Which in-tree driver wants to make use of this?

Thank you both for reviewing the patch.

Currently this is needed by a PCIe endpoint driver that handles surprise
removal on a device without a hot-plug pin routed to the CPU. The link-down
event is detected by the in-tree Xilinx DMA PL PCIe controller driver
(drivers/pci/controller/pcie-xilinx-dma-pl.c), which notifies the endpoint
driver via the link-down callback.

When link-down is detected, the endpoint driver needs to zap existing
userspace BAR mappings (mmap'd via sysfs resource files) to deliver SIGBUS
rather than leaving stale mappings to a dead device, preventing kernel
crashes on subsequent accesses.

unmap_mapping_range() is already EXPORT_SYMBOL'd for this purpose
(mm/memory.c), but without iomem_get_mapping() being exported, loadable
modules cannot use it correctly for PCI BAR mappings, forcing ugly
workarounds such as walking all process VMAs.

Regards,
Ravi Kumar Bandi

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

[David Hildenbrand (Arm)]

On 5/11/26 18:16, Ravi Kumar Bandi wrote:
> On Mon, May 11, 2026 at 00:17:45 -0700, Christoph Hellwig wrote:
>> And why?
> 
> On Mon, May 11, 2026 at 09:14:04 +0200, David Hildenbrand wrote:
>> Which in-tree driver wants to make use of this?
> 
> Thank you both for reviewing the patch.
> 
> Currently this is needed by a PCIe endpoint driver that handles surprise
> removal on a device without a hot-plug pin routed to the CPU. The link-down
> event is detected by the in-tree Xilinx DMA PL PCIe controller driver
> (drivers/pci/controller/pcie-xilinx-dma-pl.c), which notifies the endpoint
> driver via the link-down callback.
> 
> When link-down is detected, the endpoint driver needs to zap existing
> userspace BAR mappings (mmap'd via sysfs resource files) to deliver SIGBUS
> rather than leaving stale mappings to a dead device, preventing kernel
> crashes on subsequent accesses.
> 
> unmap_mapping_range() is already EXPORT_SYMBOL'd for this purpose
> (mm/memory.c), but without iomem_get_mapping() being exported, loadable
> modules cannot use it correctly for PCI BAR mappings, forcing ugly
> workarounds such as walking all process VMAs.

Okay, so you essentially want to implement something similar to revoke_iomem()?

-- 
Cheers,

David

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

[Christoph Hellwig]

On Mon, May 11, 2026 at 04:16:43PM +0000, Ravi Kumar Bandi wrote:
> On Mon, May 11, 2026 at 00:17:45 -0700, Christoph Hellwig wrote:
> > And why?
> 
> On Mon, May 11, 2026 at 09:14:04 +0200, David Hildenbrand wrote:
> > Which in-tree driver wants to make use of this?
> 
> Thank you both for reviewing the patch.
> 
> Currently this is needed by a PCIe endpoint driver that handles surprise
> removal on a device without a hot-plug pin routed to the CPU.

Which endpoint driver?

> When link-down is detected, the endpoint driver needs to zap existing
> userspace BAR mappings (mmap'd via sysfs resource files) to deliver SIGBUS
> rather than leaving stale mappings to a dead device, preventing kernel
> crashes on subsequent accesses.

Why would the endpoint driver map iomem to userspace?

> unmap_mapping_range() is already EXPORT_SYMBOL'd for this purpose
> (mm/memory.c), but without iomem_get_mapping() being exported, loadable
> modules cannot use it correctly for PCI BAR mappings, forcing ugly
> workarounds such as walking all process VMAs.

Well, we need to see the user(s) first, but once they materialize this
begs for a higher level API.  Until then it is moot anyway.

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

[Ravi Kumar Bandi]

On 5/11/26, Christoph Hellwig wrote:
> Okay, so you essentially want to implement something similar to revoke_iomem()?

Thank you for checking.

Yes, that's correct.

Regards,
Ravi Kumar Bandi

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

[Ravi Kumar Bandi]

On 5/11/26, Bjorn Helgaas wrote:
> Which endpoint driver?

Thank you for checking.

It is Marvell PCIe driver for a device without a hot-plug pin routed
to the CPU. The link-down event is detected by the in-tree Xilinx DMA PL
PCIe controller driver (drivers/pci/controller/pcie-xilinx-dma-pl.c).

> Why would the endpoint driver map iomem to userspace?

sysfs exposed BAR resource files are mmap'd directly by a third-party
userspace driver.

> Well, we need to see the user(s) first, but once they materialize this
> begs for a higher level API. Until then it is moot anyway.

Understood. Thank you for the feedback. We will work on a higher level
API proposal and get back.

Regards,
Ravi Kumar Bandi