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 DC306211B4 for ; Fri, 11 Jan 2019 17:44:28 +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:to:from:subject:message-id:date:mime-version :content-type:content-transfer-encoding; q=dns; s=default; b=wrX 4tDjjKSguP3RIxAzdsZDV5zNhsi8IMiuc0DHPn9xMsq+B3+QloHkdF0z3yrCvzyJ R4X3XClgHeuUXXqDGKXJz/fgR/eXapz5JFNeNqXNV0xtZm03fjSHC2z8UZWsIiHj DlF/ibsbLyHgzJxQGzzcAhgS0pmceCAJ7feXB2zM= 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:to:from:subject:message-id:date:mime-version :content-type:content-transfer-encoding; s=default; bh=uFqSq3HHe dFcJEDWzYv6LixUOH0=; b=JbQHUkHCT7DQJTHAtzoAbX5C1DBBWd7iOULvcVoKS Ilrr7xzVigajS55RtXnkMcQUzLQDZQGMyWJMWtQGjJQuuCHuHrwMoZ+hILZmUVhl aw7rk4erLoWvVY1ClKzQKP64KKw/GVO3yShH/NAaGOlmGh7SyCbK00VfLgdIhJcz gg= Received: (qmail 114055 invoked by alias); 11 Jan 2019 17:44:26 -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 114045 invoked by uid 89); 11 Jan 2019 17:44:26 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-qt1-f170.google.com To: GNU C Library From: Carlos O'Donell Subject: What can a signal handler do with SIGSTKSZ? Openpgp: preference=signencrypt Message-ID: Date: Fri, 11 Jan 2019 12:44:20 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit In the continuing series of "What can X do with Y?" [1] I would like to get consensus on what a signal handler can do with SIGSTKSZ amount of space. I propose the following: ~~~ The implementation only guarantees that a signal handler can manipulate a reasonable amount of local variables (no more than 2 KiB worth), and can read and write to memory, carry out atomic operations, and call simple C library functions that do similar memory and simple string operations e.g. memcpy, memset, strcmp, strcpy. The amount of signal stack allocated for SIGSTKSZ is not sufficient to call complex signal-safe functions e.g. fork, _exit, abort, nor any that can be canceled (requires enough stack for cancellation). Any other operations or function calls in the signal handler should be evaluated for runtime stack usage and additional stack beyond SIGSTKSZ should be allocated. ~~~ Thoughts? -- Cheers, Carlos. [1] "What can a thread do with PTHREAD_STACK_MIN?" https://sourceware.org/ml/libc-alpha/2017-12/msg00751.html