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-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id BC2AB1F66F for ; Thu, 19 Nov 2020 15:10:45 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B2C7738708C9; Thu, 19 Nov 2020 15:10:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B2C7738708C9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1605798644; bh=CjSBSGyGuBNET96XJ157+Py9tG69cIazo8AYSbJqSAw=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=sAgbHz2tvUyiTeJu0DFzlHxndknRSfDSglxNkaFMON2w+K8LpPe7DFXYek/hZCz91 RgYLZ5IoNqfQpcl7vVtMn8VWq0BzoAJ7SlMD0vB3m5LJEvlB5oinmhhNPIcaOa9Q0U zOzxYiRQhAs1k1DWIou4Igq8DJSWXxcOJgElDqAc= Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) by sourceware.org (Postfix) with ESMTPS id 296EA3851C27 for ; Thu, 19 Nov 2020 15:10:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 296EA3851C27 Received: by mail-oi1-x242.google.com with SMTP id j15so1321433oih.4 for ; Thu, 19 Nov 2020 07:10:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CjSBSGyGuBNET96XJ157+Py9tG69cIazo8AYSbJqSAw=; b=TxacW+jFczpuske9wulMAB8U8iGW3+uytS/r/O9SNQ11Ryrlw4XZ6Stry1jp4yLgOP 3rNXggRIa7i+0ijA/8chAOIlrW1DcfZlt1B5hxRRbY6boRJOe+JxNwYJPCzqYqOr4HvN qpP3YAPsRaCyMP1+GELijUhLABvG3C9SgqT9c6QzThnxdrMoMlDLx/0pQ0bqq/Ghy5Ld P2/B+ndML01E7W6pKa5XeiQBwmDflJpR7JQVhkT/rcen0e9nrpr/6ZxXqfDo19lt8P1f CkOKV7LBhzAeWuZa8R8pomt1UTKMU85jQHAx3s3xVaFzlaoeyhksPSPi8aRQ8CGdLY22 ZWPg== X-Gm-Message-State: AOAM531NQPeC1J+fFR+0FdSqR/LeX3/kzH0qLNx+ZnpcwCk460tzqjNP EeQhdzrrtw9WnoVtn3WMTSw7PBZRZ6RrV8dgR3I= X-Google-Smtp-Source: ABdhPJxWyvSKjsqn9b9ggyoV2oAn+hEW+7OF9POEWrC0yZLyx70DCFfkmXjGGaVMSoBO0IPwc6i42lvwoBK3HAr5Wv4= X-Received: by 2002:aca:b887:: with SMTP id i129mr2944728oif.25.1605798641498; Thu, 19 Nov 2020 07:10:41 -0800 (PST) MIME-Version: 1.0 References: <87lfeyvghf.fsf@mid.deneb.enyo.de> <20201118170434.GF6882@arm.com> <873616va9n.fsf@mid.deneb.enyo.de> <20201118180927.GI6882@arm.com> <20201119145934.GC20578@arm.com> In-Reply-To: <20201119145934.GC20578@arm.com> Date: Thu, 19 Nov 2020 07:10:05 -0800 Message-ID: Subject: Re: PING: V7 [PATCH] sysconf: Add _SC_MINSIGSTKSZ/_SC_SIGSTKSZ [BZ #20305] To: Szabolcs Nagy Content-Type: text/plain; charset="UTF-8" X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: "H.J. Lu via Libc-alpha" Reply-To: "H.J. Lu" Cc: Florian Weimer , "H.J. Lu via Libc-alpha" , Dave Martin , Joseph Myers , Rich Felker Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On Thu, Nov 19, 2020 at 7:00 AM Szabolcs Nagy via Libc-alpha wrote: > > The 11/18/2020 18:09, Dave Martin via Libc-alpha wrote: > > On Wed, Nov 18, 2020 at 06:35:00PM +0100, Florian Weimer wrote: > > > * Dave Martin: > > > > I have some thoughts on what a better interface might look like -- > > > > basically separating the signal ucontext_t type from the setcontext()/ > > > > getcontext() etc. type, and providing accessors for the architectural > > > > register state rather than just having a fixed struct definition for > > > > mcontext_t. > > > > > > > > But, there also may not be a lot of appetite for such a change, and > > > > I can't see how it could be backwards compatible. > > > > > > > > I can elaborate if people think it's worth discussing. > > > > > > I think Rich Felker wants to copy signal contexts around to implement > > > critical sections that can't be interrupted by a signal handler, I > > > think that would need this fully fixed. > > > > Is rseq a more suitable way to do that sort of thing on new-ish Linux? > > I guess a fallback may be needed for older / other kernels though. > > rseq does not help with libc critical sections: > > the point is not to restart the critical section > (which would require no side effect or mechanisms > to roll side effects back and that the section is > entirely written in asm between begin/end labels > so the kernel knows when the section is left), > > but to let the critical section with all its side > effects complete and delay the signal handler > until then. (the slow and easy way to do this is > masking signals using syscalls around critical > sections, a fast solution needs signal wrapping > and saving the sigcontext.) > > for example the entire malloc call can be a critical > section and an incomming signal delayed until malloc > completes. such solution allows hiding all libc > internal inconsistent state from user code so async > signal handlers can call all libc apis. > > > For aarch64 an explicit prctl()/sysctl opt-in is needed to enable jumbo > > vector registers before you see oversized signal frames, though I don't > > think there is a similar control for AVX-512. > > > > Even on aarch64, this interface is not very friendly though. It might > > be better to have some ELF attribute that ld.so or the libc startup can > > arbitrate on and twiddle the appropriate switches. > > we can probably mark binaries if they are large > vector length compatible. (but the incompatible > binaries have to be hunted down manually and all > we can do with them at dlopen time is to give a > nice dlerror in case the vlengh got increased) We can mark such binaries with GNU property. -- H.J.