From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathieu Desnoyers Subject: Re: [PATCH 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v10) Date: Fri, 14 Jun 2019 06:03:04 -0400 (EDT) Message-ID: <802638054.3032.1560506584705.JavaMail.zimbra@efficios.com> References: <20190503184219.19266-1-mathieu.desnoyers@efficios.com> <87muj2k4ov.fsf@oldenburg2.str.redhat.com> <1528929896.22217.1559326257155.JavaMail.zimbra@efficios.com> <87o93d4lqb.fsf@oldenburg2.str.redhat.com> <117220011.27079.1559663870037.JavaMail.zimbra@efficios.com> <87wohzorj0.fsf@oldenburg2.str.redhat.com> <914051741.43025.1560348011775.JavaMail.zimbra@efficios.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <914051741.43025.1560348011775.JavaMail.zimbra@efficios.com> Sender: linux-kernel-owner@vger.kernel.org To: carlos , Florian Weimer Cc: Joseph Myers , Szabolcs Nagy , libc-alpha , Thomas Gleixner , Ben Maurer , Peter Zijlstra , "Paul E. McKenney" , Boqun Feng , Will Deacon , Dave Watson , Paul Turner , Rich Felker , linux-kernel , linux-api List-Id: linux-api@vger.kernel.org ----- On Jun 12, 2019, at 4:00 PM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote: > ----- On Jun 10, 2019, at 4:43 PM, carlos carlos@redhat.com wrote: > >> On 6/6/19 7:57 AM, Florian Weimer wrote: >>> Let me ask the key question again: Does it matter if code observes the >>> rseq area first without kernel support, and then with kernel support? >>> If we don't expect any problems immediately, we do not need to worry >>> much about the constructor ordering right now. I expect that over time, >>> fixing this properly will become easier. >> >> I just wanted to chime in and say that splitting this into: >> >> * Ownership (__rseq_handled) >> >> * Initialization (__rseq_abi) >> >> Makes sense to me. >> >> I agree we need an answer to this question of ownership but not yet >> initialized, to owned and initialized. >> >> I like the idea of having __rseq_handled in ld.so. > > Very good, so I'll implement this approach. Sorry for the delayed > feedback, I am traveling this week. I had issues with cases where application or LD_PRELOAD library also define the __rseq_handled symbol. They appear not to see the same address as the one initialized by ld.so. I tried using the GL() macro in ld.so to set __rseq_handled, but it's the wrong address compared to what the preload lib and application observe. Any thoughts on how to solve this ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com