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.2 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,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 E717A1F453 for ; Thu, 31 Jan 2019 16:53:38 +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=gYwAY1xtVOQuoqwv qxiHEhkAMUgB6zpSwANfZOIf1ODpYIolVEHlqb7ICAizzD4hzEbJzupkOXwV7USD WwXSZVIFwG1XFKo+LNdHmkz8Yo3JJVYh0uE5Tj60SveMBBRidOgJlWFTgXpYrvmE ku8jc1eCbr/e2l4lomcfmNz2e4A= 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=KTmMqEYQ3kv2MCicL1iitI ZtQDU=; b=YG/uSXcTYqHt6itXvUoO5dV3ZOykfDPfeTlc/QxnREXBG/G0vOAMNF 2UiySPObrFZj+nHi2wyvOE2golklJR+SoEv5/XT3SP/gQSWecSxjXVzjsO6/kKBx k5I0zwzzS1dHURPnrSesIKzQ3F+AJNCuK1nQRl2Y72wT7iMabHfbw= Received: (qmail 97456 invoked by alias); 31 Jan 2019 16:53:36 -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 97437 invoked by uid 89); 31 Jan 2019 16:53:36 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail.efficios.com DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 0C0BBB8CEF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1548953613; bh=/TyHWmziK1+f0ypIloY32NPNYmiETwsNtjHvLnAdTd0=; h=Date:From:To:Message-ID:MIME-Version; b=Cb40sEyO+Gl4xl0tXZNPXwgJkzKNhVDeXUA1XC6t2fdvtZ4D6t15vD5FP3C1nZ1A7 wkbwIPvnoD96WBXMBW+vWzzw/ecxGMVz5IIBtCGAzpW5kJu7Vqy5+n1A0+RgSAf+Eb 5vk50qCjW6onbIALPvSMjMVuIa7cnYFcDgcnLsU6sv4t2vdIF2z6n/9jzwf7zK6uJf OJ6Q76c6mY+zHz8RPElfovwvZauqVCbQw0Q9eHUHXJBJ0vqorbTo87cHpcd/tqM0lw cLbR7BeDlGXQDTj+iNC4TOVdzgq/MYiJa4XtJv+2BCXHKLzJ1wDvLJ4kbBbqk7cYNW ufAbJSutk1JbQ== Date: Thu, 31 Jan 2019 11:53:32 -0500 (EST) From: Mathieu Desnoyers To: Joseph Myers Cc: carlos , Florian Weimer , Szabolcs Nagy , libc-alpha , Thomas Gleixner , Ben Maurer , Peter Zijlstra , "Paul E. McKenney" , Boqun Feng , Will Deacon , Dave Watson , Paul Turner , Rich Felker , linux-kernel , linux-api Message-ID: <492954632.538.1548953612856.JavaMail.zimbra@efficios.com> In-Reply-To: <19276261.499.1548952628477.JavaMail.zimbra@efficios.com> References: <20190121213530.23803-1-mathieu.desnoyers@efficios.com> <632671842.3079.1548781059601.JavaMail.zimbra@efficios.com> <596949707.3888.1548812359874.JavaMail.zimbra@efficios.com> <1832200535.4162.1548871426959.JavaMail.zimbra@efficios.com> <19276261.499.1548952628477.JavaMail.zimbra@efficios.com> Subject: Re: [RFC PATCH glibc 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v6) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- On Jan 31, 2019, at 11:37 AM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote: > ----- On Jan 30, 2019, at 4:10 PM, Joseph Myers joseph@codesourcery.com wrote: > >> On Wed, 30 Jan 2019, Mathieu Desnoyers wrote: >> >>> #if defined (__NR_rseq) && !defined (RSEQ_SIG) >>> # error "UAPI headers support rseq system call, but glibc does not define >>> RSEQ_SIG." >>> #endif >>> >>> Would that take care of your concerns ? >> >> That would of course need appropriate conditionals based on the most >> recent kernel version for which a given glibc version has been updated, so >> that using new kernel headers with an existing glibc release does not make >> the build fail (cf. the test of syscall-names.list). > > The test I hint at above would not be for the glibc build per se. It would > be for a check that glibc implements support for all the system calls > available in the kernel headers (if such a test target currently exists). > >> And being able to >> write such a test only solves one half of the problem - it needs to be >> easy to determine what value to put in that header in glibc for an >> architecture that's newly gained support in the kernel, *without* needing >> any architecture expertise. > > I'm afraid this requirement is incompatible with the nature of the RSEQ > signature. This signature may be required to be a specific trap instruction > by the architecture, so deciding on its value without architecture expertise > is not possible. Just to clarify a point: the "success criterion" I'm aiming for here is to provide a rseq integration that does not cause foreseeable user crashes on upgrade. I'm all for taking into account the maintenance burden on glibc maintainers as a metric in the implementation choices made, but at this point, I don't see how we can achieve success without introducing architecture headers for the RSEQ_SIG signature. If you have ideas on how to further minimize the maintenance burden for glibc maintainers while still meeting the success criterion, I'm all ears. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com