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.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,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 134FC211B4 for ; Fri, 11 Jan 2019 20:29:19 +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:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type; q=dns; s=default; b=jeKno 8MvWhwW2RAIDTms9qSaGPYdsHO/djxkjDK4czvAVnI7VzCYyQQg8zAh5Y07y5Cne EBhzEnQEE83a5Q+O8a3M1I/3eJhuLxOz+yLil84aZoqZAt5OUwrWCSAkb2uRNV+H YSWtaTsBX3tDPscG+LwxC+ZWMx1Hg6ukT1cTds= 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:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type; s=default; bh=fRqtDJZAsUS /mvXRmiU/W4ZmZrs=; b=PAV0I7usrDl10BM3F6MHI8VWMDV4mRA6XS5sPdyeMTQ BgZk0w6KACZYryZVWSZXEi4G5ZuWsTw/6iWzKYmsaMPLHTchicj1paftkF+/HNnQ dsXRbmIPHYPCTqGrgUuJyGWU2pgac6knd4Om50/0sD4xk7d8If0EmRajsAxl64lM = Received: (qmail 6847 invoked by alias); 11 Jan 2019 20:29:17 -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 6838 invoked by uid 89); 11 Jan 2019 20:29:16 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mx1.redhat.com From: Florian Weimer To: Zack Weinberg Cc: GNU C Library Subject: Re: Fwd: What can a signal handler do with SIGSTKSZ? References: <874lafezhe.fsf@oldenburg2.str.redhat.com> Date: Fri, 11 Jan 2019 21:29:11 +0100 In-Reply-To: (Zack Weinberg's message of "Fri, 11 Jan 2019 15:09:33 -0500") Message-ID: <87sgxzdjl4.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain * Zack Weinberg: > I was pretty harsh on Carlos's proposal but, on further reflection, > given the fairly nasty ABI compatibility constraints we're working > with here (SIGSTKSZ having to be usable as the size of a statically > allocated char[], for instance), I could live with _most_ of it. The > only change I insist on is, by hook or by crook we _must_ find a way > to make it safe to call `_exit` and `abort`. abort delivers another signal, so that's going to be impossible to support with a really small stack, I think. > Do you think we could push the kernel people to expose the space > requirement of a signal frame in some fashion that we could wrap up in > a new sysconf() constant? Then we could deprecate the constants, in > the same way that long ago PAGESIZE was replaced by > sysconf(_SC_PAGESIZE). That's an interesting idea. sigaltstack could also check that the size is at least that large, but then the question is how many sigaltstack users check the error return value. However, based on what I saw in the kernel sources, it's not that they have an exact upper bound in the sources or even at run time. I think the code simply uses space as it proceeds (at least on x86). But perhaps I misread it. Thanks, Florian