From: Sasha Levin <sashal@kernel.org>
To: stable@vger.kernel.org
Cc: "Mathias Nyman" <mathias.nyman@linux.intel.com>,
stable <stable@kernel.org>,
"Łukasz Bartosik" <ukaszb@chromium.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Sasha Levin" <sashal@kernel.org>
Subject: [PATCH 5.15.y 6/6] xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event
Date: Mon, 27 Oct 2025 14:42:52 -0400 [thread overview]
Message-ID: <20251027184252.639069-6-sashal@kernel.org> (raw)
In-Reply-To: <20251027184252.639069-1-sashal@kernel.org>
From: Mathias Nyman <mathias.nyman@linux.intel.com>
[ Upstream commit f3d12ec847b945d5d65846c85f062d07d5e73164 ]
DbC may add 1024 bogus bytes to the beginneing of the receiving endpoint
if DbC hw triggers a STALL event before any Transfer Blocks (TRBs) for
incoming data are queued, but driver handles the event after it queued
the TRBs.
This is possible as xHCI DbC hardware may trigger spurious STALL transfer
events even if endpoint is empty. The STALL event contains a pointer
to the stalled TRB, and "remaining" untransferred data length.
As there are no TRBs queued yet the STALL event will just point to first
TRB position of the empty ring, with '0' bytes remaining untransferred.
DbC driver is polling for events, and may not handle the STALL event
before /dev/ttyDBC0 is opened and incoming data TRBs are queued.
The DbC event handler will now assume the first queued TRB (length 1024)
has stalled with '0' bytes remaining untransferred, and copies the data
This race situation can be practically mitigated by making sure the event
handler handles all pending transfer events when DbC reaches configured
state, and only then create dev/ttyDbC0, and start queueing transfers.
The event handler can this way detect the STALL events on empty rings
and discard them before any transfers are queued.
This does in practice solve the issue, but still leaves a small possible
gap for the race to trigger.
We still need a way to distinguish spurious STALLs on empty rings with '0'
bytes remaing, from actual STALL events with all bytes transmitted.
Cc: stable <stable@kernel.org>
Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver")
Tested-by: Łukasz Bartosik <ukaszb@chromium.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/usb/host/xhci-dbgcap.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-dbgcap.c b/drivers/usb/host/xhci-dbgcap.c
index 86b1d1b84ed1d..8cd447b6c957d 100644
--- a/drivers/usb/host/xhci-dbgcap.c
+++ b/drivers/usb/host/xhci-dbgcap.c
@@ -880,7 +880,8 @@ static enum evtreturn xhci_dbc_do_handle_events(struct xhci_dbc *dbc)
dev_info(dbc->dev, "DbC configured\n");
portsc = readl(&dbc->regs->portsc);
writel(portsc, &dbc->regs->portsc);
- return EVT_GSER;
+ ret = EVT_GSER;
+ break;
}
return EVT_DONE;
@@ -940,7 +941,8 @@ static enum evtreturn xhci_dbc_do_handle_events(struct xhci_dbc *dbc)
break;
case TRB_TYPE(TRB_TRANSFER):
dbc_handle_xfer_event(dbc, evt);
- ret = EVT_XFER_DONE;
+ if (ret != EVT_GSER)
+ ret = EVT_XFER_DONE;
break;
default:
break;
--
2.51.0
prev parent reply other threads:[~2025-10-27 18:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-27 7:20 FAILED: patch "[PATCH] xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races" failed to apply to 5.15-stable tree gregkh
2025-10-27 18:42 ` [PATCH 5.15.y 1/6] xhci: dbc: Provide sysfs option to configure dbc descriptors Sasha Levin
2025-10-27 18:42 ` [PATCH 5.15.y 2/6] xhci: dbc: poll at different rate depending on data transfer activity Sasha Levin
2025-10-27 18:42 ` [PATCH 5.15.y 3/6] xhci: dbc: Allow users to modify DbC poll interval via sysfs Sasha Levin
2025-10-27 18:42 ` [PATCH 5.15.y 4/6] xhci: dbc: Improve performance by removing delay in transfer event polling Sasha Levin
2025-10-27 18:42 ` [PATCH 5.15.y 5/6] xhci: dbc: Avoid event polling busyloop if pending rx transfers are inactive Sasha Levin
2025-10-27 18:42 ` Sasha Levin [this message]
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=20251027184252.639069-6-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=mathias.nyman@linux.intel.com \
--cc=stable@kernel.org \
--cc=stable@vger.kernel.org \
--cc=ukaszb@chromium.org \
/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