* [PATCH v2 1/3] s390/pci: Rework __zpci_event_error() to remove conditional locking
2026-08-03 14:29 [PATCH v2 0/3] s390/pci: Enable CONTEXT_ANALYSIS Heiko Carstens
@ 2026-08-03 14:29 ` Heiko Carstens
2026-08-03 14:36 ` sashiko-bot
2026-08-03 16:40 ` Niklas Schnelle
2026-08-03 14:29 ` [PATCH v2 2/3] s390/pci: Rework__zpci_event_availability() " Heiko Carstens
` (2 subsequent siblings)
3 siblings, 2 replies; 9+ messages in thread
From: Heiko Carstens @ 2026-08-03 14:29 UTC (permalink / raw)
To: Alexander Gordeev, Sven Schnelle, Vasily Gorbik,
Christian Borntraeger, Niklas Schnelle, Gerd Bayer
Cc: linux-s390, linux-kernel
Clang's compiler based static context analysis does not work with
locks that are conditionally taken like in __zpci_event_error():
arch/s390/pci/pci_event.c:320:2: warning: mutex 'get_zdev_by_fid(ccdf->fid).state_lock'
is not held on every path through here [-Wthread-safety-analysis]
Given that code which takes locks conditionally can be considered
suboptimal rework __zpci_event_error() to get rid of this.
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
---
arch/s390/pci/pci_event.c | 43 ++++++++++++++++++++++-----------------
1 file changed, 24 insertions(+), 19 deletions(-)
diff --git a/arch/s390/pci/pci_event.c b/arch/s390/pci/pci_event.c
index 839bd91c056e..48fa26dcbee1 100644
--- a/arch/s390/pci/pci_event.c
+++ b/arch/s390/pci/pci_event.c
@@ -288,6 +288,12 @@ static void zpci_event_io_failure(struct pci_dev *pdev, pci_channel_state_t es)
pci_dev_unlock(pdev);
}
+static void __zpci_event_print_error(struct pci_dev *pdev, struct zpci_ccdf_err *ccdf)
+{
+ pr_err("%s: Event 0x%x reports an error for PCI function 0x%x\n",
+ pdev ? pci_name(pdev) : "n/a", ccdf->pec, ccdf->fid);
+}
+
static void __zpci_event_error(struct zpci_ccdf_err *ccdf)
{
struct zpci_dev *zdev = get_zdev_by_fid(ccdf->fid);
@@ -301,24 +307,24 @@ static void __zpci_event_error(struct zpci_ccdf_err *ccdf)
zpci_err("error CCDF:\n");
zpci_err_hex(ccdf, sizeof(*ccdf));
- if (zdev) {
- mutex_lock(&zdev->state_lock);
- rc = clp_refresh_fh(zdev->fid, &fh);
- if (rc)
- goto no_pdev;
- if (!fh || ccdf->fh != fh) {
- /* Ignore events with stale handles */
- zpci_dbg(3, "err fid:%x, fh:%x (stale %x)\n",
- ccdf->fid, fh, ccdf->fh);
- goto no_pdev;
- }
- zpci_update_fh(zdev, ccdf->fh);
- if (zdev->zbus->bus)
- pdev = pci_get_slot(zdev->zbus->bus, zdev->devfn);
- }
+ if (!zdev)
+ return __zpci_event_print_error(pdev, ccdf);
- pr_err("%s: Event 0x%x reports an error for PCI function 0x%x\n",
- pdev ? pci_name(pdev) : "n/a", ccdf->pec, ccdf->fid);
+ mutex_lock(&zdev->state_lock);
+ rc = clp_refresh_fh(zdev->fid, &fh);
+ if (rc)
+ goto no_pdev;
+ if (!fh || ccdf->fh != fh) {
+ /* Ignore events with stale handles */
+ zpci_dbg(3, "err fid:%x, fh:%x (stale %x)\n",
+ ccdf->fid, fh, ccdf->fh);
+ goto no_pdev;
+ }
+ zpci_update_fh(zdev, ccdf->fh);
+ if (zdev->zbus->bus)
+ pdev = pci_get_slot(zdev->zbus->bus, zdev->devfn);
+
+ __zpci_event_print_error(pdev, ccdf);
if (!pdev)
goto no_pdev;
@@ -340,8 +346,7 @@ static void __zpci_event_error(struct zpci_ccdf_err *ccdf)
}
pci_dev_put(pdev);
no_pdev:
- if (zdev)
- mutex_unlock(&zdev->state_lock);
+ mutex_unlock(&zdev->state_lock);
zpci_zdev_put(zdev);
}
--
2.53.0
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH v2 1/3] s390/pci: Rework __zpci_event_error() to remove conditional locking
2026-08-03 14:29 ` [PATCH v2 1/3] s390/pci: Rework __zpci_event_error() to remove conditional locking Heiko Carstens
@ 2026-08-03 14:36 ` sashiko-bot
2026-08-03 16:40 ` Niklas Schnelle
1 sibling, 0 replies; 9+ messages in thread
From: sashiko-bot @ 2026-08-03 14:36 UTC (permalink / raw)
To: Heiko Carstens
Cc: Alexander Gordeev, linux-s390, Heiko Carstens, Vasily Gorbik
> Clang's compiler based static context analysis does not work with
> locks that are conditionally taken like in __zpci_event_error():
>
> arch/s390/pci/pci_event.c:320:2: warning: mutex 'get_zdev_by_fid(ccdf->fid).state_lock'
> is not held on every path through here [-Wthread-safety-analysis]
>
> Given that code which takes locks conditionally can be considered
> suboptimal rework __zpci_event_error() to get rid of this.
>
> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260803142907.1771509-1-hca@linux.ibm.com?part=1
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2 1/3] s390/pci: Rework __zpci_event_error() to remove conditional locking
2026-08-03 14:29 ` [PATCH v2 1/3] s390/pci: Rework __zpci_event_error() to remove conditional locking Heiko Carstens
2026-08-03 14:36 ` sashiko-bot
@ 2026-08-03 16:40 ` Niklas Schnelle
1 sibling, 0 replies; 9+ messages in thread
From: Niklas Schnelle @ 2026-08-03 16:40 UTC (permalink / raw)
To: Heiko Carstens, Alexander Gordeev, Sven Schnelle, Vasily Gorbik,
Christian Borntraeger, Gerd Bayer
Cc: linux-s390, linux-kernel
On Mon, 2026-08-03 at 16:29 +0200, Heiko Carstens wrote:
> Clang's compiler based static context analysis does not work with
> locks that are conditionally taken like in __zpci_event_error():
>
> arch/s390/pci/pci_event.c:320:2: warning: mutex 'get_zdev_by_fid(ccdf->fid).state_lock'
> is not held on every path through here [-Wthread-safety-analysis]
>
> Given that code which takes locks conditionally can be considered
> suboptimal rework __zpci_event_error() to get rid of this.
>
> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
> ---
> arch/s390/pci/pci_event.c | 43 ++++++++++++++++++++++-----------------
> 1 file changed, 24 insertions(+), 19 deletions(-)
>
> diff --git a/arch/s390/pci/pci_event.c b/arch/s390/pci/pci_event.c
> index 839bd91c056e..48fa26dcbee1 100644
> --- a/arch/s390/pci/pci_event.c
> +++ b/arch/s390/pci/pci_event.c
> @@ -288,6 +288,12 @@ static void zpci_event_io_failure(struct pci_dev *pdev, pci_channel_state_t es)
> pci_dev_unlock(pdev);
> }
>
> +static void __zpci_event_print_error(struct pci_dev *pdev, struct zpci_ccdf_err *ccdf)
> +{
> + pr_err("%s: Event 0x%x reports an error for PCI function 0x%x\n",
> + pdev ? pci_name(pdev) : "n/a", ccdf->pec, ccdf->fid);
> +}
> +
> static void __zpci_event_error(struct zpci_ccdf_err *ccdf)
> {
> struct zpci_dev *zdev = get_zdev_by_fid(ccdf->fid);
> @@ -301,24 +307,24 @@ static void __zpci_event_error(struct zpci_ccdf_err *ccdf)
> zpci_err("error CCDF:\n");
> zpci_err_hex(ccdf, sizeof(*ccdf));
>
> - if (zdev) {
> - mutex_lock(&zdev->state_lock);
> - rc = clp_refresh_fh(zdev->fid, &fh);
> - if (rc)
> - goto no_pdev;
> - if (!fh || ccdf->fh != fh) {
> - /* Ignore events with stale handles */
> - zpci_dbg(3, "err fid:%x, fh:%x (stale %x)\n",
> - ccdf->fid, fh, ccdf->fh);
> - goto no_pdev;
> - }
> - zpci_update_fh(zdev, ccdf->fh);
> - if (zdev->zbus->bus)
> - pdev = pci_get_slot(zdev->zbus->bus, zdev->devfn);
> - }
> + if (!zdev)
> + return __zpci_event_print_error(pdev, ccdf);
Nit: Here pdev is always NULL because the assignment moved below.
Functionally this is fine but it would be more clear this is the case
if you passed NULL for pdev explicitly.
>
> - pr_err("%s: Event 0x%x reports an error for PCI function 0x%x\n",
> - pdev ? pci_name(pdev) : "n/a", ccdf->pec, ccdf->fid);
> + mutex_lock(&zdev->state_lock);
> + rc = clp_refresh_fh(zdev->fid, &fh);
> + if (rc)
> + goto no_pdev;
> + if (!fh || ccdf->fh != fh) {
> + /* Ignore events with stale handles */
> + zpci_dbg(3, "err fid:%x, fh:%x (stale %x)\n",
> + ccdf->fid, fh, ccdf->fh);
> + goto no_pdev;
> + }
> + zpci_update_fh(zdev, ccdf->fh);
> + if (zdev->zbus->bus)
> + pdev = pci_get_slot(zdev->zbus->bus, zdev->devfn);
> +
> + __zpci_event_print_error(pdev, ccdf);
>
> if (!pdev)
> goto no_pdev;
> @@ -340,8 +346,7 @@ static void __zpci_event_error(struct zpci_ccdf_err *ccdf)
> }
> pci_dev_put(pdev);
> no_pdev:
> - if (zdev)
> - mutex_unlock(&zdev->state_lock);
> + mutex_unlock(&zdev->state_lock);
> zpci_zdev_put(zdev);
> }
>
Thanks for cleaning this up. Even on its own this would be a net
improvement. So with or without my nit resolved feel free to add:
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
Thanks,
Niklas
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v2 2/3] s390/pci: Rework__zpci_event_availability() to remove conditional locking
2026-08-03 14:29 [PATCH v2 0/3] s390/pci: Enable CONTEXT_ANALYSIS Heiko Carstens
2026-08-03 14:29 ` [PATCH v2 1/3] s390/pci: Rework __zpci_event_error() to remove conditional locking Heiko Carstens
@ 2026-08-03 14:29 ` Heiko Carstens
2026-08-03 14:43 ` sashiko-bot
2026-08-03 14:29 ` [PATCH v2 3/3] s390/pci: Enable CONTEXT_ANALYSIS Heiko Carstens
2026-08-03 14:55 ` [PATCH v2 0/3] " Niklas Schnelle
3 siblings, 1 reply; 9+ messages in thread
From: Heiko Carstens @ 2026-08-03 14:29 UTC (permalink / raw)
To: Alexander Gordeev, Sven Schnelle, Vasily Gorbik,
Christian Borntraeger, Niklas Schnelle, Gerd Bayer
Cc: linux-s390, linux-kernel
Clang's compiler based static context analysis does not work with locks
that are conditionally taken like in __zpci_event_availability():
arch/s390/pci/pci_event.c:402:10: warning: mutex 'get_zdev_by_fid(ccdf->fid).state_lock'
is not held on every path through here [-Wthread-safety-analysis]
Given that code which takes locks conditionally can be considered
suboptimal rework __zpci_event_availability() to get rid of this.
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
---
arch/s390/pci/pci_event.c | 108 +++++++++++++++++++-------------------
1 file changed, 53 insertions(+), 55 deletions(-)
diff --git a/arch/s390/pci/pci_event.c b/arch/s390/pci/pci_event.c
index 48fa26dcbee1..f96ee87405f9 100644
--- a/arch/s390/pci/pci_event.c
+++ b/arch/s390/pci/pci_event.c
@@ -389,19 +389,25 @@ static void zpci_event_reappear(struct zpci_dev *zdev)
static void __zpci_event_availability(struct zpci_ccdf_avail *ccdf)
{
- struct zpci_dev *zdev = get_zdev_by_fid(ccdf->fid);
- bool existing_zdev = !!zdev;
+ struct zpci_dev *zdev;
enum zpci_state state;
zpci_dbg(3, "avl fid:%x, fh:%x, pec:%x\n",
ccdf->fid, ccdf->fh, ccdf->pec);
- if (existing_zdev)
- mutex_lock(&zdev->state_lock);
+ /* 0x0306 - No handle or fid stored */
+ if (ccdf->pec == 0x0306) {
+ /* 0x308 or 0x302 for multiple devices */
+ zpci_remove_reserved_devices();
+ zpci_scan_devices();
+ return;
+ }
- switch (ccdf->pec) {
- case 0x0301: /* Reserved|Standby -> Configured */
- if (!zdev) {
+ zdev = get_zdev_by_fid(ccdf->fid);
+
+ if (!zdev) {
+ switch (ccdf->pec) {
+ case 0x0301: /* Reserved|Standby -> Configured */
zdev = zpci_create_device(ccdf->fid, ccdf->fh, ZPCI_FN_STATE_CONFIGURED);
if (IS_ERR(zdev))
break;
@@ -409,18 +415,9 @@ static void __zpci_event_availability(struct zpci_ccdf_avail *ccdf)
kfree(zdev);
break;
}
- } else {
- if (zdev->state == ZPCI_FN_STATE_RESERVED)
- zpci_event_reappear(zdev);
- /* the configuration request may be stale */
- else if (zdev->state != ZPCI_FN_STATE_STANDBY)
- break;
- zdev->state = ZPCI_FN_STATE_CONFIGURED;
- }
- zpci_scan_configured_device(zdev, ccdf->fh);
- break;
- case 0x0302: /* Reserved -> Standby */
- if (!zdev) {
+ zpci_scan_configured_device(zdev, ccdf->fh);
+ break;
+ case 0x0302: /* Reserved -> Standby */
zdev = zpci_create_device(ccdf->fid, ccdf->fh, ZPCI_FN_STATE_STANDBY);
if (IS_ERR(zdev))
break;
@@ -428,53 +425,54 @@ static void __zpci_event_availability(struct zpci_ccdf_avail *ccdf)
kfree(zdev);
break;
}
- } else {
- if (zdev->state == ZPCI_FN_STATE_RESERVED)
- zpci_event_reappear(zdev);
- zpci_update_fh(zdev, ccdf->fh);
+ break;
}
+ return;
+ }
+
+ mutex_lock(&zdev->state_lock);
+ switch (ccdf->pec) {
+ case 0x0301: /* Reserved|Standby -> Configured */
+ if (zdev->state == ZPCI_FN_STATE_RESERVED)
+ zpci_event_reappear(zdev);
+ /* the configuration request may be stale */
+ else if (zdev->state != ZPCI_FN_STATE_STANDBY)
+ break;
+ zdev->state = ZPCI_FN_STATE_CONFIGURED;
+ zpci_scan_configured_device(zdev, ccdf->fh);
+ break;
+ case 0x0302: /* Reserved -> Standby */
+ if (zdev->state == ZPCI_FN_STATE_RESERVED)
+ zpci_event_reappear(zdev);
+ zpci_update_fh(zdev, ccdf->fh);
break;
case 0x0303: /* Deconfiguration requested */
- if (zdev) {
- /* The event may have been queued before we configured
- * the device.
- */
- if (zdev->state != ZPCI_FN_STATE_CONFIGURED)
- break;
- zpci_update_fh(zdev, ccdf->fh);
- zpci_deconfigure_device(zdev);
- }
+ /* The event may have been queued before we configured
+ * the device.
+ */
+ if (zdev->state != ZPCI_FN_STATE_CONFIGURED)
+ break;
+ zpci_update_fh(zdev, ccdf->fh);
+ zpci_deconfigure_device(zdev);
break;
case 0x0304: /* Configured -> Standby|Reserved */
- if (zdev) {
- /* The event may have been queued before we configured
- * the device.:
- */
- if (zdev->state == ZPCI_FN_STATE_CONFIGURED)
- zpci_event_hard_deconfigured(zdev, ccdf->fh);
- /* The 0x0304 event may immediately reserve the device */
- if (!clp_get_state(zdev->fid, &state) &&
- state == ZPCI_FN_STATE_RESERVED) {
- zpci_device_reserved(zdev);
- }
+ /* The event may have been queued before we configured
+ * the device.:
+ */
+ if (zdev->state == ZPCI_FN_STATE_CONFIGURED)
+ zpci_event_hard_deconfigured(zdev, ccdf->fh);
+ /* The 0x0304 event may immediately reserve the device */
+ if (!clp_get_state(zdev->fid, &state) &&
+ state == ZPCI_FN_STATE_RESERVED) {
+ zpci_device_reserved(zdev);
}
break;
- case 0x0306: /* 0x308 or 0x302 for multiple devices */
- zpci_remove_reserved_devices();
- zpci_scan_devices();
- break;
case 0x0308: /* Standby -> Reserved */
- if (!zdev)
- break;
zpci_device_reserved(zdev);
break;
- default:
- break;
- }
- if (existing_zdev) {
- mutex_unlock(&zdev->state_lock);
- zpci_zdev_put(zdev);
}
+ mutex_unlock(&zdev->state_lock);
+ zpci_zdev_put(zdev);
}
void zpci_event_availability(void *data)
--
2.53.0
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH v2 2/3] s390/pci: Rework__zpci_event_availability() to remove conditional locking
2026-08-03 14:29 ` [PATCH v2 2/3] s390/pci: Rework__zpci_event_availability() " Heiko Carstens
@ 2026-08-03 14:43 ` sashiko-bot
0 siblings, 0 replies; 9+ messages in thread
From: sashiko-bot @ 2026-08-03 14:43 UTC (permalink / raw)
To: Heiko Carstens
Cc: linux-s390, Vasily Gorbik, Heiko Carstens, Alexander Gordeev
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] zpci_remove_reserved_devices() calls zpci_device_reserved(zdev) without holding the required zdev->state_lock, leading to a race condition and double-put Use-After-Free.
--
--- Patch [2]: [PATCH v2 2/3] s390/pci: Rework__zpci_event_availability() to remove conditional locking ---
commit f2856d16e29fb1c200332bdad2a6ab6ca714f024
Author: Heiko Carstens <hca@linux.ibm.com>
s390/pci: Rework__zpci_event_availability() to remove conditional locking
This commit reworks __zpci_event_availability() to eliminate conditional
locking of the zdev->state_lock, resolving a clang static analysis warning.
The handling for the 0x0306 multiple-device event is also moved to the
beginning of the function since it does not target a specific device.
> diff --git a/arch/s390/pci/pci_event.c b/arch/s390/pci/pci_event.c
> index 48fa26dcbee14..f96ee87405f98 100644
> --- a/arch/s390/pci/pci_event.c
> +++ b/arch/s390/pci/pci_event.c
> @@ -389,19 +389,25 @@ static void zpci_event_reappear(struct zpci_dev *zdev)
>
> static void __zpci_event_availability(struct zpci_ccdf_avail *ccdf)
> {
[ ... ]
> - if (existing_zdev)
> - mutex_lock(&zdev->state_lock);
> + /* 0x0306 - No handle or fid stored */
> + if (ccdf->pec == 0x0306) {
> + /* 0x308 or 0x302 for multiple devices */
> + zpci_remove_reserved_devices();
[Severity: High]
This is a pre-existing issue, but does zpci_remove_reserved_devices() call
zpci_device_reserved() without holding the required zdev->state_lock?
Looking at zpci_remove_reserved_devices() in arch/s390/pci/pci.c, it
iterates through the remove list and calls zpci_device_reserved() directly:
arch/s390/pci/pci.c:zpci_remove_reserved_devices() {
...
list_for_each_entry_safe(zdev, tmp, &remove, entry)
zpci_device_reserved(zdev);
}
However, zpci_device_reserved() expects the lock to be held to safely
serialize state transitions and reference dropping:
arch/s390/pci/pci.c:zpci_device_reserved() {
lockdep_assert_held(&zdev->state_lock);
if (zdev->state == ZPCI_FN_STATE_RESERVED)
return;
zdev->state = ZPCI_FN_STATE_RESERVED;
...
zpci_zdev_put(zdev);
}
Can this lead to a race condition if two threads process events for the same
device concurrently (e.g., a specific 0x0308 event and a bulk 0x0306 event)?
If both threads read the state as STANDBY simultaneously, they could both
invoke zpci_device_reserved() and cause zpci_zdev_put() to be called twice
for a single reference, potentially leading to a use-after-free of the
zpci_dev object.
> + zpci_scan_devices();
> + return;
> + }
>
> - switch (ccdf->pec) {
> - case 0x0301: /* Reserved|Standby -> Configured */
> - if (!zdev) {
> + zdev = get_zdev_by_fid(ccdf->fid);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260803142907.1771509-1-hca@linux.ibm.com?part=2
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v2 3/3] s390/pci: Enable CONTEXT_ANALYSIS
2026-08-03 14:29 [PATCH v2 0/3] s390/pci: Enable CONTEXT_ANALYSIS Heiko Carstens
2026-08-03 14:29 ` [PATCH v2 1/3] s390/pci: Rework __zpci_event_error() to remove conditional locking Heiko Carstens
2026-08-03 14:29 ` [PATCH v2 2/3] s390/pci: Rework__zpci_event_availability() " Heiko Carstens
@ 2026-08-03 14:29 ` Heiko Carstens
2026-08-03 14:37 ` sashiko-bot
2026-08-03 14:55 ` [PATCH v2 0/3] " Niklas Schnelle
3 siblings, 1 reply; 9+ messages in thread
From: Heiko Carstens @ 2026-08-03 14:29 UTC (permalink / raw)
To: Alexander Gordeev, Sven Schnelle, Vasily Gorbik,
Christian Borntraeger, Niklas Schnelle, Gerd Bayer
Cc: linux-s390, linux-kernel
Enable CONTEXT_ANALYSIS since s390's pci code compiles now without
warnings.
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
---
arch/s390/pci/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/s390/pci/Makefile b/arch/s390/pci/Makefile
index 1810e0944a4e..b8be1316491b 100644
--- a/arch/s390/pci/Makefile
+++ b/arch/s390/pci/Makefile
@@ -3,6 +3,8 @@
# Makefile for the s390 PCI subsystem.
#
+CONTEXT_ANALYSIS := y
+
obj-$(CONFIG_PCI) += pci.o pci_irq.o pci_clp.o \
pci_event.o pci_debug.o pci_insn.o pci_mmio.o \
pci_bus.o pci_kvm_hook.o pci_report.o pci_fixup.o
--
2.53.0
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH v2 0/3] s390/pci: Enable CONTEXT_ANALYSIS
2026-08-03 14:29 [PATCH v2 0/3] s390/pci: Enable CONTEXT_ANALYSIS Heiko Carstens
` (2 preceding siblings ...)
2026-08-03 14:29 ` [PATCH v2 3/3] s390/pci: Enable CONTEXT_ANALYSIS Heiko Carstens
@ 2026-08-03 14:55 ` Niklas Schnelle
3 siblings, 0 replies; 9+ messages in thread
From: Niklas Schnelle @ 2026-08-03 14:55 UTC (permalink / raw)
To: Heiko Carstens, Alexander Gordeev, Sven Schnelle, Vasily Gorbik,
Christian Borntraeger, Gerd Bayer
Cc: linux-s390, linux-kernel
On Mon, 2026-08-03 at 16:29 +0200, Heiko Carstens wrote:
> v2:
>
> - Address potential zdev reference leak (false positive) by adding a
> comment, and moving get_zdev_by_fid() [Sashiko, Niklas]
>
> - Note: this reveals a pre-existing bug: zpci_remove_reserved_devices()
> calls zpci_device_reserved() without holding locks. It looks like
> this can be fixed easily by adding a mutex_lock()/mutex_unlock()
> pair in zpci_remove_reserved_devices(), but that is not within
> the scope of this series, and up to the pci maintainers
I agree with this assessment and can provide a patch on top of this
series to address this.
Thanks,
Niklas
^ permalink raw reply [flat|nested] 9+ messages in thread