From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1DC53C43441 for ; Thu, 22 Nov 2018 18:35:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CE37020684 for ; Thu, 22 Nov 2018 18:35:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b="fPWiUwy2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CE37020684 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=efficios.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729019AbeKWFQV (ORCPT ); Fri, 23 Nov 2018 00:16:21 -0500 Received: from mail.efficios.com ([167.114.142.138]:51184 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726358AbeKWFQV (ORCPT ); Fri, 23 Nov 2018 00:16:21 -0500 Received: from localhost (ip6-localhost [IPv6:::1]) by mail.efficios.com (Postfix) with ESMTP id 47D51F192; Thu, 22 Nov 2018 13:35:45 -0500 (EST) Received: from mail.efficios.com ([IPv6:::1]) by localhost (mail02.efficios.com [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id IczP71d2Hqk2; Thu, 22 Nov 2018 13:35:44 -0500 (EST) Received: from localhost (ip6-localhost [IPv6:::1]) by mail.efficios.com (Postfix) with ESMTP id A6E58F18D; Thu, 22 Nov 2018 13:35:44 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com A6E58F18D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1542911744; bh=AKB1Quamzgrzad6pOHpLJ5UIN4zU/qAKHRcXBDCRDIU=; h=Date:From:To:Message-ID:MIME-Version; b=fPWiUwy25qfS+VWijvv/5euofWLZWj/srL61ulMi+BvjTaoJhDobrDfszM1pSy4jb vEOuePCrER4T/PZQnf5Q8iHXGVq1Vac15TypGxjgAO0FBoPodNe5lQ8W26tmnYniXU By3TKFtkRBketZS9D8hH1FiV1okhFo4C0xSazv7okD0sL0OPALxAOs93cG/4Oxl2d4 cta+R4Mvi82Wg36nFWa2Iar0yqXvPNfpdEN7RUf1kfhlM7l3Z5s1Z64kiwTK1+A/ka BQ3JTintF9X2bD5/R2Yb/d0dd2oIEJC78YMnYH6wogTOwpRcbMEoIRDfxWxdMgT8cX rz0sjZdopBEoA== X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([IPv6:::1]) by localhost (mail02.efficios.com [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id bmFeqodnYCvu; Thu, 22 Nov 2018 13:35:44 -0500 (EST) Received: from mail02.efficios.com (mail02.efficios.com [167.114.142.138]) by mail.efficios.com (Postfix) with ESMTP id 85C5DF17D; Thu, 22 Nov 2018 13:35:44 -0500 (EST) Date: Thu, 22 Nov 2018 13:35:44 -0500 (EST) From: Mathieu Desnoyers To: Szabolcs Nagy Cc: Florian Weimer , nd , Rich Felker , carlos , Joseph Myers , libc-alpha , Thomas Gleixner , Ben Maurer , Peter Zijlstra , "Paul E. McKenney" , Boqun Feng , Will Deacon , Dave Watson , Paul Turner , linux-kernel , linux-api Message-ID: <1602745030.10426.1542911744479.JavaMail.zimbra@efficios.com> In-Reply-To: <7032ab45-8314-b85d-5b4d-f83b41dab5b6@arm.com> References: <20181121183936.8176-1-mathieu.desnoyers@efficios.com> <20181122143603.GD23599@brightrain.aerifal.cx> <782067422.9852.1542899056778.JavaMail.zimbra@efficios.com> <87a7m1ywni.fsf@oldenburg.str.redhat.com> <20181122151710.GF23599@brightrain.aerifal.cx> <875zwpyw81.fsf@oldenburg.str.redhat.com> <1306224240.10055.1542900799576.JavaMail.zimbra@efficios.com> <7032ab45-8314-b85d-5b4d-f83b41dab5b6@arm.com> Subject: Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.142.138] X-Mailer: Zimbra 8.8.10_GA_3047 (ZimbraWebClient - FF52 (Linux)/8.8.10_GA_3041) Thread-Topic: glibc: Perform rseq(2) registration at nptl init and thread creation Thread-Index: AQHUgcmYxLh54Hb0r0GDFIJAvPiE/6Vb3dCAgAAH4gCAAAIt+4AAAW4AgAABKRSAAANagIAADmkAT4+EF7I= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Nov 22, 2018, at 11:24 AM, Szabolcs Nagy Szabolcs.Nagy@arm.com wrote: > On 22/11/18 15:33, Mathieu Desnoyers wrote: >> ----- On Nov 22, 2018, at 10:21 AM, Florian Weimer fweimer@redhat.com wrote: >>> Right, but in case of user-supplied stacks, we actually free TLS memory >>> at this point, so signals need to be blocked because the TCB is >>> (partially) gone after that. >> >> Unfortuntately, disabling signals is not enough. >> >> With rseq registered, the kernel accesses the rseq TLS area when returning to >> user-space after _preemption_ of user-space, which can be triggered at any >> point by an interrupt or a fault, even if signals are blocked. >> >> So if there are cases where the TLS memory is freed while the thread is still >> running, we _need_ to explicitly unregister rseq beforehand. > > i think the man page should point this out. Yes, I should add this to the proposed rseq(2) man page. > > the memory of a registered rseq object must not be freed > before thread exit. (either unregister it or free later) > > and ideally also point out that c language thread storage > duration does not provide this guarantee: it may be freed > by the implementation before thread exit (which is currently > not observable, but with the rseq syscall it is). How about the following wording ? Memory of a registered rseq object must not be freed before the thread exits. Reclaim of rseq object's memory must only be done after either an explicit rseq unregistration is performed or after the thread exit. Keep in mind that the implementation of the Thread-Local Storage (C language __thread) lifetime does not guarantee existence of the TLS area up until the thread exits. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com