[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <B2B42839-864B-4146-A378-1CC3D15160E1@oracle.com>
Date: Mon, 1 Sep 2025 19:30:42 +0000
From: Prakash Sangappa <prakash.sangappa@...cle.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
CC: Thomas Gleixner <tglx@...utronix.de>, Florian Weimer <fweimer@...hat.com>,
Jens Axboe <axboe@...nel.dk>, LKML <linux-kernel@...r.kernel.org>,
Michael
Jeanson <mjeanson@...icios.com>,
Peter Zijlstra <peterz@...radead.org>,
"Paul
E. McKenney" <paulmck@...nel.org>,
Boqun Feng <boqun.feng@...il.com>, Wei Liu
<wei.liu@...nel.org>,
Sean Christopherson <seanjc@...gle.com>,
Samuel
Thibault <sthibault@...ian.org>
Subject: Re: BUG: rseq selftests and librseq vs. glibc fail
> On Aug 29, 2025, at 11:50 AM, Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:
>
> On 2025-08-29 14:44, Prakash Sangappa wrote:
>>> On Aug 18, 2025, at 10:13 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
>>>
>>> On Mon, Aug 18 2025 at 16:15, Florian Weimer wrote:
>>>> * Thomas Gleixner:
>>>>> It's trivial to reproduce. All it needs is to have in the source:
>>>>>
>>>>> __weak ptrdiff_t __rseq_offset;
>>>>>
>>>>> w/o even being referenced and creating a pthread. Reproducer below.
>>>>
>>>> Well, that's sort of expected. You can't define glibc symbols that are
>>>> not intended for interposition and expect things to work. It's kind of
>>>> like writing:
>>>>
>>>> int _rtld_global;
>>>>
>>>> That's going to fail rather spectaculary, too. We make an exception for
>>>> symbols that are not reserved (you can build in ISO C mode and define
>>>> open, close, etc., at least as long as you link to glibc only). But
>>>> __rseq_offset is a reserved name, so that is not applicable here.
>>>>
>>>> The real change here is GCC changing from -fcommon (which made a lot of
>>>> these things work in the past) to -fno-common.
>>>
>>> Thanks for the explanation!
>>>
>>> So the only way to make this actually work is to revert that commit and
>>> the folks who want to link that statically need to come up with:
>>>
>>> #ifdef _BUILD_STATICALLY
>>> extern ....
>>>
>>> #else
>>> ptr = dlsym(...);
>>> #endif
>>>
>>> or something daft like that. A proper function interface would avoid all
>>> that nonsense, but we can't have nice things or can we?
>> Could the rseq(2) syscall itself return the already registered rseq structure address?
>> Perhaps a new flag argument to the rseq(2) syscall to query the registered rseq address
>> or return the address of the already registered rseq structure when it fails to register a new one.
>> Application can call it when the call to register a rseq structure fails.
>
> There is a ptrace(2) PTRACE_GET_RSEQ_CONFIGURATION to achieve
> something similar. I don't know if a dependency on ptrace would
> be acceptable for that use-case though.
Can a thread call ptrace(PTRACE_GET_RSEQ_CONFIGURATION,..) on itself?
May be something similar can be added to rseq(2) .
Thanks,
-Prakash.
>
> Thanks,
>
> Mathieu
>
>
>
>> -Prakash
>>>
>>> Thanks,
>>>
>>> tglx
>>>
>
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> https://www.efficios.com
Powered by blists - more mailing lists