<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/pci/iov.c, branch linux-5.4.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.4.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.4.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2025-10-29T12:59:54Z</updated>
<entry>
<title>PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV</title>
<updated>2025-10-29T12:59:54Z</updated>
<author>
<name>Niklas Schnelle</name>
</author>
<published>2025-08-26T08:52:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5c1cd7d405e94dc6cb320cc0cc092b74895b6ddf'/>
<id>urn:sha1:5c1cd7d405e94dc6cb320cc0cc092b74895b6ddf</id>
<content type='text'>
commit 05703271c3cdcc0f2a8cf6ebdc45892b8ca83520 upstream.

Before disabling SR-IOV via config space accesses to the parent PF,
sriov_disable() first removes the PCI devices representing the VFs.

Since commit 9d16947b7583 ("PCI: Add global pci_lock_rescan_remove()")
such removal operations are serialized against concurrent remove and
rescan using the pci_rescan_remove_lock. No such locking was ever added
in sriov_disable() however. In particular when commit 18f9e9d150fc
("PCI/IOV: Factor out sriov_add_vfs()") factored out the PCI device
removal into sriov_del_vfs() there was still no locking around the
pci_iov_remove_virtfn() calls.

On s390 the lack of serialization in sriov_disable() may cause double
remove and list corruption with the below (amended) trace being observed:

  PSW:  0704c00180000000 0000000c914e4b38 (klist_put+56)
  GPRS: 000003800313fb48 0000000000000000 0000000100000001 0000000000000001
	00000000f9b520a8 0000000000000000 0000000000002fbd 00000000f4cc9480
	0000000000000001 0000000000000000 0000000000000000 0000000180692828
	00000000818e8000 000003800313fe2c 000003800313fb20 000003800313fad8
  #0 [3800313fb20] device_del at c9158ad5c
  #1 [3800313fb88] pci_remove_bus_device at c915105ba
  #2 [3800313fbd0] pci_iov_remove_virtfn at c9152f198
  #3 [3800313fc28] zpci_iov_remove_virtfn at c90fb67c0
  #4 [3800313fc60] zpci_bus_remove_device at c90fb6104
  #5 [3800313fca0] __zpci_event_availability at c90fb3dca
  #6 [3800313fd08] chsc_process_sei_nt0 at c918fe4a2
  #7 [3800313fd60] crw_collect_info at c91905822
  #8 [3800313fe10] kthread at c90feb390
  #9 [3800313fe68] __ret_from_fork at c90f6aa64
  #10 [3800313fe98] ret_from_fork at c9194f3f2.

This is because in addition to sriov_disable() removing the VFs, the
platform also generates hot-unplug events for the VFs. This being the
reverse operation to the hotplug events generated by sriov_enable() and
handled via pdev-&gt;no_vf_scan. And while the event processing takes
pci_rescan_remove_lock and checks whether the struct pci_dev still exists,
the lack of synchronization makes this checking racy.

Other races may also be possible of course though given that this lack of
locking persisted so long observable races seem very rare. Even on s390 the
list corruption was only observed with certain devices since the platform
events are only triggered by config accesses after the removal, so as long
as the removal finished synchronously they would not race. Either way the
locking is missing so fix this by adding it to the sriov_del_vfs() helper.

Just like PCI rescan-remove, locking is also missing in sriov_add_vfs()
including for the error case where pci_stop_and_remove_bus_device() is
called without the PCI rescan-remove lock being held. Even in the non-error
case, adding new PCI devices and buses should be serialized via the PCI
rescan-remove lock. Add the necessary locking.

Fixes: 18f9e9d150fc ("PCI/IOV: Factor out sriov_add_vfs()")
Signed-off-by: Niklas Schnelle &lt;schnelle@linux.ibm.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Benjamin Block &lt;bblock@linux.ibm.com&gt;
Reviewed-by: Farhan Ali &lt;alifm@linux.ibm.com&gt;
Reviewed-by: Julian Ruess &lt;julianr@linux.ibm.com&gt;
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20250826-pci_fix_sriov_disable-v1-1-2d0bc938f2a3@linux.ibm.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI/IOV: Mark VFs as not implementing PCI_COMMAND_MEMORY</title>
<updated>2020-10-29T08:57:54Z</updated>
<author>
<name>Matthew Rosato</name>
</author>
<published>2020-09-10T14:59:55Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=42f16b3add6c3dde6751e5f8f7c2fab6bcc73250'/>
<id>urn:sha1:42f16b3add6c3dde6751e5f8f7c2fab6bcc73250</id>
<content type='text'>
[ Upstream commit 12856e7acde4702b7c3238c15fcba86ff6aa507f ]

For VFs, the Memory Space Enable bit in the Command Register is
hard-wired to 0.

Add a new bit to signify devices where the Command Register Memory
Space Enable bit does not control the device's response to MMIO
accesses.

Fixes: abafbc551fdd ("vfio-pci: Invalidate mmaps and block MMIO access on disabled memory")
Signed-off-by: Matthew Rosato &lt;mjrosato@linux.ibm.com&gt;
Acked-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI/IOV: Serialize sysfs sriov_numvfs reads vs writes</title>
<updated>2020-10-01T11:17:12Z</updated>
<author>
<name>Pierre Crégut</name>
</author>
<published>2019-09-11T07:27:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bdb830d101e7e23a2b09e1c52eb291a86ddfb87e'/>
<id>urn:sha1:bdb830d101e7e23a2b09e1c52eb291a86ddfb87e</id>
<content type='text'>
[ Upstream commit 35ff867b76576e32f34c698ccd11343f7d616204 ]

When sriov_numvfs is being updated, we call the driver-&gt;sriov_configure()
function, which may enable VFs and call probe functions, which may make new
devices visible.  This all happens before before sriov_numvfs_store()
updates sriov-&gt;num_VFs, so previously, concurrent sysfs reads of
sriov_numvfs returned stale values.

Serialize the sysfs read vs the write so the read returns the correct
num_VFs value.

[bhelgaas: hold device_lock instead of checking mutex_is_locked()]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=202991
Link: https://lore.kernel.org/r/20190911072736.32091-1-pierre.cregut@orange.com
Signed-off-by: Pierre Crégut &lt;pierre.cregut@orange.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI/IOV: Fix memory leak in pci_iov_add_virtfn()</title>
<updated>2020-02-14T21:34:08Z</updated>
<author>
<name>Navid Emamdoost</name>
</author>
<published>2019-11-25T19:52:52Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4f0e6425a2da71f6c0a2e4d78f9231ca6778f71b'/>
<id>urn:sha1:4f0e6425a2da71f6c0a2e4d78f9231ca6778f71b</id>
<content type='text'>
commit 8c386cc817878588195dde38e919aa6ba9409d58 upstream.

In the implementation of pci_iov_add_virtfn() the allocated virtfn is
leaked if pci_setup_device() fails. The error handling is not calling
pci_stop_and_remove_bus_device(). Change the goto label to failed2.

Fixes: 156c55325d30 ("PCI: Check for pci_setup_device() failure in pci_iov_add_virtfn()")
Link: https://lore.kernel.org/r/20191125195255.23740-1-navid.emamdoost@gmail.com
Signed-off-by: Navid Emamdoost &lt;navid.emamdoost@gmail.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Merge branch 'pci/resource'</title>
<updated>2019-09-23T21:10:15Z</updated>
<author>
<name>Bjorn Helgaas</name>
</author>
<published>2019-09-23T21:10:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0ca0ef1042f49c4b457ca6cb48ebb5d1c0bcf003'/>
<id>urn:sha1:0ca0ef1042f49c4b457ca6cb48ebb5d1c0bcf003</id>
<content type='text'>
  - Convert pci_resource_to_user() to a weak function to remove
    HAVE_ARCH_PCI_RESOURCE_TO_USER #defines (Denis Efremov)

  - Use PCI_SRIOV_NUM_BARS for idiomatic loop structure (Denis Efremov)

  - Fix Resizable BAR size suspend/restore for 1MB BARs (Sumit Saxena)

  - Correct "pci=resource_alignment" example in documentation (Alexey
    Kardashevskiy)

* pci/resource:
  PCI: Correct pci=resource_alignment parameter example
  PCI: Restore Resizable BAR size bits correctly for 1MB BARs
  PCI: Use PCI_SRIOV_NUM_BARS in loops instead of PCI_IOV_RESOURCE_END
  PCI: Convert pci_resource_to_user() to a weak function

# Conflicts:
#	drivers/pci/pci.c
</content>
</entry>
<entry>
<title>PCI/IOV: Remove group write permission from sriov_numvfs, sriov_drivers_autoprobe</title>
<updated>2019-09-05T18:26:23Z</updated>
<author>
<name>Kelsey Skunberg</name>
</author>
<published>2019-09-05T06:32:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=244c06c3b6d86513066426c9707ee460cd845349'/>
<id>urn:sha1:244c06c3b6d86513066426c9707ee460cd845349</id>
<content type='text'>
Previously the sriov_numvfs and sriov_drivers_autoprobe sysfs files had
0664 permissions, which allowed group write.  libvirt runs as root when
dealing with PCI, and it chowns files needed by qemu, so group write
permission should not be needed.

Change these permissions from 0664 to 0644, which is what DEVICE_ATTR_RW()
does by default.

[bhelgaas: commit log]
Link: https://lore.kernel.org/r/20190905063226.43269-1-skunberg.kelsey@gmail.com
Link: https://lore.kernel.org/r/850cf536-0b72-d78c-efaf-855dcb391087@redhat.com
Signed-off-by: Kelsey Skunberg &lt;skunberg.kelsey@gmail.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Acked-by: Donald Dutile &lt;ddutile@redhat.com&gt;
</content>
</entry>
<entry>
<title>PCI/IOV: Move sysfs SR-IOV functions to iov.c</title>
<updated>2019-08-20T19:05:05Z</updated>
<author>
<name>Kelsey Skunberg</name>
</author>
<published>2019-08-13T20:45:13Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=aaee0c1ffd6399d291b030b49d622b81dd5071c5'/>
<id>urn:sha1:aaee0c1ffd6399d291b030b49d622b81dd5071c5</id>
<content type='text'>
The sysfs SR-IOV functions are only needed when the kernel is built with
SR-IOV support.  Rather than put them in pci-sysfs.c under #ifdef
CONFIG_PCI_IOV, move them to iov.c, which is only compiled when
CONFIG_PCI_IOV=y.

Link: https://lore.kernel.org/r/20190813204513.4790-4-skunberg.kelsey@gmail.com
Signed-off-by: Kelsey Skunberg &lt;skunberg.kelsey@gmail.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Reviewed-by: Donald Dutile &lt;ddutile@redhat.com&gt;
Reviewed-by: Kuppuswamy Sathyanarayanan &lt;sathyanarayanan.kuppuswamy@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>PCI: Use PCI_SRIOV_NUM_BARS in loops instead of PCI_IOV_RESOURCE_END</title>
<updated>2019-08-08T20:12:12Z</updated>
<author>
<name>Denis Efremov</name>
</author>
<published>2019-08-06T14:07:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=39098edbd79e5c9a4357eb924cb259d1c8a11346'/>
<id>urn:sha1:39098edbd79e5c9a4357eb924cb259d1c8a11346</id>
<content type='text'>
Writing loop conditions as "i &lt; NUM" is a common C idiom; using "i &lt;= END"
is unusual and thus prone to errors.  Change loops to use the former.

Link: https://lore.kernel.org/r/20190806140715.19847-1-efremov@linux.com
Signed-off-by: Denis Efremov &lt;efremov@linux.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Kuppuswamy Sathyanarayanan &lt;sathyanarayanan.kuppuswamy@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>Revert "PCI/IOV: Use VF0 cached config space size for other VFs"</title>
<updated>2019-07-03T13:58:19Z</updated>
<author>
<name>Alex Williamson</name>
</author>
<published>2019-06-13T22:57:12Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=76bf6a8634a1ac04d3075993c31a6d94a7f75580'/>
<id>urn:sha1:76bf6a8634a1ac04d3075993c31a6d94a7f75580</id>
<content type='text'>
Revert 975bb8b4dc93 ("PCI/IOV: Use VF0 cached config space size for other
VFs"), which attempted to cache the config space size from the first VF to
re-use for subsequent VFs.

The cached value was determined prior to discovering the PCIe capability on
the VF, which resulted in the first VF reporting the correct config space
size (4K), as it has a special case through pci_cfg_space_size(), while all
the other VFs only reported 256 bytes.  As this was only a performance
optimization, we're better off without it.

Fixes: 975bb8b4dc93 ("PCI/IOV: Use VF0 cached config space size for other VFs")
Link: https://lore.kernel.org/r/156046663197.29869.3633634445109057665.stgit@gimli.home
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Cc: KarimAllah Ahmed &lt;karahmed@amazon.de&gt;
Cc: Kuppuswamy Sathyanarayanan &lt;sathyanarayanan.kuppuswamy@linux.intel.com&gt;
Cc: Hao Zheng &lt;yinhe@linux.alibaba.com&gt;
</content>
</entry>
<entry>
<title>PCI/IOV: Add flag so platforms can skip VF scanning</title>
<updated>2019-01-02T01:04:37Z</updated>
<author>
<name>Sebastian Ott</name>
</author>
<published>2018-12-21T14:14:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=aff68a5a621e2569d126b817d0d42f658df524bf'/>
<id>urn:sha1:aff68a5a621e2569d126b817d0d42f658df524bf</id>
<content type='text'>
Provide a flag to skip scanning for new VFs after SR-IOV enablement.  This
can be set by implementations for which the VFs are already reported by
other means.

Signed-off-by: Sebastian Ott &lt;sebott@linux.ibm.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;</content>
</entry>
</feed>
