From: Thomas Gleixner <tglx@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>,
David Matlack <dmatlack@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Michael Jeanson <mjeanson@efficios.com>,
Jens Axboe <axboe@kernel.dk>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
"Paul E. McKenney" <paulmck@kernel.org>, X86 ML <x86@kernel.org>,
Sean Christopherson <seanjc@google.com>,
Wei Liu <wei.liu@kernel.org>
Subject: Re: SIGSEGVs after 39a167560a61 ("rseq: Optimize event setting")
Date: Mon, 26 Jan 2026 22:50:58 +0100 [thread overview]
Message-ID: <87zf60avr1.ffs@tglx> (raw)
In-Reply-To: <20260126204745.GP171111@noisy.programming.kicks-ass.net>
On Mon, Jan 26 2026 at 21:47, Peter Zijlstra wrote:
> On Mon, Jan 26, 2026 at 11:46:27AM -0800, David Matlack wrote:
>> I started seeing SIGSEGVs in Google's remote test executor when
>> running on hosts at v6.19-rc6. Bisecting led me to this commit:
>>
>> 39a167560a61 ("rseq: Optimize event setting")
>>
>> I discovered this issue while running VFIO selftests against v6.19-rc6,
>> but realized the issue has nothing to do with the selftests themselves.
>> Even running "sleep" as the test is enough to trigger this issue in the
>> executor.
>>
>> I know that Google uses rseq in its userspace software stack, so I
>> assume this is some bad interaction between that implementation and
>> commit 39a167560a61.
>>
>> Unfortunately, the remote test executor that is receiving the SIGSEGV is
>> not open source so I don't have a repro I can share. But I can easily
>> reproduce the issue with my setup so I'd be happy to help with testing
>> any fixes or debug patches.
>>
>> I've attached the .config that I used when reproducing this issue. The
>> host I am using is an Intel server with EMR CPUs in case that matters.
>
> Is this using tcmalloc? If so, that is somewhat expected because
> tcmalloc is known to violate upstream rseq ABI. IIRC you should get a
> nice splat if you enable rseq debug mode (echo 1 > /debug/rseq/debug).
The correctness of these changes has been validated by the rseq
selftests and I don't see how that commit would violate the guaranteed
ABI.
> Perhaps this is the nudge Google needs to go fix this.
The real question is whether the segfault is triggered from the rseq
sanity checks or if the application segfaults becauses it relies on
something something which is not guaranteed by the ABI. As this is
secret sauce, I can't tell.
Just for the record: I tried to build tcmalloc and get some tests done
with it, but the documentation is abysmal and I have no intention to
debug that bazel insanity.
Thanks,
tglx
next prev parent reply other threads:[~2026-01-26 21:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-26 19:46 SIGSEGVs after 39a167560a61 ("rseq: Optimize event setting") David Matlack
2026-01-26 20:47 ` Peter Zijlstra
2026-01-26 20:49 ` Peter Zijlstra
2026-01-26 21:50 ` Thomas Gleixner [this message]
2026-01-26 22:27 ` David Matlack
2026-01-26 22:35 ` Mathieu Desnoyers
2026-01-27 20:34 ` Mathieu Desnoyers
2026-01-28 8:54 ` Dmitry Vyukov
2026-01-28 11:28 ` Mathieu Desnoyers
2026-01-28 11:40 ` Dmitry Vyukov
2026-01-28 13:16 ` Thomas Gleixner
2026-02-02 7:11 ` Dmitry Vyukov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zf60avr1.ffs@tglx \
--to=tglx@kernel.org \
--cc=axboe@kernel.dk \
--cc=dmatlack@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mjeanson@efficios.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=seanjc@google.com \
--cc=wei.liu@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox