MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <18170.44782.134750.907938@alkaid.it.uu.se>
Date: Wed, 26 Sep 2007 21:11:42 +0200
From: Mikael Pettersson <mikpe@it.uu.se>
To: "Ulrich Drepper" <drepper@gmail.com>
Cc: "John Z. Bohach" <jzb2@aexorsyst.com>, linux-kernel@vger.kernel.org
Subject: Re: __kernel_vsyscall () hangs in SIGCHLD handler
In-Reply-To: <a36005b50709261003j923835fu621882c54706d476@mail.gmail.com>
References: <200709260757.20478.jzb2@aexorsyst.com>
	<a36005b50709261003j923835fu621882c54706d476@mail.gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1284
Lines: 25

Ulrich Drepper writes:
 > On 9/26/07, John Z. Bohach <jzb2@aexorsyst.com> wrote:
 > > Is there some reason that syslog() sleeps in __kernel_vsyscall() when
 > > invoked from a signal handler?
 > 
 > Only very few functions are allowed to be called from signal handlers.
 >  This is clearly spelled out in the POSIX spec.  Section XSH 2.4.3
 > lists the allowed functions.  syslog of course is not on it.

The Linux kernel itself imposes no restrictions on what you can
do in user-space signal handlers.

However, user-space is a different story. The interrupted thread
may have held a lock, in which case calling code from the signal
handler that tries to take the same lock may result in a deadlock.
Or the thread may be been in the process of updating some private
data, in which case calling code from the signal handler that tries
to access that data may result in data corruption. And then there's
libc which may wrap your signal handler with code doing unspecified
libc magic. And so on, the possibilities for failure are endless :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/