Linux PCI subsystem development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ravi Kumar Bandi" <ravib@amazon.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v2] PCI/sysfs: Check if device disabled in resource mmap handler
Date: Thu, 14 May 2026 01:47:02 +0000	[thread overview]
Message-ID: <20260514014702.D411AC19425@smtp.kernel.org> (raw)
In-Reply-To: <20260513041332.24105-1-ravib@amazon.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The `pci_dev_is_disconnected()` check fails to block mmaps on soft-unplugged devices and contradicts the commit's stated intent.
--

commit fff70a5b941929593fed8b551604aadd9e28748d
Author: Ravi Kumar Bandi <ravib@amazon.com>

PCI/sysfs: Check if device disabled in resource mmap handler

This commit adds a check to pci_mmap_resource() to prevent mapping a PCI BAR
resource into userspace if the device is disconnected. The stated intent is to
block new mmaps after a device has been marked disabled or soft-unplugged.

> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index d37860841260c..83d580256c4b2 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -1089,6 +1089,9 @@ static int pci_mmap_resource(struct kobject *kobj, const struct bin_attribute *a
>  	if (ret)
>  		return ret;
>  
> +	if (pci_dev_is_disconnected(pdev))
> +		return -ENODEV;
> +

The commit message mentions that this change prevents new mmaps after a device
has been marked disabled or soft-unplugged. Does this check accurately capture
a soft-unplug?

Looking at pci_dev_is_disconnected(), it strictly checks if the device's
error_state is pci_channel_io_perm_failure. This state is typically set
during surprise hotplug removals or fatal PCIe errors.

During a graceful driver unbind or a soft-removal via sysfs, the error_state
remains pci_channel_io_normal. Would a concurrent mmap() on an already-open
file descriptor still succeed during the window before the sysfs files are
completely removed, bypassing this protection?

Additionally, if the intention was to literally check if the device is disabled
(as the commit subject suggests), would that introduce a regression for
userspace? Valid userspace tools, such as X servers or VFIO utilities, often
map PCI BARs prior to explicitly enabling the device.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260513041332.24105-1-ravib@amazon.com?part=1

  reply	other threads:[~2026-05-14  1:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-12  8:43 [PATCH] PCI/sysfs: Check IORESOURCE_DISABLED in resource mmap handler Ravi Kumar Bandi
2026-05-12  9:26 ` Krzysztof Wilczyński
2026-05-12  9:43   ` Ilpo Järvinen
2026-05-12  9:54     ` Krzysztof Wilczyński
2026-05-13  4:04       ` Ravi Kumar Bandi
2026-05-13  5:07         ` Krzysztof Wilczyński
2026-05-13  6:48           ` Ravi Kumar Bandi
2026-05-13  4:13 ` [PATCH v2] PCI/sysfs: Check if device disabled " Ravi Kumar Bandi
2026-05-14  1:47   ` sashiko-bot [this message]
2026-05-13 19:42 ` [PATCH] PCI/sysfs: Check IORESOURCE_DISABLED " 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=20260514014702.D411AC19425@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=ravib@amazon.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox