Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp8036854ybi; Thu, 6 Jun 2019 05:47:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqwyZQZzjwkarQEViFt9WM1njBcQuwMxx59kKeq45bn8teaoL0nhMtxxcTM8v+iBRe+GUX0i X-Received: by 2002:a17:902:76c3:: with SMTP id j3mr24857068plt.116.1559825244939; Thu, 06 Jun 2019 05:47:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559825244; cv=none; d=google.com; s=arc-20160816; b=g1kM7e2h3WAlZhGADVl9rj6uqgSRSONEwGZ5jeqaQ0JS6Mc7Q0QVzxLI5vC57AckSM M3Y64zqbdUhSxsdlgi6tKqtx4eFNc9zYJ6IYbOblZKW0kckwho/Dt2QZOQxdhCUCEJVf lw2c88LRIxviHCYDrBq7FdaKkI6mc6mEDNCg0aGbtsLB6AylqhN1uWXul/LcPmvwxdNI OgpZekPAuABIwxP0IOnrHYCgkrOsRoKirTPGr0y60VAuHZco40l5p2TRW3B5ilrVtmh8 4DP2VTp4J1O89bcFMjEzDebiqIEKrfnMPw76N6Hb+pimAh9lFeWhoX9qkQagoiU8Sizh Wsmw== 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=yPTZnrvJWTGOJ93wVjhduB3IJbU80FR1NJ5kZ0dyHD8=; b=kikLn4zI5/qy6EesGexZAX/aM3NbMQfaK27cRfaNGZZ3MzJwTt8SDxMWBPc2Gpyu/i 3FxX0DsN285XWfVrAV79S1pezEy3AgLGS4wpx95jQ2kzfGlZetxpx1Vf7IMkbKE18ngK iMgG9Adt18t643+wMJ1gIx3Ityog1kO8l0sYBhaGf/GCWgMFUMkypy1mms8delgGWC+o +GMmHMMSjdb2hSKgDIGIiHp9Br6JfPV/1PWOR0t9w9889FnQX5jtF1JFZvTWDMPrVYhw NUGHPG0Id+hwxJfAC5T9UTPHxUKEQSzS7/MxRK8AdbfVndPE7Ou4I0xe9kvL9muqYbg6 Ynfg== 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 u10si1762483pjr.102.2019.06.06.05.47.06; Thu, 06 Jun 2019 05:47:24 -0700 (PDT) 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 S1728693AbfFFL5s (ORCPT + 99 others); Thu, 6 Jun 2019 07:57:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56562 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727290AbfFFL5r (ORCPT ); Thu, 6 Jun 2019 07:57:47 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3B8B92F8BDE; Thu, 6 Jun 2019 11:57:33 +0000 (UTC) Received: from oldenburg2.str.redhat.com (dhcp-192-180.str.redhat.com [10.33.192.180]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 476E2619CB; Thu, 6 Jun 2019 11:57:25 +0000 (UTC) From: Florian Weimer To: Mathieu Desnoyers Cc: carlos , 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 Subject: Re: [PATCH 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v10) References: <20190503184219.19266-1-mathieu.desnoyers@efficios.com> <140718133.18261.1559144710554.JavaMail.zimbra@efficios.com> <2022553041.20966.1559249801435.JavaMail.zimbra@efficios.com> <875zprm4jo.fsf@oldenburg2.str.redhat.com> <732661684.21584.1559314109886.JavaMail.zimbra@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> Date: Thu, 06 Jun 2019 13:57:23 +0200 Message-ID: <87wohzorj0.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 06 Jun 2019 11:57:47 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Mathieu Desnoyers: > Should we plan ahead for such scheme to override which library "owns" rseq > registration from a LD_PRELOAD library ? If so, then we would want glibc to > set __rseq_handled _after_ LD_PRELOAD ctors are executed. I don't think so. The LD_PRELOAD phase is not clearly delineated from the non-preload phase. So it's not clear to me what this would even mean in practice. 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. >> The final remaining case is static dlopen. There is a copy of ld.so on >> the dynamic side, but it is completely inactive and has never run. I do >> not think we need to support that because multi-threading does not work >> reliably in this scenario, either. However, we should skip rseq >> registration in a nested libc (see the rtld_active function). > > So for SHARED, if (!rtld_active ()), we should indeed leave the state of > __rseq_handled as it is, because we are within a nested inactive ld.so. I think we should add __rseq_handled initialization to ld.so, so it will only run once, ever. It's the registration from libc.so which needs some care. In particular, we must not override an existing registration. Thanks, Florian