lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6deed02fcbf2c359382f9e96a4f6883d34f5df28.camel@linux.ibm.com>
Date: Mon, 27 Oct 2025 09:28:48 +0100
From: Niklas Schnelle <schnelle@...ux.ibm.com>
To: Bjorn Helgaas <bhelgaas@...gle.com>
Cc: Jan Kiszka <jan.kiszka@...mens.com>, Huacai Chen
 <chenhuacai@...nel.org>,
        linux-s390 <linux-s390@...r.kernel.org>, loongarch@...ts.linux.dev,
        Farhan Ali <alifm@...ux.ibm.com>,
        Matthew
 Rosato <mjrosato@...ux.ibm.com>,
        Tianrui Zhao <zhaotianrui@...ngson.cn>,
        Gerald Schaefer	 <gerald.schaefer@...ux.ibm.com>,
        Heiko Carstens
 <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>,
        Alexander Gordeev
 <agordeev@...ux.ibm.com>,
        Sven Schnelle	 <svens@...ux.ibm.com>,
        Christian
 Borntraeger <borntraeger@...ux.ibm.com>,
        Gerd Bayer
 <gbayer@...ux.ibm.com>, linux-kernel@...r.kernel.org,
        linux-pci@...r.kernel.org, jailhouse-dev@...glegroups.com
Subject: Re: [PATCH v4 1/2] PCI: Fix isolated PCI function probing with ARI
 and SR-IOV

On Thu, 2025-10-23 at 17:20 +0200, Niklas Schnelle wrote:
> When the isolated PCI function probing mechanism is used in conjunction
> with ARI or SR-IOV it may not find all available PCI functions. In the
> case of ARI the problem is that next_ari_fn() always returns -ENODEV if
> dev is NULL and thus if fn 0 is missing the scan stops.
> 
> For SR-IOV things are more complex. Here the problem is that the check
> for multifunction may fail. One example where this can occur is if the
> first passed-through function is a VF with devfn 8. Now in
> pci_scan_slot() this means it is fn 0 and thus multifunction doesn't get
> set. Since VFs don't get multifunction set via PCI_HEADER_TYPE_MFD it
> remains unset and probing stops even if there is a devfn 9.
> 
> Now at the moment both of these issues are hidden on s390. The first one
> because ARI is detected as disabled as struct pci_bus's self is NULL
> even though firmware does enable and use ARI. The second issue is hidden
> as a side effect of commit 25f39d3dcb48 ("s390/pci: Ignore RID for
> isolated VFs"). This is because VFs are either put on their own virtual
> bus if the parent PF is not passed-through to the same instance or VFs
> are hotplugged once SR-IOV is enabled on the parent PF and then
> pci_scan_single_device() is used.
> 
> Still especially the first issue prevents correct detection of ARI and
> the second might be a problem for other users of isolated function
> probing. Fix both issues by keeping things as simple as possible. If
> isolated function probing is enabled simply scan every possible devfn.
> 
> Fixes: 189c6c33ff42 ("PCI: Extend isolated function probing to s390")

Since I'm adding a fixes tag, I should also add Cc stable. Added for
next revision.

> Link: https://lore.kernel.org/linux-pci/d3f11e8562f589ddb2c1c83e74161bd8948084c3.camel@linux.ibm.com/
> Signed-off-by: Niklas Schnelle <schnelle@...ux.ibm.com>
> ---
>  drivers/pci/probe.c | 20 ++++++++++++--------
>  1 file changed, 12 insertions(+), 8 deletions(-)
> 
--- snip ---

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ