ZFS port and thread_exit()

Konstantin Belousov kostikbel at gmail.com
Sat Feb 28 11:19:33 UTC 2015


On Fri, Feb 27, 2015 at 11:36:26PM -0800, Mark Johnston wrote:
> On Sat, Feb 28, 2015 at 06:31:44AM +0200, 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.
> 
> I'm not very familiar with the ZFS code, but:
> 
> The opensolaris compat proc.h #defines thread_exit to kthread_exit after
> FreeBSD's proc.h is included, so calls to thread_exit() in ZFS code should
> be replaced. Also, zfs.ko contains no references to thread_exit, but does
> reference kthread_exit.
> 
> > 
> > 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.
> 
> This is done in zfs_context.h, which includes
> cddl/contrib/opensolaris/head/thread.h, which #defines thr_exit(r) to
> pthread_exit(r). There is no other thread.h in the src tree, and
> libzpool.so references only pthread_exit. So it seems to me that the
> compat layer is doing the right thing.

Thank you for the explanation.

I realized why kthread_exit() did not popped up in my reading.
Still, it is very confusing, probably at the same scale as our/Linux
PAGE_MASK.


More information about the freebsd-threads mailing list