[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <9fd284e6-f3aa-456b-b91d-44d4ff5c55b1@efficios.com>
Date: Fri, 29 Aug 2025 14:50:54 -0400
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: Prakash Sangappa <prakash.sangappa@...cle.com>,
Thomas Gleixner <tglx@...utronix.de>
Cc: 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 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.
Thanks,
Mathieu
>
> -Prakash
>
>>
>> Thanks,
>>
>> tglx
>>
>
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
Powered by blists - more mailing lists