Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp493438imu; Tue, 11 Dec 2018 02:42:19 -0800 (PST) X-Google-Smtp-Source: AFSGD/XxwaNuo5Td3zhOEGTdvQG+GD8mf/wdJ6PGws5Y1mPR8kHwPOfcBkq3EDz84LKhaw67VnJR X-Received: by 2002:a62:8985:: with SMTP id n5mr16088002pfk.255.1544524939106; Tue, 11 Dec 2018 02:42:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544524939; cv=none; d=google.com; s=arc-20160816; b=SxyJnTjPbTV4FIxSRuz7fYTwaL/S8HB6sC5Mtpthy6WPUQZXwqNKod7IgaTvmJkqsM N8i3v0bMixkuS+7go5ICxu32jDIBEh+yK+w32sHtlBQIOrDokat7WTPYb28CNLFlOINC RJt1thdrUt9+XC3f8u/EE93Atm1SZHCygiKlGsgcbzzgVYwOkOP2VU95vxHPLsu3np/J GW4UTDbNrXRTyrvCpLNXEvh4oSZ7MfzD56KDOpXdeSi3bsR18JY5JtCfEqzViJX85x7C wpS2x7fu2rk6bLTOMZs1jdpvG3oLNkEOV5UlxkaIMBvfJu2joxZ8tIsU+03oc94WwUDn oetA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id:date :references:subject:cc:to:from; bh=VF8l/OvQHZsetLk9e/MzwZApQNDC+zICMuDghtH5Bk4=; b=RsBl8Sv/wmxsgn+2rV1TY7UB+YLkRT8RVgT25h1VzxI1e/CqdIoy2Bf6At9hdlpMta VW/fcaAnQ/3X6xxmPbaUjXrnmrZ7kLirp+b9e6WXBocyLWO3HtS8185y095jppYB0YIq fqCXx1mt2PiehFRKpcoiAs5qU/7Up5GkWgvKCAe+sHxFUf9HZaTWJ382HvRNhhPOwk82 9u33VwPwxEYYWEi2hcQ0A6GvDJ+va9ERUPiy55+A9tRVWV/AUMWcGN5o0UGeTvQwcxhM ywj6fxO8FaAKmqJm1vPvH7mbd0IqGyK8ftq14voR+tq9LdkOgOeqQLYfCntKpcFvZLFZ nYkg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c1si9432652pld.194.2018.12.11.02.42.00; Tue, 11 Dec 2018 02:42:19 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726387AbeLKKkc (ORCPT + 99 others); Tue, 11 Dec 2018 05:40:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47592 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726114AbeLKKkb (ORCPT ); Tue, 11 Dec 2018 05:40:31 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0FC2D3082E52; Tue, 11 Dec 2018 10:40:31 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-116-82.ams2.redhat.com [10.36.116.82]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CF0005D964; Tue, 11 Dec 2018 10:40:24 +0000 (UTC) From: Florian Weimer To: Mathieu Desnoyers Cc: Carlos O'Donell , Joseph Myers , Szabolcs Nagy , libc-alpha@sourceware.org, Thomas Gleixner , Ben Maurer , Peter Zijlstra , "Paul E. McKenney" , Boqun Feng , Will Deacon , Dave Watson , Paul Turner , Rich Felker , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org Subject: Re: [RFC PATCH glibc 1/4] glibc: Perform rseq(2) registration at nptl init and thread creation (v4) References: <20181204192141.4684-1-mathieu.desnoyers@efficios.com> Date: Tue, 11 Dec 2018 11:40:22 +0100 Message-ID: <87h8fkz6qx.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Tue, 11 Dec 2018 10:40:31 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Mathieu Desnoyers: > I want to keep the __rseq_refcount symbol so out-of-libc users can > register rseq if they are linked against a pre-2.29 libc. Sorry, I was confused. > diff --git a/csu/Makefile b/csu/Makefile > index 88fc77662e..81d471587f 100644 > --- a/csu/Makefile > +++ b/csu/Makefile > @@ -28,7 +28,7 @@ include ../Makeconfig > > routines = init-first libc-start $(libc-init) sysdep version check_fds \ > libc-tls elf-init dso_handle > -aux = errno > +aux = errno rseq > elide-routines.os = libc-tls > static-only-routines = elf-init > csu-dummies = $(filter-out $(start-installed-name),crt1.o Mcrt1.o) Do we plan to add Hurd support for this? > diff --git a/sysdeps/unix/sysv/linux/rseq-internal.h b/sysdeps/unix/sysv/linux/rseq-internal.h > new file mode 100644 > index 0000000000..2367926def > --- /dev/null > +++ b/sysdeps/unix/sysv/linux/rseq-internal.h > +#define RSEQ_SIG 0x53053053 What's this? This needs a comment. > +extern __thread volatile struct rseq __rseq_abi > +__attribute__ ((tls_model ("initial-exec"))); > + > +extern __thread volatile uint32_t __rseq_refcount > +__attribute__ ((tls_model ("initial-exec"))); The volatile qualifier needs justification in a comment. (Usually, volatile is wrong. and it is difficult to get rid of it.) We need to document these public symbols somewhere. There should be an installed header file. > diff --git a/nptl/Versions b/nptl/Versions > index e7f691da7a..f7890f73fc 100644 > --- a/nptl/Versions > +++ b/nptl/Versions > @@ -277,6 +277,10 @@ libpthread { > cnd_timedwait; cnd_wait; tss_create; tss_delete; tss_get; tss_set; > } > > + GLIBC_2.29 { > + __rseq_refcount; > + } Why put this into libpthread, and __rseq_abi into libc? What, exactly, is the benefit of having __rseq_refcount defined by glibc? Have you actually got this working? If an rseq library is linked against glibc 2.29, it will reference the GLIBC_2.29 symbol version, so it cannot be loaded by older glibcs. In this case, __rseq_refcount is not needed. If you build against pre-2.29, then the __rseq_refcount symbol will be unversioned. But then you don't need it glibc, either. So it seems to me that the addition to glibc is useless in both scenarios. Am I missing something? By the way, you could avoid the need for unregistration if you allocated the rseq areas persistently, index by TID. They are quite small, so with the typical PID range, maybe the wasted memory due to changing TIDs would be acceptable? I guess things would be so much easier if the kernel simply provided a means to obtain the address of a previously registered rseq area. Thanks, Florian