From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Jonathan Gopel <jgopel@gmail.com>
Cc: andreas.noever@gmail.com, westeri@kernel.org,
YehezkelShB@gmail.com, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] thunderbolt: Do not RPM complete unrelated subtrees on unplug
Date: Mon, 5 Oct 2026 13:38:22 +0200 [thread overview]
Message-ID: <20261005113822.GL176164@black.igk.intel.com> (raw)
In-Reply-To: <20261004171404.448474-1-jgopel@gmail.com>
Hi,
On Sun, Oct 04, 2026 at 11:13:50AM -0600, Jonathan Gopel wrote:
> When a Thunderbolt device is unplugged, that switch and every switch
> subsequent to it on the bus device list is `complete()`d, not just its
> child devices. In the case of multiple domains, it may cause, eg, an
> attempt to `complete()` the uninitialized domain 1 root switch RPM
> completion on unplug of a switch from domain 0 (though ordering is not
> guaranteed numerically sorted).
>
> I initially noticed this issue on a Dell XPS9720 when the system would
> seem to sporadically not wake after unplugging a Thunderbolt dock. I
> tried multiple kernel versions including v7.2.7 and v7.3-rc4 to see if
> that resolved the issue, but the issue persisted. Eventually I found
> that I could consistently generate a kernel Oops reporting a page fault
> at 0xffff_ffff_ffff_fff8 on unplug from one side of the laptop and went
> bug hunting. I became suspicious of the `bus_for_each_dev()` walk that I
> ultimately ended up changing. To confirm this issue, I did an eBPF trace
> of `bus_for_each_dev()`, `complete_rpm()`, and `complete()` while
> unplugging in a variety of situations and found that an unplug from
> domain 0 tries to `complete_rpm()` domain 1's switch, whose RPM
> completion is not initialized and thus is holding a null wait-list
> pointer, triggering the page fault.
>
> Here are the key sections of that eBPF trace. Note that HEAD denotes the
> completion's own wait-list HEAD:
>
> ```
> RESCAN_ENTER domain=0
>
> COMPLETE rescan_domain=0 target=0-1 target_domain=0
> route=0x1 parent=0-0 unplugged=1
> COMPLETION done=0 head=HEAD next=HEAD prev=HEAD
>
> BUS_WALK domain=0 start=0-1 callback=complete_rpm
> CALLBACK_ENTER rescan_domain=0 dev=1-0 parent=domain1 is_switch=1
>
> COMPLETE rescan_domain=0 target=1-0 target_domain=1
> route=0x0 parent=domain1 unplugged=0
> COMPLETION done=0 head=HEAD next=0 prev=0
>
> complete+5
> complete_rpm+43
> bus_for_each_dev+133
> icm_free_unplugged_children+250
> icm_rescan_work+42
> ```
>
> This patch gates the `complete()` on an additional condition - that the
> Thunderbolt domain matches the domain of the device that was unplugged.
>
> I only have a single system with multiple Thunderbolt domains - the Dell
> XPS9720. I am consistently able to reproduce the Oops on that system.
> Since running with this patch, I have not seen the Oops reoccur. I have
> also tested it on a Thinkpad X1-Gen12, and that system boots and runs
> well with it, but it only has a single Thunderbolt domain, so it does
> not exercise the multi-domain failure case.
>
> Assisted by: LLM
> Signed-off-by: Jonathan Gopel <jgopel@gmail.com>
I dropped the Assisted-by per your previous email, did a couple of small
cosmetic changes to the patch, added Fixes and stable tags and applied to
thunderbolt.git/fixes, thanks!
next prev parent reply other threads:[~2026-10-05 11:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-04 2:26 [PATCH] thunderbolt: Do not RPM complete unrelated subtrees on unplug Jonathan Gopel
2026-10-04 12:02 ` Mika Westerberg
2026-10-04 17:11 ` Jonathan Gopel
2026-10-05 4:30 ` Mika Westerberg
2026-10-04 17:13 ` [PATCH v2] " Jonathan Gopel
2026-10-05 11:38 ` Mika Westerberg [this message]
2026-10-06 12:55 ` Jonathan Gopel
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=20261005113822.GL176164@black.igk.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=YehezkelShB@gmail.com \
--cc=andreas.noever@gmail.com \
--cc=jgopel@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=westeri@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.