During the aborting of a command, the software receives a command
completion event for the command ring stopped, with the TRB pointing
to the next TRB after the aborted command.

If the command we abort is located just before the Link TRB in the
command ring, then during the 'command ring stopped' completion event,
the xHC gives the Link TRB in the event's cmd DMA, which causes a
mismatch in handling command completion event.

To address this situation, move the 'command ring stopped' completion
event check slightly earlier, since the specific command it stopped
on isn't of significant concern.

Fixes: 7f84eef0dafb ("USB: xhci: No-op command queueing and irq handler.")
Cc: stable@vger.kernel.org
Signed-off-by: Faisal Hassan <quic_faisalh@quicinc.com>
---

Changes in v3:
- Skip dma check for the cmd ring stopped event
- v2 link:
https://lore.kernel.org/all/20241021131904.20678-1-quic_faisalh@quicinc.com

Changes in v2:
- Added Fixes tag
- Removed traversing of TRBs with in_range() API.
- Simplified the if condition check.
- v1 link:
https://lore.kernel.org/all/20241018195953.12315-1-quic_faisalh@quicinc.com

 drivers/usb/host/xhci-ring.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index b2950c35c740..1ffc69c48eac 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1718,6 +1718,14 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
 
 	trace_xhci_handle_command(xhci->cmd_ring, &cmd_trb->generic);
 
+	cmd_comp_code = GET_COMP_CODE(le32_to_cpu(event->status));
+
+	/* If CMD ring stopped we own the trbs between enqueue and dequeue */
+	if (cmd_comp_code == COMP_COMMAND_RING_STOPPED) {
+		complete_all(&xhci->cmd_ring_stop_completion);
+		return;
+	}
+
 	cmd_dequeue_dma = xhci_trb_virt_to_dma(xhci->cmd_ring->deq_seg,
 			cmd_trb);
 	/*
@@ -1734,14 +1742,6 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
 
 	cancel_delayed_work(&xhci->cmd_timer);
 
-	cmd_comp_code = GET_COMP_CODE(le32_to_cpu(event->status));
-
-	/* If CMD ring stopped we own the trbs between enqueue and dequeue */
-	if (cmd_comp_code == COMP_COMMAND_RING_STOPPED) {
-		complete_all(&xhci->cmd_ring_stop_completion);
-		return;
-	}
-
 	if (cmd->command_trb != xhci->cmd_ring->dequeue) {
 		xhci_err(xhci,
 			 "Command completion event does not match command\n");
-- 
2.17.1

On 22.10.2024 18.56, Faisal Hassan wrote:
> During the aborting of a command, the software receives a command
> completion event for the command ring stopped, with the TRB pointing
> to the next TRB after the aborted command.
> 
> If the command we abort is located just before the Link TRB in the
> command ring, then during the 'command ring stopped' completion event,
> the xHC gives the Link TRB in the event's cmd DMA, which causes a
> mismatch in handling command completion event.
> 
> To address this situation, move the 'command ring stopped' completion
> event check slightly earlier, since the specific command it stopped
> on isn't of significant concern.
> 
> Fixes: 7f84eef0dafb ("USB: xhci: No-op command queueing and irq handler.")
> Cc: stable@vger.kernel.org
> Signed-off-by: Faisal Hassan <quic_faisalh@quicinc.com>

Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>

Greg, would you like to take this directly to usb-linus (6.12)?
If not I'll send it as part of series to usb-next later

Thanks
Mathias

On Thu, Oct 24, 2024 at 05:06:44PM +0300, Mathias Nyman wrote:
> On 22.10.2024 18.56, Faisal Hassan wrote:
> > During the aborting of a command, the software receives a command
> > completion event for the command ring stopped, with the TRB pointing
> > to the next TRB after the aborted command.
> > 
> > If the command we abort is located just before the Link TRB in the
> > command ring, then during the 'command ring stopped' completion event,
> > the xHC gives the Link TRB in the event's cmd DMA, which causes a
> > mismatch in handling command completion event.
> > 
> > To address this situation, move the 'command ring stopped' completion
> > event check slightly earlier, since the specific command it stopped
> > on isn't of significant concern.
> > 
> > Fixes: 7f84eef0dafb ("USB: xhci: No-op command queueing and irq handler.")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Faisal Hassan <quic_faisalh@quicinc.com>
> 
> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
> 
> Greg, would you like to take this directly to usb-linus (6.12)?
> If not I'll send it as part of series to usb-next later

Sure, I'll take it now, thanks.

greg k-h