Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp831861ybt; Wed, 24 Jun 2020 12:18:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzXpexaR2FdPPav4p7S+qj1S84o4to3QiMf4SLIMQltI1XTyfrkDARyvrbNzJeHtB8lRA7r X-Received: by 2002:aa7:ce93:: with SMTP id y19mr27340053edv.50.1593026289719; Wed, 24 Jun 2020 12:18:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593026289; cv=none; d=google.com; s=arc-20160816; b=pPuBlgzpOZzDPQidfxscb1dZd+WL8sq7nJ09KR2LLhtsrIeuqZktWD79KHD9Xjgjrx myvrx9RRosHzD+7kQrKnDDJKcTPOTkDu+X/TsJNwfQCfbBCQq7FKFyzKzVSivLjI/Mna YdwgaRxeAWRM8aYHxtTrRRyeH1CnQ3sre93BrVoCrj9MSCTNETaYbtmHMI5xQ9R9apOK YY6QqpoiqbNgEWa8prKT7Y4dDOs4uzyz9HWrBf7jKBAph5hZMmVU+UBRmOPiwg5bQnUW UL0saT8Wwt2/HMHOSTp+QiidQv2RmTn7JiYM1GNf9+hzJAN/lpnOHHEefBthGQeAcLF+ eGGA== 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; bh=3iQZiVLyuzca+V6wzidMMRJWMtP3eZM0DyCNIq1qy5A=; b=WCvVlZ7kf+CwHecSTSOlemlf3oP0yhT2EDWf0pIAeUDXxL8FHFJ+zFuMpllZTSj3ws 3e5+1NhCe5rRBVYulmSkssqtZeHhq7+bh2/irQLWgBdHy3G1dVi1wWL80MlL8wOCUeau iKXBPQi2tZ/xS/hCd1r82v4DHVqqYFFvLjCTVMjitTTpdU4xmllQ5wHUmADi+71HHsOL IsQVTcXbknePDNrHkLfhB633dVdvfHiWxa0/jrJ4Zf4QFclubtE0WGVtGAddoM4vvFMv xeHvSayOCuTd5dU12aHEw3io9+KM+AIN5NSwAMT5kttW0u3Z86xJajPl7UAQf1V3Iy/t 1+cw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@efficios.com header.s=default header.b=gLi7cDDY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id h11si1261297edl.235.2020.06.24.12.17.44; Wed, 24 Jun 2020 12:18:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@efficios.com header.s=default header.b=gLi7cDDY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S2405777AbgFXTQl (ORCPT + 99 others); Wed, 24 Jun 2020 15:16:41 -0400 Received: from mail.efficios.com ([167.114.26.124]:52714 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404563AbgFXTQk (ORCPT ); Wed, 24 Jun 2020 15:16:40 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 32B2E2C41EA; Wed, 24 Jun 2020 15:16:39 -0400 (EDT) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Sy_hIEQaqNSw; Wed, 24 Jun 2020 15:16:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id D4A622C41E9; Wed, 24 Jun 2020 15:16:38 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com D4A622C41E9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1593026198; bh=3iQZiVLyuzca+V6wzidMMRJWMtP3eZM0DyCNIq1qy5A=; h=Date:From:To:Message-ID:MIME-Version; b=gLi7cDDYKoLA6fi9D2m9YjL4neyMZO3/xX+0sRd9xuPY3k0RAYiL9OKhPETdy2UrJ z8tHPffjw7aJNS6TM58GTkea3FuJmkbJ/N9FJ2M0fQVImRVEP180V4OPxhzjxHUalS 07Ll1v+SfqY+Hb4T8BhRTC1Dx9iP6XrTBhlA1xoU1cn14782maIaB7LFY2rHp6rqdQ dkeih0Scg2lV3eG8CIHF5Hg3DUv81hNLJ5IQw1+ESr/UxfA0vRupwMsvhuaVJs/9Tk EZo+kBGQXt8rOYsiXVTPro3r2CsdtcB1ey32YpvI7/ma+gmd/5s7hXuJodUtdbpp9v tQbeTDgR83aLQ== X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DBrbA6G8I6OI; Wed, 24 Jun 2020 15:16:38 -0400 (EDT) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id BF3DA2C448D; Wed, 24 Jun 2020 15:16:38 -0400 (EDT) Date: Wed, 24 Jun 2020 15:16:38 -0400 (EDT) From: Mathieu Desnoyers To: Florian Weimer Cc: carlos , Joseph Myers , Szabolcs Nagy , libc-alpha , Thomas Gleixner , Ben Maurer , Peter Zijlstra , Paul , Boqun Feng , Will Deacon , Dave Watson , Paul Turner , Rich Felker , linux-kernel , linux-api Message-ID: <1248023868.11643.1593026198678.JavaMail.zimbra@efficios.com> In-Reply-To: <87r1u48eix.fsf@oldenburg2.str.redhat.com> References: <20200622180803.1449-1-mathieu.desnoyers@efficios.com> <20200622180803.1449-2-mathieu.desnoyers@efficios.com> <87d05obl4w.fsf@oldenburg2.str.redhat.com> <1158112159.11628.1593025203438.JavaMail.zimbra@efficios.com> <87r1u48eix.fsf@oldenburg2.str.redhat.com> Subject: Re: [PATCH 1/3] glibc: Perform rseq registration at C startup and thread creation (v21) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.26.124] X-Mailer: Zimbra 8.8.15_GA_3945 (ZimbraWebClient - FF77 (Linux)/8.8.15_GA_3928) Thread-Topic: glibc: Perform rseq registration at C startup and thread creation (v21) Thread-Index: YkL95Fw6DEDAnKFpYDNCDQAteeHIAQ== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Jun 24, 2020, at 3:11 PM, Florian Weimer fweimer@redhat.com wrote: > * Mathieu Desnoyers: > >>> I'm still worried that __rseq_static_assert and __rseq_alignof will show >>> up in the UAPI with textually different definitions. (This does not >>> apply to __rseq_tls_model_ie.) >> >> What makes this worry not apply to __rseq_tls_model_ie ? > > It's not needed by the kernel header because it doesn't contain a > __rseq_abi declaration. > >>> >>> Is my worry unfounded? >> >> So AFAIU you worry that eventually sys/rseq.h and linux/rseq.h carry different >> definitions of __rseq_static_assert and __rseq_alignof. >> >> Indeed, I did not surround those #define with #ifndef/#endif. Maybe we should ? >> >> Just in case the definitions end up being different (worse case scenario), we >> should expect their behavior to be pretty much equivalent. So going for the >> following should address your concern I think: > > I think we should keep things simple on the glibc side for now and do > this changes to the kernel headers first. Just to be sure I understand what you mean by "keep things simple", do you recommend removing the following lines completely for now from sys/rseq.h ? /* Ensure the compiler supports rseq_align. */ __rseq_static_assert (__rseq_alignof (struct rseq_cs) >= 32, "alignment"); __rseq_static_assert (__rseq_alignof (struct rseq) >= 32, "alignment"); Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com