From: sashiko-bot@kernel.org
To: "Fan Wu" <fanwu01@zju.edu.cn>
Cc: linux-hyperv@vger.kernel.org
Subject: Re: [PATCH net] net: mana: fix reset work race with device removal
Date: Thu, 06 Aug 2026 14:39:27 +0000 [thread overview]
Message-ID: <20260806143928.609441F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260805143812.220509-1-fanwu01@zju.edu.cn>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] The patch introduces a 10-second sleep while holding the device core lock (`device_lock`), which will block system PM and driver core operations.
Pre-existing issues:
- [High] Driver unbind unexpectedly triggers a full PCI bus rescan due to the `!gc` check.
--
--- Patch [1]: [PATCH net] net: mana: fix reset work race with device removal ---
commit 839c641df5112c8f696d580233f5a31b4e6686dd
Author: Fan Wu <fanwu01@zju.edu.cn>
net: mana: fix reset work race with device removal
The reset service work runs on the system workqueue and obtains the
GDMA context through PCI drvdata. It can race with device removal,
which frees the context, so this patch serializes mana_serv_reset()
with device removal by taking the PCI device lock.
> diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c b/drivers/net/ethernet/microsoft/mana/gdma_main.c
> --- a/drivers/net/ethernet/microsoft/mana/gdma_main.c
> +++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c
> @@ -591,15 +591,16 @@ static void mana_serv_fpga(struct pci_dev *pdev)
>
> static void mana_serv_reset(struct pci_dev *pdev)
> {
> - struct gdma_context *gc = pci_get_drvdata(pdev);
> + struct gdma_context *gc;
> struct hw_channel_context *hwc;
> int ret;
>
> + device_lock(&pdev->dev);
[Severity: High]
Does holding device_lock() here cause a regression by stalling system PM
and driver core operations?
mana_serv_reset() calls msleep(MANA_SERVICE_PERIOD * 1000) (which is a 10
second sleep) further down in this function:
mana_serv_reset() {
...
mana_gd_suspend(pdev, PMSG_SUSPEND);
msleep(MANA_SERVICE_PERIOD * 1000);
...
}
Because system suspend loops over all devices and sequentially acquires
device_lock, would a suspend attempt or a user-space unbind operation
unconditionally hang for up to 10 seconds while waiting for this lock?
> + gc = pci_get_drvdata(pdev);
> if (!gc) {
> /* Perform PCI rescan on device if GC is not set up */
> dev_err(&pdev->dev, "MANA service: GC not setup, rescanning\n");
> - mana_serv_rescan(pdev);
> - return;
> + goto rescan;
[Severity: High]
This is a pre-existing issue, but if mana_gd_remove() is called due to a
standard driver unbind, it clears drvdata. If a pending reset work then
executes, acquires the lock, and observes gc == NULL, it jumps to the rescan
label which forcefully removes the device and triggers a full PCI bus rescan.
Will this effectively defeat the user's attempt to unbind the driver and
disrupt the PCI topology?
> }
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260805143812.220509-1-fanwu01@zju.edu.cn?part=1
next prev parent reply other threads:[~2026-08-06 14:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 14:38 [PATCH net] net: mana: fix reset work race with device removal Fan Wu
2026-08-06 14:17 ` [EXTERNAL] " Haiyang Zhang
2026-08-06 14:39 ` sashiko-bot [this message]
2026-08-07 12:49 ` Simon Horman
-- strict thread matches above, loose matches on Subject: below --
2026-08-05 14:19 Fan Wu
2026-08-06 14:20 ` 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=20260806143928.609441F00A3D@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=fanwu01@zju.edu.cn \
--cc=linux-hyperv@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox