[Bug 220272] Latent race condition in USB code unveiled with optimized memset_64.S

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=220272

--- Comment #18 from Marcus Seyfarth (m.seyfarth@gmail.com) ---
(In reply to Michał Pecio from comment #16)
> What if you disable and re-enable the whole USB bus?
> Based on your logs, this should do it:
> 
> echo 0000:00:14.0 > /sys/bus/pci/drivers/xhci_hcd/unbind
> echo 0000:00:14.0 > /sys/bus/pci/drivers/xhci_hcd/bind
> 
> Note that if you have a keyboard on this bus it will stop working. You may
> want to issue both commands at once: "echo xxxx ; echo yyyy".

I've just tested this and to my surprise, the mouse remained in a non-working
state. The keyboard turned off and on again and was usable before and after.

(In reply to Michał Pecio from comment #17)
> I also had a look at this LLM generated "report" and I can't see how the
> alleged issues are supposed to be real.
> 
> 1. Replacing wmb() with dma_wmb() possibly makes sense, though on x86 wmb()
> is stronger than dma_wmb() so it can't be the cause of your problem. Other
> PCI drivers made such change for performance rather than correctness.
> 
> 2. I'm not familiar with xhci->mutex use so no comment, but the alleged
> deadlock probably doesn't exist as there is no asynchronous completion
> callback here.
> 
> 3. Pedantry with no functional impact.
> 
> 4. The driver will abort a hanging command and signal the completion.
> 
> 5. We immediately return so we don't go to the out label. No bug.
> 
> 6. mutex != spinlock. No bug.
> 
> 7. I see no bug. No static analyzer was run so that part is made up.
> 
> 8. Doesn't matter if the value is zero.
> 
> 9. No arithmetic is done on this variable.

Thanks a lot for taking a look, even if only #1 ends up being worth of
consideration.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.