From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10287 Path: news.gmane.org!not-for-mail From: Jorge Almeida Newsgroups: gmane.linux.lib.musl.general Subject: Re: abort() PID 1 Date: Mon, 4 Jul 2016 02:37:18 -0700 Message-ID: References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1467625072 846 80.91.229.3 (4 Jul 2016 09:37:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Jul 2016 09:37:52 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-10300-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jul 04 11:37:46 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1bK0Jr-0007SG-OQ for gllmg-musl@m.gmane.org; Mon, 04 Jul 2016 11:37:36 +0200 Original-Received: (qmail 17588 invoked by uid 550); 4 Jul 2016 09:37:31 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 17567 invoked from network); 4 Jul 2016 09:37:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=EpA7Qnc9Tejoj3adRTCzAUswRAqehXcQ7tBwOHKjYt0=; b=PrE2qjtaOKj83rYRH51+bSZwMIimutWrG6af1PWYlIkZZjkhsj6aszP1cTBc5WngeP y1mqIIrMYlN6tuYR7XGj7AePydumyfZ0XmhKDZhTUgig6ODe5pe1iQDyfnGO5Alg3VGx WdUPan3oqpf1dC+49K08tDhtTw3oJ97/g9lcijhOmv++Spo85EujnDnJ+XZ1Tj/QJxuw Cx/dUQFul2AxiJEr2Vz9it/SjdCES+AWFkCvrrgqx3ziCSujjxmPauDD4w15jL+2al+N 9Ty9LLF7UJRPlR/JxAvNNSULMc3gTOFAO5zIvZnw0knD5Tip3cI8fr2Owws1COOduj2D RQ0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=EpA7Qnc9Tejoj3adRTCzAUswRAqehXcQ7tBwOHKjYt0=; b=DaeVy68ZshkVpnyyHjT00rpU68nPv7RTTyoOoLMdvKnJgooSG2VRAWGAPnC1LUdtLQ eOhigNWUbz9wQ0Ba95N7/8oK/j+SNJBRA2UrtWmUG2VaSTwq7yKsgg8x2K8VIukpBsHh 9em8PkFA/YfaMvqOkJwHo3raTbQeU+d71ga306MFH/93tqrCIYcyU5pMojcEU58mZ22K TNXqrGgb1Y7bEhsxydSCUd+YGYd/KsjEvdtVYBXeWr6FhnTOxIMhIuVxg2Tx7pptEbY1 vi6SQZdRq4ELrVbyc4GfdHCli5jIihSzCyHrZcit2ALzHsusB4ltOWobyMbaNB9QPoTH JQQw== X-Gm-Message-State: ALyK8tLGCpHYw9NsYQZUe0eLI653gE7pmMvrt3HsOCzb23oZqi5+1wdx125Iw7dVMl27koDG118WNzZK+6lpAw== X-Received: by 10.25.125.139 with SMTP id y133mr2995300lfc.140.1467625039731; Mon, 04 Jul 2016 02:37:19 -0700 (PDT) In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:10287 Archived-At: On Mon, Jul 4, 2016 at 1:28 AM, Igmar Palsenberg wrote: > > >> >> -if process 1 calls abort() (regardless of what purpose that would fill), then: >> >> - if a handler was setup, it should be done whatever the handler does >> >> - if a handler was not setup, nothing should happen (as in: >> process didn't receive any signal at all) > > Pid 1 can ignore sigkill / sigstop. "Normal" processes can't. "Normal" > processes have defaults handling signals, pid 1 ignores all by default, > unless it instructs the kernel it wants to receive it. > Yes, just what I said. >> >> What the standards say: >> >> (http://pubs.opengroup.org/onlinepubs/9699919799/) >> >> "The SIGABRT signal shall be sent to the calling process as if by >> means of raise() with the argument SIGABRT." >> >> "The effect of the raise() function shall be equivalent to calling: >> >> pthread_kill(pthread_self(), sig);" >> >> man raise(3): >> The raise() function sends a signal to the caling process or >> thread. In a single-threaded program it is equivalent to >> kill(getpid(), sig); >> >> So, what should " kill(1, SIGABRT)" do? It doesn't seem ambiguous to >> me. IOW, there's nothing special about SIGABRT regarding PID 1. > > The "problem" in this case is that the "normal" abort() sends a SIGABRT, > if that doesn't work, unblocks signals and retries. > While that works with "normal" processes, it doesn't work with pid 1, > because the default action on that process for SIGABRT isn't terminate. As I see it: the process that issues abort() is really saying to the kernel: "pretty please, send SIGABRT to this process--hey, that would be me!" and the kernel replies "nope, you're process 1, I won't send you anything" or else "sure, you have a signal handler, knock yourself out". If the handler has something like _exit, this will cause a kernel panic. Whoever writes the code may have a use for a panic on demand, who knows? If the handler doesn't return, that's it, abort() has done its job, per the man page. If the handler returns, abort() must "restore the default disposition for SIGABRT and then raise the signal a 2nd time" --restoring the default disposition means removing the handler, and so the 2nd time the kernel won't send a signal, and end of story. I just can't see why there should be any remaining issue. Why shoul there be any loop at all? Thanks, Jorge