From: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
Manivannan Sadhasivam <mani@kernel.org>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
linux-pci@vger.kernel.org
Subject: [PATCH] PCI/sysfs: Return -EINVAL for unsupported I/O BAR mmap
Date: Mon, 20 Jul 2026 20:46:24 +0000 [thread overview]
Message-ID: <20260720204624.1503794-1-kwilczynski@kernel.org> (raw)
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
next reply other threads:[~2026-07-20 20:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 20:46 Krzysztof Wilczyński [this message]
2026-07-20 20:51 ` [PATCH] PCI/sysfs: Return -EINVAL for unsupported I/O BAR mmap sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260720204624.1503794-1-kwilczynski@kernel.org \
--to=kwilczynski@kernel.org \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.