From: Willy Tarreau <w@1wt.eu>
Date: Tue, 25 Aug 2026 16:21:36 +0000 (+0200)
Subject: MEDIUM: threads: always abort when calling thread_isolated() under a lock
X-Git-Tag: v3.5-dev6~73
X-Git-Url: https://git.kaiwu.me/?a=commitdiff_plain;h=8e2fff8b39ff5bf271f64868ecc548ef7a3a5c69;p=haproxy.git

MEDIUM: threads: always abort when calling thread_isolated() under a lock

A bug was found in _sink_forward_io_handler() where we call
ring_dispatch_messages() under an unneeded look, and that one calls
thread_isolate() on first call. Needless to say that when we're unlucky
it really deadlocks.

There is never ever any valid case for calling thread_isolate() with a
lock held, and all such instances MUST be addressed. In addition we must
not call it under isolation either. Let's just add two BUG_ON() for this
that display exactly the problem so that next time a developer creates
such an accidental construct, it's instantly discovered.

All tests pass, but better not backport this, as it's essentially meant
to help developers, it would not bring any benefit to end users (the
watchdog just addresses this case as well one second later if this
happens).
---

diff --git a/src/thread.c b/src/thread.c
index 3a6efe482..24f7aa751 100644
--- a/src/thread.c
+++ b/src/thread.c
@@ -90,6 +90,9 @@ void thread_isolate()
 {
 	uint tgrp, thr;
 
+	BUG_ON(thread_isolated(), "thread_isolate() called recursively!");
+	BUG_ON(th_ctx->lock_level, "thread_isolate() called with a lock held!");
+
 	_HA_ATOMIC_OR(&tg_ctx->threads_harmless, ti->ltid_bit);
 	__ha_barrier_atomic_store();
 	_HA_ATOMIC_INC(&rdv_requests);