tree 76e34ae02308219afc24c7ec3594f5e926c81173
parent 5a096a74b8e306a2938fe38ec22b3a53e512de3f
author Aurelien DARRAGON <adarragon@haproxy.com> 1715949170 +0200
committer Aurelien DARRAGON <adarragon@haproxy.com> 1715954851 +0200

BUG/MEDIUM: thread/sched: set proper scheduling context upon ha_set_tid()

Adapting 1a9c922b ("REORG: thread/sched: move the task_per_thread stuff
to thread_ctx") noteworthy changes for 2.4. Indeed, since e3957f83
("BUG/MAJOR: lua: use task_wakeup() to properly run a task once")
using register_task() from script loaded via lua-load-per-thread
is broken due to the task being scheduled in the wrong queue (queue
from thread id 0 instead of tid thread's own queue). The result is
that process_runnable_tasks() loops forever, and the wathdog eventually
kicks in to crash the process.

Here is a simple reproducer:

  global
    lua-load-per-thread foo.lua
  listen dummy
    bind localhost:9999

foo.lua:

  core.register_task(function()
    print("ok")
  end)

$> ./haproxy -f repro.conf
  [WARNING]  (101526) : config : missing timeouts for proxy 'dummy'.
     | While not properly invalid, you will certainly encounter various problems
     | with such a configuration. To fix this, please ensure that all following
     | timeouts are set to a non-zero value: 'client', 'connect', 'server'.
  ok
  Thread 1 is about to kill the process.
  *>Thread 1 : id=0x7bbbaeb4de80 act=1 glob=0 wq=0 rq=1 tl=0 tlsz=0 rqsz=1
               stuck=1 prof=0 harmless=0 wantrdv=0
               cpu_ns: poll=0 now=2045862232 diff=2045862232
               curr_task=0
               call trace(14):
               | 0x7bbbae442520 [48 c7 c0 0f 00 00 00 0f]: libc:+0x42520
               | 0x63b9e9fd454c [48 83 f8 01 0f 84 25 03]: process_runnable_tasks+0x33c/0x81d
    Thread 2 : id=0x7bbbae3ff640 act=0 glob=0 wq=0 rq=0 tl=0 tlsz=0 rqsz=0
               stuck=0 prof=0 harmless=1 wantrdv=0
               cpu_ns: poll=0 now=4545006 diff=4545006
               curr_task=0

Since that, the issue was self-corrected by 1a9c922b, but this latter
commit didn't make it up to 2.4 (first appears in 2.5), which makes 2.4
the very last version affected by this bug.

This patch has no upstream id as it was specifically written for 2.4.