[PATCH AUTOSEL 6.18-6.1] thunderbolt: xdomain: Notify peers after enumeration

[Sasha Levin <sashal@kernel.org>]

From: Milo Chen <cmh79479@gmail.com>

[ 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 <cmh79479@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

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 <cmh79479@gmail.com>` (author)
  - `Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>`
    (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