From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 774934D3BDF; Mon, 19 Oct 2026 13:56:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792418199; cv=none; b=QboJ/Qx1fokS/2eRJbsA25G2AfIjIwoTVtEKUG8d/An6wtQcAmShf15d2KcR19rUb60DPJQD2XTxET/ArMpy3wzyo9nJ1jNqnWiu3N0LcMXD53k0sfwFwFXv1foCDOJUBU/0vJzjv32X4me/ZWsV7Wb/2TRcwTC7zuoqUVkhOKM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792418199; c=relaxed/simple; bh=DGeyJUKNG/Zud4VeFVjsUaBEmqmQzHiz7nCp348GZvA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ueMkY7GzYE8vIpmFW3kaNFuFWrLZElm2dStCQe8Jrm6fpEaXnlH+ivCJeYoLPlGVKyjRIPbTLnwpWBlcDnTAnb0s4c6PvtxlTBGfSYoLCHS+0+E6aTEBB3CPvMs1G/TfCTuOfdeThLnyJy8wwwgKKbGDg9wXz8f4n6IvctYQbcw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HAZSqTT4; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HAZSqTT4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5D1881F000C6; Mon, 19 Oct 2026 13:56:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792418197; bh=ab8K1Llg3UAFspOW+KyCke1prYK5tm9fieHRIDRqQcE=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=HAZSqTT4SSHnZtvrc8unzgvs3tRVtEv2oYsaoPNkGNBAQYvCjCB+wCxzmhNqfUxIT Hu9URr83A5B5aeaAnHKCZx1q967VLLIIpPHSwrNB595LVyLBvpd4XxBd7P/GSCwSmZ Aa3UaHqeG9J43VfERhimebWN3mAtkdC6kUiPyv4CPnKCXK7C4Lxd7iZ7+TwglwHgF7 kUyRE1hmBBb9pM/Pm2IXAuaykK4jmNFtuxpWRs7JBNiQZjtnjeaVeEe2ocFLGRcQVa IlpGYbbJZ9NtC0Iae+RFOiDBicrNpZzwKO1whheAJQqyFSbPR843TV4boMdcjM5VW1 Nvt2Voe9baVLg== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Milo Chen , Mika Westerberg , Sasha Levin , andreas.noever@gmail.com, westeri@kernel.org, YehezkelShB@gmail.com, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH AUTOSEL 6.18-6.1] thunderbolt: xdomain: Notify peers after enumeration Date: Mon, 19 Oct 2026 09:46:12 -0400 Message-ID: <20261019135441.1420968-81-sashal@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20261019135441.1420968-1-sashal@kernel.org> References: <20261019135441.1420968-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.18.57 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Milo Chen [ Upstream commit e027dba038f0008df9bc9575f5c3e803e90636c6 ] Service drivers may register local XDomain properties while discovery is still in progress. This can cause the properties changed notification to be sent before the peer is ready to act on it. If the peer has already read the local property block before the service was registered, it may keep using the old property generation and miss the newly registered service. With ThunderboltIP this can leave the network service half-discovered after a warm reboot and the login request eventually times out. Queue another properties changed notification after the XDomain reaches ENUMERATED so the peer can re-read the final local properties. Signed-off-by: Milo Chen Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: The local tree is **7.3.0-rc4** (`v7.3-rc4-27-gf0100363d8c37`). The candidate is a one-line Thunderbolt XDomain handshake fix: after discovery reaches `ENUMERATED`, send another properties-changed notification so a peer can pick up services registered during discovery. That matches a real ThunderboltIP failure after warm reboot, and the surrounding helpers already exist here. --- ## PHASE 1: COMMIT MESSAGE FORENSICS **Step 1.1: PARSE THE SUBJECT LINE** - Record: `[thunderbolt: xdomain:] [Notify] [send properties-changed to peers once XDomain discovery reaches ENUMERATED]` **Step 1.2: PARSE ALL COMMIT MESSAGE TAGS** - Record: - `Signed-off-by: Milo Chen ` (author) - `Signed-off-by: Mika Westerberg ` (Thunderbolt maintainer; applied the patch) - No `Fixes:` - No `Reported-by:` / `Tested-by:` / `Reviewed-by:` / `Acked-by:` / `Link:` / `Cc: stable` - Absence of `Fixes:` / `Cc: stable` is expected for this review and is not a negative signal **Step 1.3: ANALYZE THE COMMIT BODY TEXT** - Record: - **Bug:** Service drivers may register local XDomain properties while discovery is still running. The properties-changed notification can go out before the peer can act on it. - **Symptom:** Peer keeps an old property generation and misses the new service. With ThunderboltIP, the network service stays half- discovered after a **warm reboot** and the **login request times out**. - **Root cause:** Notification is sent too early (during discovery); nothing is sent once the local host is fully enumerated. - **Fix:** Queue another properties-changed notification when the XDomain reaches `ENUMERATED`. - **Version info:** none in the message. **Step 1.4: DETECT HIDDEN BUG FIXES** - Record: Not a disguised cleanup. The message describes a concrete functional failure (ThunderboltIP login timeout) and a protocol-timing fix. --- ## PHASE 2: DIFF ANALYSIS **Step 2.1: INVENTORY THE CHANGES** - Record: - File: `drivers/thunderbolt/xdomain.c` (`+1 / -0`) - Function: `tb_xdomain_state_work()` - Scope: single-file, one-line surgical change **Step 2.2: UNDERSTAND THE CODE FLOW CHANGE** - Record: - **Before:** `XDOMAIN_STATE_PROPERTIES` success only sets `xd->state = XDOMAIN_STATE_ENUMERATED`. - **After:** same, then `tb_xdomain_queue_properties_changed(xd)`. - Path: successful remote property fetch at the end of XDomain discovery (normal path, not an error path). **Step 2.3: IDENTIFY THE BUG MECHANISM** - Record: - **Category:** logic / protocol handshake correctness (missed peer notification). - **Mechanism:** `tb_xdomain_queue_properties_changed()` already runs in `XDOMAIN_STATE_INIT` and after UUID. `tb_register_property_dir()` (used by `thunderbolt-net`) also notifies via `update_all_xdomains()`. If that happens while the peer is not ready, or after the peer already read the old block, the peer can stick on the old generation. There was no notify after local discovery finished. The new call reuses the existing notify helper at ENUMERATED so the peer re-reads the final block. **Step 2.4: ASSESS THE FIX QUALITY** - Record: - **Quality:** Obviously correct relative to the described race. It reuses `tb_xdomain_queue_properties_changed()`, which already sends `PROPERTIES_CHANGED_REQUEST` with retries. - **Minimal:** one call, no API/data-structure change. - **Regression risk:** Low for the intended case. Extra notifies are already part of the protocol; the receiver path in `tb_xdp_handle_request()` treats `PROPERTIES_CHANGED_REQUEST` as “re-run state work / re-read properties.” - **Noted risk (code-derived, not field-confirmed):** because `XDOMAIN_STATE_ENUMERATED` already re-enters `PROPERTIES` when a peer notify arrives, a successful re-read will now send another notify. Two Linux hosts both running this change could keep exchanging property updates. No follow-up revert/fix appears in this tree after the commit. Treat as theoretical unless proven in use. --- ## PHASE 3: GIT HISTORY INVESTIGATION **Step 3.1: BLAME THE CHANGED LINES** - Record: - Surrounding state machine: `8e1de7042596ab` (“thunderbolt: Add support for XDomain lane bonding”, 2022-05-05), first in **v5.19-rc1**. - Notify helper and INIT/UUID notify sites: same commit. - The added line is this candidate (`e027dba038f000`, Milo Chen, 2026-06-24). - XDomain discovery protocol itself: `d1ff70241a275` (2017), **v4.15-rc1**. **Step 3.2: FOLLOW THE FIXES: TAG** - Record: No `Fixes:` tag. Not applicable. The missing notify at ENUMERATED dates to the 5.19 state machine. **Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES** - Record: - Related: `abc27e5bfed2f` (“Allow service drivers to specify their own properties”) — extra per-service properties, not required for this one-line call. - `308092d080852` (“Restart XDomain discovery handshake after failure”) — nearby error-path change; not a prerequisite. - Standalone. Not `patch X/Y`. **Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS** - Record: Milo Chen has only this thunderbolt commit here. Applied by **Mika Westerberg**, Thunderbolt maintainer. **Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS** - Record: Depends only on `tb_xdomain_queue_properties_changed()` and `XDOMAIN_STATE_ENUMERATED`, both present since 5.19. Applies standalone. --- ## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH **Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION** - Record: - `b4 dig -c e027dba038f000…` → https://patch.msgid.link/20260624060909.2610434-1-cmh79479@gmail.com - **v1:** `[PATCH] thunderbolt: xdomain: notify peers after enumeration` (From: Rqirus) — https://patch.msgid.link/20260624011131.2532004-1-cmh79479@gmail.com - **v2:** same diff; changelog: “Use full name in From and Signed-off- by.” - Mika Westerberg on v2: **“Applied to thunderbolt.git/next, thanks!”** - No NAK. No request for `Cc: stable` in the saved thread. - lore.kernel.org HTTP fetch returned 403; discussion was recovered via `b4 dig -m`. **Step 4.2: CHECK WHO REVIEWED THE PATCH** - Record (`b4 dig -w`): To/Cc Mika Westerberg, Andreas Noever, Michael Jamet, Yehezkel Bernat, linux-usb, linux-kernel. Subsystem maintainers were on the original mail. Mika applied it. **Step 4.3: SEARCH FOR THE BUG REPORT** - Record: No bugzilla/syzbot/Link. The commit text is the bug report: ThunderboltIP half-discovered after warm reboot, login timeout. Severity from the author: networking service fails to complete discovery. **Step 4.4: CHECK FOR RELATED PATCHES AND SERIES** - Record: Single-patch series (v1→v2, identical diff). Not part of a multi-patch set. **Step 4.5: CHECK STABLE MAILING LIST HISTORY** - Record: Web search of lore.kernel.org/stable for this subject returned no relevant hits. **UNVERIFIED** that nobody asked for it on stable@; no evidence it was rejected either. --- ## PHASE 5: CODE SEMANTIC ANALYSIS **Step 5.1: IDENTIFY KEY FUNCTIONS** - Record: `tb_xdomain_state_work()` modified; calls `tb_xdomain_queue_properties_changed()`; that queues `tb_xdomain_properties_changed()` → `tb_xdp_properties_changed_request()`. **Step 5.2: TRACE CALLERS** - Record: - `tb_xdomain_state_work` is delayed work started from `start_handshake()` / queue helpers; not a syscall. - `tb_xdomain_queue_properties_changed` call sites: INIT (no UUID needed), UUID success, and (after this patch) PROPERTIES success. - `tb_register_property_dir()` is called from `drivers/net/thunderbolt/main.c` (`tbnet_init`), `drivers/thunderbolt/stream.c`, `drivers/thunderbolt/dma_test.c`. **Step 5.3: TRACE CALLEES** - Record: Notify path allocates/sends an XDomain control packet with retries (`XDOMAIN_RETRIES`). Failure is logged; it does not unwind enumeration. **Step 5.4: FOLLOW THE CALL CHAIN** - Record: Reachable when two hosts do XDomain discovery over Thunderbolt/USB4 (cable/peer already present, including after warm reboot). Userspace does not need a special syscall; loading `thunderbolt-net` during boot vs in-progress discovery is the trigger. Config: `CONFIG_USB4` plus Thunderbolt networking. **Step 5.5: SEARCH FOR SIMILAR PATTERNS** - Record: Same notify is already used at INIT/UUID and when property dirs are registered. This fills the gap at end-of-discovery. No sibling drivers needed the same hunk. --- ## PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE **Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?** - Record: Yes. `drivers/thunderbolt/xdomain.c` has the PROPERTIES → ENUMERATED transition. Parent of the candidate only sets `xd->state = XDOMAIN_STATE_ENUMERATED` with no notify. ThunderboltIP registers `"network"` via `tb_register_property_dir()` in this tree. Bug class has been present since the 5.19 state machine; this tree is 7.3-rc4, so the code is in-scope. **Step 6.2: CHECK FOR BACKPORT COMPLICATIONS** - Record: Expected **clean apply**. Parent context around the hunk matches this tree’s pre-patch source. One added line, no helpers missing. **Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE** - Record: No other commit on this file addresses “notify after enumeration” or the ThunderboltIP warm-reboot miss. `abc27e5bfed2f` is a separate feature (per-service properties), not a substitute. --- ## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT **Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY** - Record: `drivers/thunderbolt/` (USB4/Thunderbolt). **IMPORTANT** for USB4/TBT hosts, **PERIPHERAL** relative to mm/VFS. Affects Thunderbolt XDomain and ThunderboltIP (`drivers/net/thunderbolt/`), not all machines. **Step 7.2: ASSESS SUBSYSTEM ACTIVITY** - Record: Actively maintained (Mika Westerberg). Recent xdomain work includes UAF and bounds fixes. Mature protocol with ongoing fixes; this is not staging. --- ## PHASE 8: IMPACT AND RISK ASSESSMENT **Step 8.1: DETERMINE WHO IS AFFECTED** - Record: Thunderbolt/USB4 hosts using XDomain, especially ThunderboltIP between two machines after warm reboot. Driver-specific / config- specific (`CONFIG_USB4`, thunderbolt-net). **Step 8.2: DETERMINE THE TRIGGER CONDITIONS** - Record: Warm reboot (or service driver registering properties during discovery). Timing-dependent. Unprivileged users do not trigger it via a random syscall; they hit it by using Thunderbolt networking. Common for that hardware/use case, rare globally. **Step 8.3: DETERMINE THE FAILURE MODE SEVERITY** - Record: ThunderboltIP discovery incomplete; login times out; network over Thunderbolt does not come up. Not a panic, UAF, or corruption. **Severity: HIGH for ThunderboltIP users, MEDIUM overall** (feature broken, host stays up). **Step 8.4: CALCULATE RISK-BENEFIT RATIO** - Record: - **Benefit:** Restores Thunderbolt networking after a realistic warm- reboot race. High for those users. - **Risk:** Very low line count; extra notify is an existing protocol message. Theoretical Linux↔Linux notify loop is unverified in the field; no revert in this tree. - **Ratio:** Benefit outweighs risk. --- ## PHASE 9: FINAL SYNTHESIS **Step 9.1: COMPILE THE EVIDENCE** **FOR backporting:** - Real user-visible bug: ThunderboltIP half-discovered, login timeout after warm reboot. - One-line, reuses an existing helper. - Maintainer (Mika Westerberg) applied it with no technical objections. - All needed symbols/state exist in this 7.3-rc4 tree (state machine since 5.19). - Applies cleanly; not a new API/feature. - Standalone; v2 only fixed the author’s From name. **AGAINST backporting:** - Not a crash, UAF, or security bug. - Affects a subset (USB4/TBT XDomain / ThunderboltIP). - No `Reported-by` besides the author’s scenario. - Theoretical extra notify traffic between two patched Linux peers (unverified in production). **UNRESOLVED:** - Could not fetch lore over HTTP (403); used `b4` mbox instead. - Mika’s v1 mail body was not in the saved v2 mbox; v2 changelog says the only change was the From/SOB name. - No stable@ thread found. **Step 9.2: APPLY THE STABLE RULES CHECKLIST** 1. Obviously correct and tested? **PASS** — one existing helper call; maintainer applied to thunderbolt.git/next. 2. Fixes a real bug that affects users? **PASS** — ThunderboltIP login timeout after warm reboot. 3. Important issue? **PASS** — service remains unusable (connectivity failure), not a panic; still a serious functional break for that hardware. 4. Small and contained? **PASS** — +1 line, one file. 5. No new features or APIs? **PASS**. 6. Can apply to the local tree? **PASS** — helpers and state machine are present; hunk context matches. **Step 9.3: CHECK FOR EXCEPTION CATEGORIES** - Record: None (not a device ID, quirk table, DT, build, or docs-only change). Qualifies as a normal small bugfix. **Step 9.4: DECISION** This tree has the buggy handshake. The patch is a minimal, maintainer- acked fix for a real ThunderboltIP discovery failure. That is appropriate to backport here. --- ### What the commit solves for this tree On 7.3-rc4, XDomain discovery still notifies peers early and service drivers (notably `thunderbolt-net`) can still register the `"network"` property directory while handshake is in progress. Without a notify at `ENUMERATED`, a peer that already read the old block can miss the service; ThunderboltIP then sits half-discovered and login times out after warm reboot. One extra `tb_xdomain_queue_properties_changed()` at the end of discovery closes that window. ### Stable rules The change is obviously correct, tiny, and does not add APIs. It fixes a real connectivity bug, not a refactor. ### Risk vs benefit Benefit is restoring Thunderbolt networking after reboot. Risk is one extra protocol notify on a path that already sends that message. Residual ping-pong risk between two Linux peers is unverified and did not produce a follow-up fix in this tree. ### Concerns No `Fixes:` tag (expected). Not a crash-class bug. Depends on Thunderbolt XDomain, which this tree has. No missing prerequisites. --- Verification: - [Phase 1] Parsed commit `e027dba038f0008df9bc9575f5c3e803e90636c6`: subject/body/SOBs only; no Fixes/Reported-by/Cc stable - [Phase 2] Diff: +1 line in `tb_xdomain_state_work()` after `xd->state = XDOMAIN_STATE_ENUMERATED` - [Phase 2] Confirmed existing notifies at INIT (line 1739) and UUID success (line 1751); `tb_register_property_dir()` calls `update_all_xdomains()` - [Phase 2] Confirmed `thunderbolt-net` `tbnet_init()` calls `tb_register_property_dir("network", tbnet_dir)` - [Phase 2] Receiver of `PROPERTIES_CHANGED_REQUEST` queues `state_work`; `ENUMERATED` re-enters `PROPERTIES` (verified in `xdomain.c`) - [Phase 3] `git blame`: state machine from `8e1de7042596ab` (v5.19-rc1); XDomain protocol from `d1ff70241a275` (v4.15-rc1) - [Phase 3] `git log --author="Milo Chen" -- drivers/thunderbolt/`: only this commit - [Phase 3] No later xdomain.c commit addresses this notify - [Phase 4] `b4 dig -c e027dba038f000…`: lore match https://patch.msgid.link/20260624060909.2610434-1-cmh79479@gmail.com - [Phase 4] `b4 dig -a`: v1 and v2; v2 identical diff, From-name fix only - [Phase 4] `b4 dig -w`: thunderbolt maintainers + linux-usb - [Phase 4] mbox: Mika Westerberg “Applied to thunderbolt.git/next, thanks!” - [Phase 4] WebFetch lore: 403; used b4 instead - [Phase 4] Stable-list search: no relevant hits - [Phase 5] Callers of `tb_register_property_dir`: thunderbolt-net, stream, dma_test (grep) - [Phase 5] semcode MCP: not available; used git grep/read - [Phase 6] `make kernelversion` / Makefile: 7.3.0-rc4; `git describe HEAD`: v7.3-rc4-27-gf0100363d8c37 - [Phase 6] Parent hunk lacks the notify; this tree has the helpers - [Phase 6] `git merge-base --is-ancestor e027dba038f000 HEAD`: ancestor (original commit in this development tree; not used as “already selected for stable”) - [Phase 7] MAINTAINERS: THUNDERBOLT DRIVER, Mika Westerberg - [Phase 8] Failure mode: ThunderboltIP login timeout / half-discovered service, not oops - UNVERIFIED: Mika v1 review body (not in v2 mbox); whether Linux↔Linux notify looping occurs in the field; whether stable@ ever discussed this patch **YES** drivers/thunderbolt/xdomain.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/thunderbolt/xdomain.c b/drivers/thunderbolt/xdomain.c index d9c2686b5fe41..b35e2f7c318dc 100644 --- a/drivers/thunderbolt/xdomain.c +++ b/drivers/thunderbolt/xdomain.c @@ -1692,6 +1692,7 @@ static void tb_xdomain_state_work(struct work_struct *work) tb_xdomain_failed(xd); } else { xd->state = XDOMAIN_STATE_ENUMERATED; + tb_xdomain_queue_properties_changed(xd); } break; -- 2.53.0