Re: [PATCH] rseq: don't promote transient TLS faults to SIGSEGV

[Mathieu Desnoyers]

On 2026-06-07 22:15, Yuanhe Shu wrote:
> With oom_score_adj=-1000 the OOM killer finds no killable task, so the
> rseq SIGSEGV is the sole outcome; otherwise the rseq SIGSEGV can be
> delivered before the OOM killer queues SIGKILL, and the process exits
> 139 instead of 137, breaking OOMKilled detection in container
> runtimes
As Peter and Thomas said, this is not transient. We simply cannot return
to userspace with an out-of-date value.

It looks like an issue with the choice of which signal should be
delivered in priority: rseq force signal enqueues SIGSEGV, and you
would expect the OOM killer to issue SIGKILL, and somehow it's the
forced SIGSEGV that wins.

Perhaps look into fixing that instead if you really care about which
signal is emitted ? (and that's a big _if_)

Thanks,

Mathieu

--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com