[Bug 219532] Crash in RIP: 0010:xhci_handle_stopped_cmd_ring

[bugzilla-daemon@kernel.org]

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

--- Comment #7 from Michał Pecio (michal.pecio@gmail.com) ---
No sensible way to handle it and it should never happen. All we could do is
print an error and return immediately, but in any such case the xHCI driver is
likely already FUBAR anyway.

I *hope* that you are mistaken and your crash was caused by dereferencing
xhci->current_cmd in the next line, due to cur_cmd being NULL. This is not
supposed to happen either, because the check for (xhci->cmd_ring->dequeue !=
xhci->cmd_ring->enqueue) is there exactly to catch cases when no commands are
pending and cur_cmd is expected to be NULL.

But it doesn't work for one in 255 commands, namely when the aborted command
was the last one in its ring segment. Then enqueue points at the subsequent
link TRB, while dequeue is already in the next segment. Until recently, such
command abort would have failed due to a different bug (and caused different
problems), but that other bug has just been fixed and it looks like we may
start seeing those NULL dereferences now.

This patch should keep your system from crashing *if* this is the problem that
you are running into. The driver should print "cur_cmd bug detected, 0 fff" and
continue working normally. (Which means, keep printing more of those "setup
device timed out".)

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

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