From owner-freebsd-fs@FreeBSD.ORG  Sat Feb 28 06:23:53 2015
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Delivered-To: fs@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id 3A6B5C59;
 Sat, 28 Feb 2015 06:23:53 +0000 (UTC)
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
 by mx1.freebsd.org (Postfix) with ESMTP id 2885EAC4;
 Sat, 28 Feb 2015 06:23:52 +0000 (UTC)
Received: from AlfredMacbookAir.local (hudsonhotel209.h.subnet.rcn.com
 [207.237.151.136])
 by elvis.mu.org (Postfix) with ESMTPSA id 6EEE4341F8AC;
 Fri, 27 Feb 2015 22:23:45 -0800 (PST)
Message-ID: <54F15FC9.2090209@mu.org>
Date: Sat, 28 Feb 2015 01:27:21 -0500
From: Alfred Perlstein <bright@mu.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
 rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Konstantin Belousov <kostikbel@gmail.com>, fs@freebsd.org
Subject: Re: ZFS port and thread_exit()
References: <20150228043144.GQ2379@kib.kiev.ua>
In-Reply-To: <20150228043144.GQ2379@kib.kiev.ua>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Cc: threads@freebsd.org
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.18-1
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs/>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Feb 2015 06:23:53 -0000



On 2/27/15 11:31 PM, Konstantin Belousov wrote:
> While looking for some change to thread_exit(), I noted that ZFS
> on FreeBSD directly calls thread_exit(). It simply cannot work,
> thread_exit() is the internal function which requires the thread and
> process state prepared for it call. Among most obvious things, process
> spin lock must be held, but also several cleanups and accounting have to
> be done before the call.
>
> I believe the function just happens to have the same name as the Solaris
> counterpart, and for some reasons it is never called. If this is true,
> kthread_exit() should be used instead.
>
> Also, I noted that the userspace port defines thread_exit() as
> thr_exit(NULL). Again, the direct invocation of the syscall does not
> look right. The libthr library must do some cleanups on the thread exit,
> which are not done if syscall is invoked by an application code. Also,
> the thread itself gets no destructor calls.
>
> Could somebody interested in ZFS look into the issues ?
this sounds v important, needs a bugzilla in case no one steps up now, 
should be marked high priority.