diff options
| author | Sven Peter <sven@kernel.org> | 2026-08-29 10:08:36 +0200 |
|---|---|---|
| committer | Mika Westerberg <mika.westerberg@linux.intel.com> | 2026-09-01 10:12:40 +0200 |
| commit | 419fa32fa5bc2d7fb9d0d15d5630b1c1090808b3 (patch) | |
| tree | 8e8f003f60857b19ec81b98982ca24682350d5ee /tools/lib/python/kdoc | |
| parent | 1fd1f67c94d30889377bba774f032ec15e8b9299 (diff) | |
| download | linux-next-419fa32fa5bc2d7fb9d0d15d5630b1c1090808b3.tar.gz linux-next-419fa32fa5bc2d7fb9d0d15d5630b1c1090808b3.zip | |
thunderbolt: Don't access a DP tunnel after its DPRX read was canceled
tb_dp_dprx_work() checks ->dprx_canceled before it takes tb->lock so it
misses a tb_dp_dprx_stop() that could not cancel the already running
work. It then polls the DPRX capabilities and runs the callback for a
tunnel that has already been torn down while the domain is suspending or
going away.
This can be hit by cancelling the DPRX read from outside the ordered
tb->wq: During suspend tb_disconnect_and_release_dp() does just this and
with a later patch tb_stop() will do it as well. The latter in combination
with the Apple NHI where the DPRX read never completed is how I hit
this.
Check the flag with tb->lock held instead and check it again in
tb_dp_tunnel_active() because the callback runs after the lock has been
dropped again.
Also clear the flag in tb_dp_dprx_start() so that it only ever describes
the work that is currently in flight.
Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously")
Cc: stable@vger.kernel.org
Signed-off-by: Sven Peter <sven@kernel.org>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Diffstat (limited to 'tools/lib/python/kdoc')
0 files changed, 0 insertions, 0 deletions
