From owner-freebsd-arch@FreeBSD.ORG Thu Nov 20 22:22:06 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EC8F1065673 for ; Thu, 20 Nov 2008 22:22:06 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from outbound.icp-qv1-irony-out2.iinet.net.au (outbound.icp-qv1-irony-out2.iinet.net.au [203.59.1.107]) by mx1.freebsd.org (Postfix) with ESMTP id B82A18FC1F for ; Thu, 20 Nov 2008 22:22:05 +0000 (UTC) (envelope-from lstewart@freebsd.org) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAB5yJUl8qEpL/2dsb2JhbADRYYJ8 X-IronPort-AV: E=Sophos;i="4.33,639,1220198400"; d="scan'208";a="403343341" Received: from unknown (HELO lawrence1.loshell.room52.net) ([124.168.74.75]) by outbound.icp-qv1-irony-out2.iinet.net.au with ESMTP; 21 Nov 2008 07:22:03 +0900 Message-ID: <4925E30B.8010709@freebsd.org> Date: Fri, 21 Nov 2008 09:22:03 +1100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.17 (X11/20081109) MIME-Version: 1.0 To: John Baldwin References: <492412E8.3060700@freebsd.org> <200811201502.23943.jhb@freebsd.org> In-Reply-To: <200811201502.23943.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: kthread_exit(9) unexpectedness X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2008 22:22:06 -0000 John Baldwin wrote: > On Wednesday 19 November 2008 08:21:44 am Lawrence Stewart wrote: >> Hi all, >> >> I tracked down a deadlock in some of my code today to some weird >> behaviour in the kthread(9) KPI. The executive summary is that >> kthread_exit() thread termination notification using wakeup() behaves as >> expected intuitively in 8.x, but not in 7.x. > > In 5.x/6.x/7.x kthreads are still processes and it has always been a wakeup on > the proc pointer. kthread_create() in 7.x returns a proc pointer, not a > thread pointer for example. In 8.x kthreads are actual threads and Yep, but the processes have a *thread in them right? The API naming is obviously slightly misleading, but it essentially creates a new single threaded process prior to 8.x. > kthread_add() and kproc_kthread_add() both return thread pointers. Hence in Yup. > 8.x kthread_exit() is used for exiting kernel threads and wakes up the thread > pointer, but in 7.x kthread_exit() is used for exiting kernel processes and > wakes up the proc pointer. I think what is probably needed is to simply In the code, yes. Our documented behaviour as far as I can tell is different though, unless we equate a "thread handle" to "proc handle" prior to 8.x, which I don't think is the case - they are still different. > document that arrangement as such. Note that the sleeping on proc pointer I agree that the arrangement needs to be better documented. The change in 8.x is subtle enough that reading the kthread man page in 7.x and 8.x doesn't immediately make it obvious what's going on. > has been the documented way to synchronize with kthread_exit() since 5.0. > Could you please point me at this documentation? I've missed it in my poking around thus far. Cheers, Lawrence