From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 600461F55A for ; Fri, 21 Feb 2020 16:14:00 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type :content-transfer-encoding; q=dns; s=default; b=U2MdZPUlZ8lzpWqG F/qbFDp2VIKYQdwFs/FjMzVshwBZ1aFXjREXFV4hXy7FEgcvx5yuZT0xf+7AHTXL ya3xLBk4q3eE2a1OsGDME5/bdJyZB+aiomMJADdRBwY0L+YdhOMnezjjjeXPbPul 3H2Huw0/y9DTjljvlEh7WumPKJA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type :content-transfer-encoding; s=default; bh=7S9Uk4B+ao6BWNiWZOQpNS 9Nn68=; b=O9XqJwyD8tFARmcTQ+OPtNQLafQfyQvv84NdyXrH7yze+iLchulOD1 RAg/Z9nDka3UYiaehEFzm9x79VumlBZZK/CcjyNUzRerqKBxBdqzblkZ+3XQv8fX EHSpje1zHP7qyWQdqBIENCZnCpVrGlUoZIzHB9kmJWGukUpB+yDL8= Received: (qmail 81941 invoked by alias); 21 Feb 2020 16:13:57 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 81822 invoked by uid 89); 21 Feb 2020 16:13:56 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail.efficios.com DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com C6C87260D14 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1582301632; bh=i4/JFZqxh7npdYYNKOpTF3g1l9o9iVzv8QM5fojaOrI=; h=Date:From:To:Message-ID:MIME-Version; b=Gys2M1rU74CRMa9I8KyccloZP+O06an3jwOZPqUTluNw2w6+o4WyspM9OUPjmLwpQ Y3aojss2NXEjuVtHpW71dxAgp2QRL5gdON7VJ3ZxPHnqUXz7fHLKg2GlCmOXIec7Eu tOgo2xfMyVtvJzRnoSZE7y7w17RplS2PY/AFPMkZcc0Gm5h8ZK3/11RPOcVX8xFeaC 8UuLsbSr3eDAGxR5DVuRaTiDfQek1UI2brAe0q/Ns9qlUoseknspPnbNwNtGSUZxFa 2dJlf+VtN1RlTq/GZrUapPAo0WWt35iGNJCdmON8CqVs0TgqybA3GeIXQbrGFh8kTd RGTfvOlB7Z3Rg== Date: Fri, 21 Feb 2020 11:13:52 -0500 (EST) From: Mathieu Desnoyers To: "Joel Fernandes, Google" Cc: Chris Kennelly , Paul Turner , Florian Weimer , Carlos O'Donell , libc-alpha , linux-kernel , Peter Zijlstra , paulmck , Boqun Feng , Brian Geffon Message-ID: <1683022606.3452.1582301632640.JavaMail.zimbra@efficios.com> In-Reply-To: <20200221154923.GC194360@google.com> References: <1503467992.2999.1582234410317.JavaMail.zimbra@efficios.com> <20200221154923.GC194360@google.com> Subject: Re: Rseq registration: Google tcmalloc vs glibc MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- On Feb 21, 2020, at 10:49 AM, Joel Fernandes, Google joel@joelfernandes.org wrote: [...] >> >> 3) Use the __rseq_abi TLS cpu_id field to know whether Rseq has been >> registered. >> >> - Current protocol in the most recent glibc integration patch set. >> - Not supported yet by Linux kernel rseq selftests, >> - Not supported yet by tcmalloc, >> >> Use the per-thread state to figure out whether each thread need to register >> Rseq individually. >> >> Works for integration between a library which exists for the entire lifetime >> of the executable (e.g. glibc) and other libraries. However, it does not >> allow a set of libraries which are dlopen'd/dlclose'd to co-exist without >> having a library like glibc handling the registration present. > > Mathieu, could you share more details about why during dlopen/close > libraries we cannot use the same __rseq_abi TLS to detect that rseq was > registered? Sure, A library which is only loaded and never closed during the execution of the program can let the kernel implicitly unregister rseq at thread exit. For the dlopen/dlclose use-case, we need to be able to explicitly unregister each thread's __rseq_abi which sit in a library which is going to be dlclose'd. The issue is that __rseq_abi.cpu_id does not track any reference counting of rseq user libraries, which becomes an issue if we have many of those libraries around with different life-time. As an example scenario, let's suppose we have a single-threaded application which does the following: main() dlopen(liba) -> liba's constructor observes uninitialized __rseq_abi.cpu_id, thus performs rseq registration dlopen(libb) -> libb's constructor observes that rseq is already registered. dlclose(libb) -> libb's destructor unregisters rseq. -> at this point, liba is still loaded, and would still expect rseq to be registered. But unfortunately rseq has been unregistered by libb. dlclose(liba) -> rseq is already unregistered, which is unexpected. The TLS __rseq_refcount solves this by tracking the number of users of rseq for the thread, so rseq is only unregistered when the very last user decrements the reference count. As soon as there is at least one library taking care of registering rseq for the entire thread's duration (e.g. glibc), and that this library guarantees to never be dlclose'd, the __rseq_refcount becomes unneeded. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com