From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52993 invoked by alias); 20 Oct 2017 17:19:48 -0000 Mailing-List: contact libc-help-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: libc-help-owner@sourceware.org Received: (qmail 52980 invoked by uid 89); 20 Oct 2017 17:19:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=H*M:cfb3, reserved X-HELO: mail-qt0-f182.google.com Received: from mail-qt0-f182.google.com (HELO mail-qt0-f182.google.com) (209.85.216.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 20 Oct 2017 17:19:46 +0000 Received: by mail-qt0-f182.google.com with SMTP id 8so19332562qtv.1 for ; Fri, 20 Oct 2017 10:19:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=fYevojIZZ+A1cmossm2lf7/rYWXk3NJeZYGWfQoA4Lw=; b=RbDjRhTWR+5x9TNJ5MKv+Rwbo7ge0SGNXi/+cOT+ck7m4GjEo0336VCBtvFv8h7aGV qhs7E/gjAQyRgxFdOFuYyQRUEGgeb7NVjW24ecRQicxld96ya54Rw6QLwUZFIwi7zLOC FIlSlrJ1mndmGyMnRljJ8UGVhs52BqYG4skJHm71SZTT+zfwr41zPEFD42h4JNIfi6MS cHdvjCQzveKA2NsP6iXxsLeae/Gm0frEkZATQoWYTvySjqwDjT3T4SJB0ntucTe8LNaq bBEJxahwmUsFsyE/CCcBd0ndOpGLgJBG4DIIcuYaICt7Qpfkh27OUFZOVsisKPUwLUyv cgng== X-Gm-Message-State: AMCzsaVHJUMwrHz+j3Jdml/QJ7mpnJ2hmHfqikAcO2cLuTYLSH/D1bY+ LJbRyc3E8+dhu3LVAvplhqxwDHSGt6M= X-Google-Smtp-Source: ABhQp+RGGr+/v1JjJScz/VQbPO9XHWp68F5dKA/sgUcfC4zLGv0tc9CfN0/xnCwj+CxwsRDd7d6ihQ== X-Received: by 10.200.53.171 with SMTP id k40mr8557184qtb.264.1508519984804; Fri, 20 Oct 2017 10:19:44 -0700 (PDT) Received: from [10.150.73.190] ([184.151.231.188]) by smtp.gmail.com with ESMTPSA id g47sm902233qtk.37.2017.10.20.10.19.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Oct 2017 10:19:43 -0700 (PDT) Subject: Re: determine whether code is running in a signal handler context To: Szabolcs Nagy , Yubin Ruan Cc: nd@arm.com, libc-help@sourceware.org References: <59E9D0C2.4090900@arm.com> <59E9DE7F.6010909@arm.com> From: Carlos O'Donell Message-ID: <36695ee6-cfb3-3363-5827-94d52ca48e24@redhat.com> Date: Fri, 20 Oct 2017 17:19:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <59E9DE7F.6010909@arm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg00032.txt.bz2 On 10/20/2017 04:31 AM, Szabolcs Nagy wrote: > On 20/10/17 12:23, Yubin Ruan wrote: >> Thanks Szabolcs, >> >> 2017-10-20 18:32 GMT+08:00 Szabolcs Nagy : >>> On 18/10/17 15:18, Yubin Ruan wrote: >>>> Hi, >>>> >>>> I am writing to see if this is any util functions in libc that can >>>> help to determine it is currently running in a signal. >>>> >>>> I wrote some library and provide a function which will be used in many >>>> client code. However this function is not async-signal safe (it calls >>>> malloc(3)) so when it is called, I want to detect whether it is >>>> currently running in a signal handler. If it is, I can avoid calling >>>> those not-async-signal-safe functions which might cause deadlock. >>>> >>> >>> note that in posix as-safety is symmetric between the >>> interrupted code and interrupt handler: if any of the >>> interrupt and interrupt handler is as-safe then the >>> behaviour is well defined. >>> >>> so calling non-as-safe code in an asynchronous signal >>> handler is perfectly fine if the interrupted code is >>> as-safe. >>> >>> there are synchronous signals too, i.e. raise(sig), >>> and then the signal handler runs in well-defined state >>> (one can use signal masks to make sure a signal handler >>> only runs in such state) >> >> Actually I think the point is that that piece of code should not run >> in a signal handler. That have nothing to do with sync-signal or >> async-signal code, because in both case we might encounter deadlock. >> From this perspective, that `in_signal_handler_context()' make sense >> to me. > > there is no deadlock, malloc is safe to call in a signal > handler in posix if the signal interrupts as-safe code. > > this entire mailing list thread assumes that only as-safe > code may run in a signal handler and that is wrong. Correct. I didn't want to go down more complex scenarios. > your api proposal does not make sense in a posix libc. > (which explains why it does not exists) > > (the libc startup code may raise a reserved realtime > signal and make all programs run from a signal handler, > it would be a posix conform implementation and your > 'in_signal_handler_context' would be always true) Conservatively, if you see you are in a signal handler, and always run AS-safe code, you are always safe. The converse is true too, if such an API call says you are *not* in a signal handler, you may always run AS-unsafe code because you know you could not have interrupted AS-unsafe code. The API could still have its uses? -- Cheers, Carlos.