From: Thomas Gleixner <tglx@kernel.org>
To: Yuanhe Shu <xiangzao@linux.alibaba.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Peter Zijlstra <peterz@infradead.org>
Cc: "Paul E . McKenney" <paulmck@kernel.org>,
Boqun Feng <boqun@kernel.org>,
linux-kernel@vger.kernel.org,
Yuanhe Shu <xiangzao@linux.alibaba.com>
Subject: Re: [PATCH] rseq: don't promote transient TLS faults to SIGSEGV
Date: Mon, 08 Jun 2026 11:15:32 +0200 [thread overview]
Message-ID: <87o6hl4cln.ffs@fw13> (raw)
In-Reply-To: <20260608021553.1037128-1-xiangzao@linux.alibaba.com>
On Mon, Jun 08 2026 at 10:15, Yuanhe Shu wrote:
> On return to user space the rseq slow path writes the new cpu_id /
> mm_cid into the user-space rseq TLS. rseq_update_usr() already
> classifies its failures in rseq_event::fatal: the flag is set only
> when corrupt user data is positively identified (e.g. a bad rseq_cs
> signature or an out-of-bounds abort IP) and stays clear when the
> access merely hit an unresolved page fault.
>
> rseq_slowpath_update_usr() ignores that and calls force_sig(SIGSEGV)
> on any failure, so a transient page fault on a still-registered rseq
> area becomes a fatal SIGSEGV. This is reachable since glibc >= 2.35
It's not transient.
rseq_slowpath_update_usr() does the full pagefault resolution, which
means if that returns without resolving the fault, then it's game over.
We also cannot return to user space in that case because the rseq area,
which is not accessible, has not been updated.
Thanks,
tglx
next prev parent reply other threads:[~2026-06-08 9:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 2:15 [PATCH] rseq: don't promote transient TLS faults to SIGSEGV Yuanhe Shu
2026-06-08 8:29 ` Peter Zijlstra
2026-06-08 9:15 ` Thomas Gleixner [this message]
2026-06-08 12:52 ` Mathieu Desnoyers
2026-06-08 22:20 ` Thomas Gleixner
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=87o6hl4cln.ffs@fw13 \
--to=tglx@kernel.org \
--cc=boqun@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=xiangzao@linux.alibaba.com \
/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