Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1967426imm; Thu, 14 Jun 2018 06:47:36 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJCYgmzQL5r/YW3HqrwUjHbgg/Xl0gwjC0PH+VD1yu9KIL8x1sSYlqcAMAyBAEVLXcK3vkE X-Received: by 2002:a62:249b:: with SMTP id k27-v6mr9698210pfk.143.1528984056338; Thu, 14 Jun 2018 06:47:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528984056; cv=none; d=google.com; s=arc-20160816; b=BdER+1zcYDgFrMDE2GebcCam9y5dpFlxvjjqLFxe4RPtt77r1hPLsj4w5sguwJ6IHr oweb52pnvCGR794yZp5hFUhFAq1Z/DcOQoeRn+8QUrS6SL2JRaOyxohJWAtopgrkVRHT tJagjlHLmKMOD+DptR9rXLKtsaimu+VJq8e5AM70tae+vlWBRDVWLYZkg1fEfr3C2KKo RwKMGDEmo+hiuRKTkVKcXnVboxbJd9NjDi+3z7dk3sPx4zRc6GOyg8mSkJn4yEZScJhC nN6RoOSGJR8lCYIxoXsynuGDXq/0mTW8SpEfDxkEgX/zwE3KSLowabZke8fsN9GODpu8 oM1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:thread-index:thread-topic :content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:dkim-signature:dkim-filter :arc-authentication-results; bh=4aoWfqEkSbFXdxxZZHOWEeAoIqu7xB3INTlRghiUKcw=; b=BRQMpNWi23HwHRYTGz7Qb4FbH0TGr35P9srOfMe4OUq6UVQWKJ9n3jGrvMnptQLM5I clk4TrSI/xVFKOp+RAfI09kPer1l1FgwaB+ar2kwyCbrp+Y7hBAFsKJtueu5SBNKWdOR 21YsQ0OCXpquBlV9K9YypxZL8cHK2+UctoIwR/p05R4CTCauuqbK0T0loYvGf/XbvXgj ZzrDApC+GjEdKOVpNL0CV+cOx5N65tyqbCV+S4vdHMe8GgsTgShVWmN39FGNFmpveTws zh+8kWxSoKqYSL9tJzSG/cTQgDKirCDe6fEJiQ30/qBHliSJ4wXAgFMK7GyT84NEe5IR fexw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@efficios.com header.s=default header.b="KoL9/zLY"; 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=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a98-v6si5681099pla.117.2018.06.14.06.47.22; Thu, 14 Jun 2018 06:47:36 -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; dkim=pass header.i=@efficios.com header.s=default header.b="KoL9/zLY"; 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=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755295AbeFNNqu (ORCPT + 99 others); Thu, 14 Jun 2018 09:46:50 -0400 Received: from mail.efficios.com ([167.114.142.138]:43130 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755258AbeFNNqs (ORCPT ); Thu, 14 Jun 2018 09:46:48 -0400 Received: from localhost (ip6-localhost [IPv6:::1]) by mail.efficios.com (Postfix) with ESMTP id 62FCD22AE2C; Thu, 14 Jun 2018 09:46:47 -0400 (EDT) Received: from mail.efficios.com ([IPv6:::1]) by localhost (mail02.efficios.com [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id BUQ_iGJI0Nk4; Thu, 14 Jun 2018 09:46:47 -0400 (EDT) Received: from localhost (ip6-localhost [IPv6:::1]) by mail.efficios.com (Postfix) with ESMTP id E5CB122AE25; Thu, 14 Jun 2018 09:46:46 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com E5CB122AE25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1528984006; bh=4aoWfqEkSbFXdxxZZHOWEeAoIqu7xB3INTlRghiUKcw=; h=Date:From:To:Message-ID:MIME-Version; b=KoL9/zLYFeuE+k5Q20fiH7bWx31dPbl3ilgA7TE6kJlv7NuySdqFDbdw1eZZymxl6 wLgSkneDoNCmsqkHBKklb7A0Rgjk/GhgP4oSgZakSmJxg+hzQW8Bhg2MOXCrBEdqQ2 qZYjKGxj+ovZdabbNFbrvahpd4aWs9BJJgp48C9C74uEhwT3oomc8iJ00UJSlkSfVZ N9UR1CxcwSlBRSzw4UvkasOI6ezuLSF51XNj7a9ySugjWRSeDC8zwGw1NaAoGfc3/T Pd+h2jI0FYmhlcncwCs2t56wbwYvWbTzjxn9uEpbR/K9X7bBg3CZZD0KlNKXBtRlHR bq0raZDwyjbnQ== 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 t33k4YoCORCO; Thu, 14 Jun 2018 09:46:46 -0400 (EDT) Received: from mail02.efficios.com (mail02.efficios.com [167.114.142.138]) by mail.efficios.com (Postfix) with ESMTP id CE8E422AE1B; Thu, 14 Jun 2018 09:46:46 -0400 (EDT) Date: Thu, 14 Jun 2018 09:46:46 -0400 (EDT) From: Mathieu Desnoyers To: Florian Weimer Cc: Pavel Machek , carlos , Peter Zijlstra , "Paul E. McKenney" , Boqun Feng , Thomas Gleixner , linux-kernel , libc-alpha Message-ID: <1399480624.13011.1528984006717.JavaMail.zimbra@efficios.com> In-Reply-To: <1110f198-88c2-544d-6836-f901b8e90f98@redhat.com> References: <1084280721.10859.1528746558696.JavaMail.zimbra@efficios.com> <305409897.10888.1528747473727.JavaMail.zimbra@efficios.com> <091061df-3482-8762-30e4-feaf3417be11@redhat.com> <417742741.11550.1528821084084.JavaMail.zimbra@efficios.com> <20180614122759.GB8798@amd> <894222691.12973.1528981314012.JavaMail.zimbra@efficios.com> <20180614132557.GA15201@amd> <1110f198-88c2-544d-6836-f901b8e90f98@redhat.com> Subject: Re: Restartable Sequences system call merged into Linux 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.8_GA_2096 (ZimbraWebClient - FF52 (Linux)/8.8.8_GA_1703) Thread-Topic: Restartable Sequences system call merged into Linux Thread-Index: nXCKTzw5HShYkUfF6imqBIpjKO491A== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Jun 14, 2018, at 9:32 AM, Florian Weimer fweimer@redhat.com wrote: > On 06/14/2018 03:25 PM, Pavel Machek wrote: > >> But the proposal wanted to add a syscall to thread creation, right? >> And I believe that may be noticeable. > > We already call set_robust_list, so we could just pass a larger area to > that and the kernel could use it. Then no additional system call would > be needed in the common case (new kernel which recognizes the new area > size). > > But then we cannot use an initial-exec thread local variable for it > (although the offset from the thread pointer will still be constant, of > course). I'm wondering whether we could turn the problem around: expose a new system call allowing to register an array of pointers to per-thread data, which would be used rather than set_robust_list when available. This way, we could register both the robust list and rseq with a single system call, e.g.: enum linux_tls_area_type { LINUX_TLS_ROBUST_LIST, LINUX_TLS_RSEQ, }; struct linux_tls_area_item { enum linux_tls_area_type type; void *p; }; long sys_register_tls_areas(struct linux_tls_area_item *array, size_t nb) This would allow registering various TLS data structures with a single system call without hindering flexibility on the user-space side. For instance, we could still use initial-exec and the __rseq_abi symbol for rseq with this approach. Thoughts ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com