[PATCH] PCI/sysfs: Return -EINVAL for unsupported I/O BAR mmap

[PATCH] PCI/sysfs: Return -EINVAL for unsupported I/O BAR mmap

[Krzysztof Wilczyński]

Currently, mmap() of a resourceN file for an I/O BAR fails with
-ENODEV on architectures where arch_can_pci_mmap_io() is 0, such as
x86, because the attribute has no mmap callback there and the error
comes from the generic kernfs dispatch.

This is a side effect of commit e854d8b2a82e ("PCI: Add
arch_can_pci_mmap_io() on architectures which can mmap() I/O space"),
which removed the mmap callback from the I/O resource attribute on
these architectures.  Previously the request reached the architecture
mmap code and failed with -EINVAL, and the same commit deliberately
kept -EINVAL for the identical operation on the procfs interface, so
the two PCI userspace interfaces have disagreed ever since.

Therefore, add a pci_mmap_resource_io_unsupported() callback that
returns -EINVAL and use it as the mmap handler of the I/O resource
attribute when arch_can_pci_mmap_io() is 0, so the failure is
produced deliberately by PCI code, consistent with the procfs
interface and with the behaviour before e854d8b2a82e.

Architectures where arch_can_pci_mmap_io() is non-zero keep the real
pci_mmap_resource_uc() handler and are unaffected.  The mmap() fails
either way.  Only the reported error changes from -ENODEV to -EINVAL.

Fixes: e854d8b2a82e ("PCI: Add arch_can_pci_mmap_io() on architectures which can mmap() I/O space")
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
---
 drivers/pci/pci-sysfs.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 5ec0b245a69b..4cc082929d1a 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1244,7 +1244,16 @@ static loff_t pci_llseek_resource(struct file *filep,
 	.llseek = pci_llseek_resource,		\
 	.mmap = pci_mmap_resource_uc,
 #else
-# define __PCI_RESOURCE_IO_MMAP_ATTRS
+static int pci_mmap_resource_io_unsupported(struct file *filp,
+					    struct kobject *kobj,
+					    const struct bin_attribute *attr,
+					    struct vm_area_struct *vma)
+{
+	return -EINVAL;
+}
+
+# define __PCI_RESOURCE_IO_MMAP_ATTRS	\
+	.mmap = pci_mmap_resource_io_unsupported,
 #endif
 
 #define pci_dev_resource_io_attr(_bar)					\
-- 
2.55.0

Re: [PATCH] PCI/sysfs: Return -EINVAL for unsupported I/O BAR mmap

[sashiko-bot]

> Currently, mmap() of a resourceN file for an I/O BAR fails with
> -ENODEV on architectures where arch_can_pci_mmap_io() is 0, such as
> x86, because the attribute has no mmap callback there and the error
> comes from the generic kernfs dispatch.
> 
> This is a side effect of commit e854d8b2a82e ("PCI: Add
> arch_can_pci_mmap_io() on architectures which can mmap() I/O space"),
> which removed the mmap callback from the I/O resource attribute on
> these architectures.  Previously the request reached the architecture
> mmap code and failed with -EINVAL, and the same commit deliberately
> kept -EINVAL for the identical operation on the procfs interface, so
> the two PCI userspace interfaces have disagreed ever since.
> 
> Therefore, add a pci_mmap_resource_io_unsupported() callback that
> returns -EINVAL and use it as the mmap handler of the I/O resource
> attribute when arch_can_pci_mmap_io() is 0, so the failure is
> produced deliberately by PCI code, consistent with the procfs
> interface and with the behaviour before e854d8b2a82e.
> 
> Architectures where arch_can_pci_mmap_io() is non-zero keep the real
> pci_mmap_resource_uc() handler and are unaffected.  The mmap() fails
> either way.  Only the reported error changes from -ENODEV to -EINVAL.
> 
> Fixes: e854d8b2a82e ("PCI: Add arch_can_pci_mmap_io() on architectures which can mmap() I/O space")
> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720204624.1503794-1-kwilczynski@kernel.org?part=1