From owner-freebsd-current@FreeBSD.ORG  Sun Oct 11 06:33:08 2009
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from alona.my.domain (localhost [127.0.0.1])
	by hub.freebsd.org (Postfix) with ESMTP id E9C02106566B;
	Sun, 11 Oct 2009 06:33:05 +0000 (UTC)
	(envelope-from davidxu@freebsd.org)
Message-ID: <4AD17C1F.8020709@freebsd.org>
Date: Sun, 11 Oct 2009 14:33:03 +0800
From: David Xu <davidxu@freebsd.org>
User-Agent: Thunderbird 2.0.0.21 (X11/20090522)
MIME-Version: 1.0
To: Kostik Belousov <kostikbel@gmail.com>
References: <c47019cc0909301102y189a0b8aq47d23efae549f4ab@mail.gmail.com>	<20091001120730.GR3130@deviant.kiev.zoral.com.ua>	<20091002201213.GA16633@stack.nl>	<20091005192144.GA2259@deviant.kiev.zoral.com.ua>	<4AD01ABC.50901@freebsd.org>
	<20091010143643.GA2259@deviant.kiev.zoral.com.ua>
In-Reply-To: <20091010143643.GA2259@deviant.kiev.zoral.com.ua>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-current@freebsd.org, Jilles Tjoelker <jilles@stack.nl>,
	Justin Teller <justin.teller@gmail.com>
Subject: Re: Signals and an exiting thread
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Oct 2009 06:33:08 -0000

Kostik Belousov wrote:
> On Sat, Oct 10, 2009 at 01:25:16PM +0800, David Xu wrote:
>   
>> Kostik Belousov wrote:
>>
>>     
>>> I agree that postponing assignment of the thread for signal delivery
>>> till the actual delivery occurs is the proper fix. I tried to cheat
>>> in my previous patch. Below is an experimental change that did very
>>> minimal testing.
>>> <snip>
>>>       
>> Even if the signal is put into process's signal queue, it is still
>> possible that signal notification is lost because selected thread
>> exits before seeing it, if other threads are sleeping, they are
>> not notified, this leaves signal in process queue long time before
>> it can be delivered to userland.
>>
>>     
>
> Agreed. Actually, there is one more race. Namely, when thread enters
> kernel for executing sigprocmask syscall, but still did not acquired
> process mutex, some signal may be scheduled for the thread which will
> block it later while still in kernel, so wakeup is lost again. I did
> fixed that in later version of the patch, by waking up possible target
> threads that have newly blocked signals unblocked.
>
> Resulting code seems to be relevant for exiting thread as well, where
> we also shall set sigmask to indicate that thread is not willing (cannot)
> handle any further signals.
>
> Updated patch below.
>   

The patch looks fine to me.