All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Benjamin Block" <bblock@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, "Heiko Carstens" <hca@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>,
	intel-xe@lists.freedesktop.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH v15 5/5] s390/pci: Fix circular/recursive deadlocks in PCI-bus and -device release
Date: Thu, 24 Sep 2026 16:44:06 +0000	[thread overview]
Message-ID: <20260924164406.B7A151F000FF@smtp.kernel.org> (raw)
In-Reply-To: <845f3fd0e94294765ea10454823c21e464d2f4bd.1790267348.git.bblock@linux.ibm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] pci: mixing goto and cleanup helpers in __zpci_event_error and pci_base_init
--

commit 703530c4b98b53581e1625ffc110fa9701e163ee
Author: Benjamin Block <bblock@linux.ibm.com>

s390/pci: Fix circular/recursive deadlocks in PCI-bus and -device release

When removing PCI device or PCI bus objects there are a couple of
call-chains where it is possible that the kernel runs into a circular
deadlock involving the central pci_rescan_remove_lock.

> diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
> index d64c544b32b0c..4fc3e3dc87ad1 100644
> --- a/arch/s390/pci/pci.c
> +++ b/arch/s390/pci/pci.c
[ ... ]
> @@ -1208,7 +1212,8 @@ static int __init pci_base_init(void)
>  	if (rc)
>  		goto out_irq;
>  
> -	rc = zpci_scan_devices();
> +	scoped_guard(pci_rescan_remove)
> +		rc = zpci_scan_devices();
>  	if (rc)
>  		goto out_find;
>  

[Severity: Medium]
Is it intentional to mix goto-based error handling with scope-based cleanup
helpers here?

The pci_base_init() function contains multiple goto statements for error
handling, and this patch introduces a scoped_guard() into the same routine.
The cleanup.h guidelines state that usage of goto and cleanup helpers should
never be mixed in the same function.

[ ... ]
> diff --git a/arch/s390/pci/pci_event.c b/arch/s390/pci/pci_event.c
> index f317a1465dad8..268f435677ae3 100644
> --- a/arch/s390/pci/pci_event.c
> +++ b/arch/s390/pci/pci_event.c
[ ... ]
> @@ -382,6 +382,7 @@ static void __zpci_event_error(struct zpci_ccdf_err *ccdf)
>  	pci_dev_put(pdev);
>  no_pdev:
>  	mutex_unlock(&zdev->state_lock);
> +	guard(pci_rescan_remove)();
>  	zpci_zdev_put(zdev);
>  }
>  

[Severity: Medium]
Can this introduction of guard() into __zpci_event_error() also cause issues
with mixed cleanup paradigms?

In __zpci_event_error(), there are goto statements used for error handling,
and this patch introduces a guard() right at the cleanup label. Mixing goto
with cleanup.h helpers in the same function goes against the subsystem
guidelines.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1790267348.git.bblock@linux.ibm.com?part=5

  reply	other threads:[~2026-09-24 16:44 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-24 16:29 [PATCH v15 0/5] PCI/IOV: Fix SR-IOV locking races and AB-BA deadlocks Benjamin Block
2026-09-24 16:29 ` [PATCH v15 1/5] PCI/IOV: Make pci_lock_rescan_remove() reentrant and protect sriov_add_vfs/sriov_del_vfs Benjamin Block
2026-09-24 16:40   ` sashiko-bot
2026-09-24 16:29 ` [PATCH v15 2/5] PCI: Fix AB-BA deadlock between device_lock and pci_rescan_remove_lock in remove_store Benjamin Block
2026-09-24 16:38   ` sashiko-bot
2026-09-24 16:29 ` [PATCH v15 3/5] PCI: Move declaration of pci_rescan_remove_lock into public pci.h Benjamin Block
2026-09-24 16:35   ` sashiko-bot
2026-09-24 16:29 ` [PATCH v15 4/5] PCI: Provide lock guard for pci_rescan_remove_lock Benjamin Block
2026-09-24 16:34   ` sashiko-bot
2026-09-24 16:29 ` [PATCH v15 5/5] s390/pci: Fix circular/recursive deadlocks in PCI-bus and -device release Benjamin Block
2026-09-24 16:44   ` sashiko-bot [this message]
2026-09-25  5:20     ` Benjamin Block
2026-10-02 12:55   ` [PATCH v16 " Benjamin Block
2026-09-24 16:35 ` ✗ CI.checkpatch: warning for PCI/IOV: Fix SR-IOV locking races and AB-BA deadlocks Patchwork
2026-09-24 16:37 ` ✓ CI.KUnit: success " Patchwork
2026-09-24 17:46 ` ✓ Xe.CI.BAT: " Patchwork
2026-09-25  6:20 ` ✓ Xe.CI.FULL: " Patchwork
2026-10-02 13:02 ` ✗ CI.checkpatch: warning for PCI/IOV: Fix SR-IOV locking races and AB-BA deadlocks (rev2) Patchwork
2026-10-02 13:04 ` ✓ CI.KUnit: success " Patchwork

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=20260924164406.B7A151F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=bblock@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --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 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.