summaryrefslogtreecommitdiff
path: root/tools/lib/python/kdoc
diff options
context:
space:
mode:
authorSven Peter <sven@kernel.org>2026-08-29 10:08:36 +0200
committerMika Westerberg <mika.westerberg@linux.intel.com>2026-09-01 10:12:40 +0200
commit419fa32fa5bc2d7fb9d0d15d5630b1c1090808b3 (patch)
tree8e8f003f60857b19ec81b98982ca24682350d5ee /tools/lib/python/kdoc
parent1fd1f67c94d30889377bba774f032ec15e8b9299 (diff)
downloadlinux-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