From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 26 Jun 2009 02:58:20 +0200 (CEST) Received: from mail3.caviumnetworks.com ([12.108.191.235]:14803 "EHLO mail3.caviumnetworks.com" rhost-flags-OK-OK-OK-OK) by ftp.linux-mips.org with ESMTP id S1492805AbZFZA6O (ORCPT ); Fri, 26 Jun 2009 02:58:14 +0200 Received: from caexch01.caveonetworks.com (Not Verified[192.168.16.9]) by mail3.caviumnetworks.com with MailMarshal (v6,2,2,3503) id ; Thu, 25 Jun 2009 20:53:16 -0400 Received: from caexch01.caveonetworks.com ([192.168.16.9]) by caexch01.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 17:52:34 -0700 Received: from dd1.caveonetworks.com ([64.169.86.201]) by caexch01.caveonetworks.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 17:52:34 -0700 Message-ID: <4A441BCF.2030009@caviumnetworks.com> Date: Thu, 25 Jun 2009 17:52:31 -0700 From: David Daney User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Ralf Baechle CC: Kaz Kylheku , "Kevin D. Kissell" , linux-mips@linux-mips.org Subject: Re: Silly 100% CPU behavior on a SIG_IGN-ored SIGBUS. References: <20090625134511.GC10661@linux-mips.org> <20090626004527.GA3235@linux-mips.org> In-Reply-To: <20090626004527.GA3235@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jun 2009 00:52:34.0330 (UTC) FILETIME=[647BCFA0:01C9F5F8] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 23504 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@caviumnetworks.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > On Thu, Jun 25, 2009 at 09:00:19AM -0700, Kaz Kylheku wrote: > >> Ralf wrote: >>> I found this in IRIX 6.5 documentation: >>> >>> Caution: Signals raised by the instruction stream, SIGILL, >>> SIGEMT, SIGBUS, and SIGSEGV, will cause infinite loops >>> if their handler returns, or the action is set to SIG_IGN. >> The Single Unix Specification (Issue 6) marks the behavior >> explicitly undefined. > > I should have mentioned that above mentioned paragraph of IRIX documentation > was in the section on implmentation specific behaviour. > >> Bookmark this: http://www.opengroup.org/onlinepubs/009695399 >> >> Not the latest set of documents, but that can be regarded >> as a virtue. :) >> >> Under pthread_sigmask and sigprocmask, for blocking: >> >> If any of the SIGFPE, SIGILL, SIGSEGV, or SIGBUS >> signals are generated while they are blocked, >> the result is undefined, unless the signal >> was generated by the kill() function, the >> sigqueue() function, or the raise() function. >> >> Under ``2.4 Signal Concepts'', for SIG_IGN: >> >> SIG_IGN >> >> Ignore signal. >> >> Delivery of the signal shall have no effect on >> the process. The behavior of a process is undefined >> after it ignores a SIGFPE, SIGILL, SIGSEGV, >> or SIGBUS signal that was not generated by kill(), >> sigqueue(), or raise(). >> >> So, as I suspected, there are in fact no requirements >> from the applicable spec. Infinite looping or >> stopping the process anyway are conforming responses, >> as is rebooting or halting the machine with a >> ``panic'' message. > > I'd not go quite as far as that but execve("/usr/bin/nethack") certainly > would be acceptable. It is kind of moot at this point. The HEAD now kills the process instead of looping forever. David Daney