[linux-6.6.y] PCI: Fix PCIe unplug Enumeration Long Blocking Issue#1692
[linux-6.6.y] PCI: Fix PCIe unplug Enumeration Long Blocking Issue#1692leoliu-oc wants to merge 1 commit into
Conversation
When a USB4 device is inserted, a PCIe tunnel will be established. Then, the PCIe hierarchy within the USB4 device will be enumerated. If the device is suddenly unplugged during the enumeration process, it is possible that the function pci_find_next_ext_capability called when the PCI driver scans the PCIe extended capability may take a very long time, perhaps more than 20 seconds. Signed-off-by: LeoLiu-oc <leoliu-oc@zhaoxin.com>
Reviewer's guide (collapsed on small PRs)Reviewer's GuideAdds an early exit in pci_find_next_ext_capability() to avoid long blocking when a device disappears during PCIe extended capability enumeration by checking for an all-ones header value and returning immediately. Sequence diagram for pci_find_next_ext_capability early exit on unplugged devicesequenceDiagram
participant PciDriver
participant pci_find_next_ext_capability
participant PciDevice
PciDriver->>pci_find_next_ext_capability: pci_find_next_ext_capability(dev, start, cap)
activate pci_find_next_ext_capability
pci_find_next_ext_capability->>PciDevice: pci_read_config_dword(dev, pos, header)
alt header is 0xffffffff
pci_find_next_ext_capability-->>PciDriver: return 0
else header is valid
loop scan extended capabilities
pci_find_next_ext_capability->>PciDevice: pci_read_config_dword(dev, next_pos, header)
alt PCI_EXT_CAP_ID(header) == cap
pci_find_next_ext_capability-->>PciDriver: return pos
end
end
end
deactivate pci_find_next_ext_capability
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Hi @leoliu-oc. Thanks for your PR. I'm waiting for a deepin-community member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- Consider adding a brief comment explaining why a header of 0xffffffff indicates an unplugged device or invalid config space so future readers understand the reason for this early return.
- Instead of directly checking for 0xffffffff here, consider centralizing the unplugged/invalid config space detection (e.g., via pci_device_is_present() or a helper) so similar checks are consistent and reusable across PCIe capability walkers.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Consider adding a brief comment explaining why a header of 0xffffffff indicates an unplugged device or invalid config space so future readers understand the reason for this early return.
- Instead of directly checking for 0xffffffff here, consider centralizing the unplugged/invalid config space detection (e.g., via pci_device_is_present() or a helper) so similar checks are consistent and reusable across PCIe capability walkers.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
There was a problem hiding this comment.
Pull request overview
This PR hardens PCIe extended capability enumeration against devices that are unplugged mid-scan (e.g., during USB4 PCIe tunnel enumeration), preventing long stalls in pci_find_next_ext_capability() when config reads return an all-ones error response.
Changes:
- Abort extended capability traversal early when the capability header reads as
0xffffffff(error response for a non-responding/unplugged device).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| return 0; | ||
|
|
||
| while (ttl-- > 0) { | ||
| if (header == 0xffffffff) |
When a USB4 device is inserted, a PCIe tunnel will be established. Then, the PCIe hierarchy within the USB4 device will be enumerated. If the device is suddenly unplugged during the enumeration process, it is possible that the function pci_find_next_ext_capability called when the PCI driver scans the PCIe extended capability may take a very long time, perhaps more than 20 seconds.
Summary by Sourcery
Bug Fixes: