From owner-freebsd-threads@FreeBSD.ORG Wed Jan 30 22:09:22 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5ED416A41A for ; Wed, 30 Jan 2008 22:09:22 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 796F913C4D9 for ; Wed, 30 Jan 2008 22:09:22 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.2/8.14.2/NETPLEX) with ESMTP id m0UM9G75028701; Wed, 30 Jan 2008 17:09:17 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Wed, 30 Jan 2008 17:09:17 -0500 (EST) Date: Wed, 30 Jan 2008 17:09:17 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Julian Elischer In-Reply-To: <47A0D2DE.9060005@elischer.org> Message-ID: References: <200801240850.m0O8o2JQ023500@freefall.freebsd.org> <4798564B.7070500@elischer.org> <488DBC6A-CF33-4E50-B1BB-C396C8957F92@bikemonkey.org> <892A73B3-0114-4718-ABC0-CADD45D9D0FA@bikemonkey.org> <47A0D2DE.9060005@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-threads@freebsd.org Subject: Re: threads/119920: fork broken in libpthread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2008 22:09:22 -0000 On Wed, 30 Jan 2008, Julian Elischer wrote: > Landon Fuller wrote: >> >> Is my assumption that kse_critical_enter() prevents any other code from >> being run during the critical section incorrect? > > My understanding (not being a userland expert) is that > critical-enter sets a flag in the thread's mailbox telling the > kernel that no matter what happens, it must not allow another > thread to pre-empt this one. This means that any system call > (or page fault or whatever) will be handled synchronously. if > it blocks, that schedulable entity will block and no upcall > will be made to schedule another thread. > > It does not in any way however ensure that any other thread changes its > behaviour. > Dan, is my understanding correct? Right, it doesn't prevent another KSE from getting an upcall and doing things to threads. The problem seems to be in src/libpthread/sys/lock.c. See the patch here: http://people.freebsd.org/~deischen/kse/libpthread.6.diffs It is an attempt to merge in all of HEAD to 6.x. I can't test it, but it compiles. You at least want the part of the patchset that patches sys/lock.c (along with the previous patch I posted which is also included in the patchset). -- DE