[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <F9DBABAD-ABF0-49AA-9A38-BD4D2BE78B94@oracle.com>
Date: Fri, 29 Aug 2025 18:44:51 +0000
From: Prakash Sangappa <prakash.sangappa@...cle.com>
To: 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>,
Mathieu Desnoyers <mathieu.desnoyers@...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 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.
-Prakash
>
> Thanks,
>
> tglx
>
Powered by blists - more mailing lists