Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp5320564imm; Tue, 12 Jun 2018 06:12:25 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIc167BPozz2Lor30X+w6fhwsnUIym53BD2eHHpJJ1ONszA/GOR0NQ0kElzuP2iI1L6viSK X-Received: by 2002:a17:902:d90f:: with SMTP id c15-v6mr358865plz.65.1528809145621; Tue, 12 Jun 2018 06:12:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528809145; cv=none; d=google.com; s=arc-20160816; b=VCb9UFILf5hccHzpWy8FRVTrwy0DLssOBfkNo21SZGTO9grZWL916Wbyc1GtJVgs7i N4lrC9Y+DwaAgYUWd9rJA0OgPnt8JTPiCMgXsitrtRn4cUxLsWM0XDVX0g2uwvJfpkwo mIGyK2xL231PriIAFH0wuEN0IjJtDnaktssG92CkyF+zmPmaBkvxWgm8AVQtpqnsQzdj Cbja52IewoI4ZUjObZ+n4dFVyFoSa3WESeUNYL1a4m320QxkX1QPJb/aKam9ixA/+jBO vTXP0Z98G+Sx+JUtlNvns30+vfvFXhwlGHm2btcwrk306DWNA1QBDwYPuirRtax+f15N R2EA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=XdbsY/xFVtqfUIXSF/yURkfeTsABhP4nozSAPpSjsuE=; b=RZVigPe0D3YkXrc6kN6jcDJaxydnbqu5FTT4hB5UhlBANfwK1t+Yds7WUsfla1RlKm IQY8l00O7TUgrxgh49vhwm7qtQS0AXi+j5raHptfMINL7eDekp7hWhIlCcr9J0qW5WWh KxNBD7x+MXXx2YcpE1Sl3+5Pez7X2Xp1Q/bNSeqKjZTArkWVelHxfGcTSohJ+vV7Wqr3 N5y/HNk6GK7DxvB1xkP+UvA0zq6AbHQ23EVTTBcji4Bv5uvfTRRquj1ce7066Izh4WUF fZPV5amkVsP3mWqIHN5kShLNvD2rdiNqs0L7vKXa1msFIYeI+VifJ6jSq4Fe76JneQmz sPpg== 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 w16-v6si104075pgc.232.2018.06.12.06.12.11; Tue, 12 Jun 2018 06:12:25 -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 S1754325AbeFLNLm (ORCPT + 99 others); Tue, 12 Jun 2018 09:11:42 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:41980 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754289AbeFLNLl (ORCPT ); Tue, 12 Jun 2018 09:11:41 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 37D0D77885; Tue, 12 Jun 2018 13:11:41 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.36.118.41]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0B3897C42; Tue, 12 Jun 2018 13:11:35 +0000 (UTC) Subject: Re: Restartable Sequences system call merged into Linux To: Mathieu Desnoyers Cc: Carlos O'Donell , Peter Zijlstra , "Paul E. McKenney" , Boqun Feng , Thomas Gleixner , linux-kernel , libc-alpha References: <1084280721.10859.1528746558696.JavaMail.zimbra@efficios.com> <31fc101a-295b-067b-1a82-7e9e509fc92f@redhat.com> <305409897.10888.1528747473727.JavaMail.zimbra@efficios.com> From: Florian Weimer Message-ID: <091061df-3482-8762-30e4-feaf3417be11@redhat.com> Date: Tue, 12 Jun 2018 15:11:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <305409897.10888.1528747473727.JavaMail.zimbra@efficios.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Tue, 12 Jun 2018 13:11:41 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Tue, 12 Jun 2018 13:11:41 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'fweimer@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/11/2018 10:04 PM, Mathieu Desnoyers wrote: > ----- On Jun 11, 2018, at 3:55 PM, Florian Weimer fweimer@redhat.com wrote: > >> On 06/11/2018 09:49 PM, Mathieu Desnoyers wrote: >>> It should be noted that there can be only one rseq TLS area registered per >>> thread, >>> which can then be used by many libraries and by the executable, so this is a >>> process-wide (per-thread) resource that we need to manage carefully. >> >> Is it possible to resize the area after thread creation, perhaps even >> from other threads? > > I'm not sure why we would want to resize it. The per-thread area is fixed-size. > Its layout is here: include/uapi/linux/rseq.h: struct rseq Looks I was mistaken and this is very similar to the robust mutex list. Should we treat it the same way? Always allocate it for each new thread and register it with the kernel? > The ABI is designed so that all users (program and libraries) can interact > through this per-thread TLS area. Then the user code needs just the address of the structure. How much coordination is needed between different users of this interface? Looking at the the section hacks, I don't think we want to put this into glibc at this stage. It looks more like something for which we traditionally require compiler support. Thanks, Florian