From owner-freebsd-threads@FreeBSD.ORG Thu Feb 26 10:20:09 2015 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91A721CA for ; Thu, 26 Feb 2015 10:20:09 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7871FCCB for ; Thu, 26 Feb 2015 10:20:09 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t1QAK9at057818 for ; Thu, 26 Feb 2015 10:20:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 198050] mtx_trylock from libstdthreads is blocking Date: Thu, 26 Feb 2015 10:20:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: vineela_17@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 10:20:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198050 Bug ID: 198050 Summary: mtx_trylock from libstdthreads is blocking Product: Base System Version: 10.1-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: threads Assignee: freebsd-threads@FreeBSD.org Reporter: vineela_17@yahoo.com mtx_trylock from mtx.c in libstdthreads calls pthread_mutex_lock instead of pthread_mutex_trylock and thus is blocking. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-threads@FreeBSD.ORG Thu Feb 26 10:39:48 2015 Return-Path: Delivered-To: threads@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 4F9EA560 for ; Thu, 26 Feb 2015 10:39:48 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E56A1E85 for ; Thu, 26 Feb 2015 10:39:47 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t1QAdfLa039664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Feb 2015 12:39:42 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t1QAdfLa039664 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t1QAdft2039663 for threads@freebsd.org; Thu, 26 Feb 2015 12:39:41 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 26 Feb 2015 12:39:41 +0200 From: Konstantin Belousov To: threads@freebsd.org Subject: umtx_lock MTX_SPIN->MTX_DEF Message-ID: <20150226103941.GI2379@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 10:39:48 -0000 Recent silly discussion on arch@ reminded me about umtx_lock, which is used by top-half of the kernel, but which is spin lock. Apparently, the only reason for this is that umtx_thread_exit() is called under the process spinlock, which put the requirement on the umtx_lock. Note that the witness static order list is wrong for the umtx_lock, umtx_lock is explicitely before any thread lock, so it is also before sleepq locks. I think it went unnoticed because witness for spinlocks currently broken due to console locks. Below is the patch which changes umtx_lock to the sleepable mutex. For the reason above, I have to move calls to umtx_thread_exit() from thread_exit() earlier in each caller, when the process spin lock is not yet taken. Patch was lightly tested. Please review the idea. diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c index ce1f8f9..ef8dcb2 100644 --- a/sys/kern/kern_exit.c +++ b/sys/kern/kern_exit.c @@ -71,6 +71,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #ifdef KTRACE #include #endif @@ -633,6 +634,7 @@ exit1(struct thread *td, int rv) wakeup(p->p_pptr); cv_broadcast(&p->p_pwait); sched_exit(p->p_pptr, td); + umtx_thread_exit(td); PROC_SLOCK(p); p->p_state = PRS_ZOMBIE; PROC_UNLOCK(p->p_pptr); diff --git a/sys/kern/kern_thr.c b/sys/kern/kern_thr.c index b298f33..280bc0b 100644 --- a/sys/kern/kern_thr.c +++ b/sys/kern/kern_thr.c @@ -322,6 +322,7 @@ sys_thr_exit(struct thread *td, struct thr_exit_args *uap) LIST_REMOVE(td, td_hash); rw_wunlock(&tidhash_lock); tdsigcleanup(td); + umtx_thread_exit(td); PROC_SLOCK(p); thread_stopped(p); thread_exit(); diff --git a/sys/kern/kern_thread.c b/sys/kern/kern_thread.c index 2d0b0d2..dd11e5c 100644 --- a/sys/kern/kern_thread.c +++ b/sys/kern/kern_thread.c @@ -413,7 +413,6 @@ thread_exit(void) #ifdef AUDIT AUDIT_SYSCALL_EXIT(0, td); #endif - umtx_thread_exit(td); /* * drop FPU & debug register state storage, or any other * architecture specific resources that @@ -864,6 +863,7 @@ thread_suspend_check(int return_instead) tidhash_remove(td); PROC_LOCK(p); tdsigcleanup(td); + umtx_thread_exit(td); PROC_SLOCK(p); thread_stopped(p); thread_exit(); diff --git a/sys/kern/kern_umtx.c b/sys/kern/kern_umtx.c index 721f4f0..de57f9e 100644 --- a/sys/kern/kern_umtx.c +++ b/sys/kern/kern_umtx.c @@ -396,7 +396,7 @@ umtxq_sysinit(void *arg __unused) #ifdef UMTX_PROFILING umtx_init_profiling(); #endif - mtx_init(&umtx_lock, "umtx lock", NULL, MTX_SPIN); + mtx_init(&umtx_lock, "umtx lock", NULL, MTX_DEF); EVENTHANDLER_REGISTER(process_exec, umtx_exec_hook, NULL, EVENTHANDLER_PRI_ANY); } @@ -1467,9 +1467,9 @@ umtx_pi_claim(struct umtx_pi *pi, struct thread *owner) struct umtx_q *uq, *uq_owner; uq_owner = owner->td_umtxq; - mtx_lock_spin(&umtx_lock); + mtx_lock(&umtx_lock); if (pi->pi_owner == owner) { - mtx_unlock_spin(&umtx_lock); + mtx_unlock(&umtx_lock); return (0); } @@ -1477,7 +1477,7 @@ umtx_pi_claim(struct umtx_pi *pi, struct thread *owner) /* * userland may have already messed the mutex, sigh. */ - mtx_unlock_spin(&umtx_lock); + mtx_unlock(&umtx_lock); return (EPERM); } umtx_pi_setowner(pi, owner); @@ -1491,7 +1491,7 @@ umtx_pi_claim(struct umtx_pi *pi, struct thread *owner) sched_lend_user_prio(owner, pri); thread_unlock(owner); } - mtx_unlock_spin(&umtx_lock); + mtx_unlock(&umtx_lock); return (0); } @@ -1506,7 +1506,7 @@ umtx_pi_adjust(struct thread *td, u_char oldpri) struct umtx_pi *pi; uq = td->td_umtxq; - mtx_lock_spin(&umtx_lock); + mtx_lock(&umtx_lock); /* * Pick up the lock that td is blocked on. */ @@ -1515,7 +1515,7 @@ umtx_pi_adjust(struct thread *td, u_char oldpri) umtx_pi_adjust_thread(pi, td); umtx_repropagate_priority(pi); } - mtx_unlock_spin(&umtx_lock); + mtx_unlock(&umtx_lock); } /* @@ -1537,12 +1537,12 @@ umtxq_sleep_pi(struct umtx_q *uq, struct umtx_pi *pi, UMTXQ_LOCKED_ASSERT(uc); KASSERT(uc->uc_busy != 0, ("umtx chain is not busy")); umtxq_insert(uq); - mtx_lock_spin(&umtx_lock); + mtx_lock(&umtx_lock); if (pi->pi_owner == NULL) { - mtx_unlock_spin(&umtx_lock); + mtx_unlock(&umtx_lock); /* XXX Only look up thread in current process. */ td1 = tdfind(owner, curproc->p_pid); - mtx_lock_spin(&umtx_lock); + mtx_lock(&umtx_lock); if (td1 != NULL) { if (pi->pi_owner == NULL) umtx_pi_setowner(pi, td1); @@ -1566,20 +1566,20 @@ umtxq_sleep_pi(struct umtx_q *uq, struct umtx_pi *pi, td->td_flags |= TDF_UPIBLOCKED; thread_unlock(td); umtx_propagate_priority(td); - mtx_unlock_spin(&umtx_lock); + mtx_unlock(&umtx_lock); umtxq_unbusy(&uq->uq_key); error = umtxq_sleep(uq, wmesg, timo); umtxq_remove(uq); - mtx_lock_spin(&umtx_lock); + mtx_lock(&umtx_lock); uq->uq_pi_blocked = NULL; thread_lock(td); td->td_flags &= ~TDF_UPIBLOCKED; thread_unlock(td); TAILQ_REMOVE(&pi->pi_blocked, uq, uq_lockq); umtx_repropagate_priority(pi); - mtx_unlock_spin(&umtx_lock); + mtx_unlock(&umtx_lock); umtxq_unlock(&uq->uq_key); return (error); @@ -1611,7 +1611,7 @@ umtx_pi_unref(struct umtx_pi *pi) UMTXQ_LOCKED_ASSERT(uc); KASSERT(pi->pi_refcount > 0, ("invalid reference count")); if (--pi->pi_refcount == 0) { - mtx_lock_spin(&umtx_lock); + mtx_lock(&umtx_lock); if (pi->pi_owner != NULL) { TAILQ_REMOVE(&pi->pi_owner->td_umtxq->uq_pi_contested, pi, pi_link); @@ -1619,7 +1619,7 @@ umtx_pi_unref(struct umtx_pi *pi) } KASSERT(TAILQ_EMPTY(&pi->pi_blocked), ("blocked queue not empty")); - mtx_unlock_spin(&umtx_lock); + mtx_unlock(&umtx_lock); TAILQ_REMOVE(&uc->uc_pi_list, pi, pi_hashlink); umtx_pi_free(pi); } @@ -1873,11 +1873,11 @@ do_unlock_pi(struct thread *td, struct umutex *m, uint32_t flags) umtxq_busy(&key); count = umtxq_count_pi(&key, &uq_first); if (uq_first != NULL) { - mtx_lock_spin(&umtx_lock); + mtx_lock(&umtx_lock); pi = uq_first->uq_pi_blocked; KASSERT(pi != NULL, ("pi == NULL?")); if (pi->pi_owner != curthread) { - mtx_unlock_spin(&umtx_lock); + mtx_unlock(&umtx_lock); umtxq_unbusy(&key); umtxq_unlock(&key); umtx_key_release(&key); @@ -1903,7 +1903,7 @@ do_unlock_pi(struct thread *td, struct umutex *m, uint32_t flags) thread_lock(curthread); sched_lend_user_prio(curthread, pri); thread_unlock(curthread); - mtx_unlock_spin(&umtx_lock); + mtx_unlock(&umtx_lock); if (uq_first) umtxq_signal_thread(uq_first); } else { @@ -1920,10 +1920,10 @@ do_unlock_pi(struct thread *td, struct umutex *m, uint32_t flags) * umtx_pi, and unlocked the umtxq. * If the current thread owns it, it must disown it. */ - mtx_lock_spin(&umtx_lock); + mtx_lock(&umtx_lock); if (pi->pi_owner == td) umtx_pi_disown(pi); - mtx_unlock_spin(&umtx_lock); + mtx_unlock(&umtx_lock); } } umtxq_unlock(&key); @@ -1986,9 +1986,9 @@ do_lock_pp(struct thread *td, struct umutex *m, uint32_t flags, goto out; } - mtx_lock_spin(&umtx_lock); + mtx_lock(&umtx_lock); if (UPRI(td) < PRI_MIN_REALTIME + ceiling) { - mtx_unlock_spin(&umtx_lock); + mtx_unlock(&umtx_lock); error = EINVAL; goto out; } @@ -1999,7 +1999,7 @@ do_lock_pp(struct thread *td, struct umutex *m, uint32_t flags, sched_lend_user_prio(td, uq->uq_inherited_pri); thread_unlock(td); } - mtx_unlock_spin(&umtx_lock); + mtx_unlock(&umtx_lock); rv = casueword32(&m->m_owner, UMUTEX_CONTESTED, &owner, id | UMUTEX_CONTESTED); @@ -2034,7 +2034,7 @@ do_lock_pp(struct thread *td, struct umutex *m, uint32_t flags, umtxq_remove(uq); umtxq_unlock(&uq->uq_key); - mtx_lock_spin(&umtx_lock); + mtx_lock(&umtx_lock); uq->uq_inherited_pri = old_inherited_pri; pri = PRI_MAX; TAILQ_FOREACH(pi, &uq->uq_pi_contested, pi_link) { @@ -2049,11 +2049,11 @@ do_lock_pp(struct thread *td, struct umutex *m, uint32_t flags, thread_lock(td); sched_lend_user_prio(td, pri); thread_unlock(td); - mtx_unlock_spin(&umtx_lock); + mtx_unlock(&umtx_lock); } if (error != 0) { - mtx_lock_spin(&umtx_lock); + mtx_lock(&umtx_lock); uq->uq_inherited_pri = old_inherited_pri; pri = PRI_MAX; TAILQ_FOREACH(pi, &uq->uq_pi_contested, pi_link) { @@ -2068,7 +2068,7 @@ do_lock_pp(struct thread *td, struct umutex *m, uint32_t flags, thread_lock(td); sched_lend_user_prio(td, pri); thread_unlock(td); - mtx_unlock_spin(&umtx_lock); + mtx_unlock(&umtx_lock); } out: @@ -2140,7 +2140,7 @@ do_unlock_pp(struct thread *td, struct umutex *m, uint32_t flags) if (error == -1) error = EFAULT; else { - mtx_lock_spin(&umtx_lock); + mtx_lock(&umtx_lock); if (su != 0) uq->uq_inherited_pri = new_inherited_pri; pri = PRI_MAX; @@ -2156,7 +2156,7 @@ do_unlock_pp(struct thread *td, struct umutex *m, uint32_t flags) thread_lock(td); sched_lend_user_prio(td, pri); thread_unlock(td); - mtx_unlock_spin(&umtx_lock); + mtx_unlock(&umtx_lock); } umtx_key_release(&key); return (error); @@ -3841,13 +3841,13 @@ umtx_thread_cleanup(struct thread *td) if ((uq = td->td_umtxq) == NULL) return; - mtx_lock_spin(&umtx_lock); + mtx_lock(&umtx_lock); uq->uq_inherited_pri = PRI_MAX; while ((pi = TAILQ_FIRST(&uq->uq_pi_contested)) != NULL) { pi->pi_owner = NULL; TAILQ_REMOVE(&uq->uq_pi_contested, pi, pi_link); } - mtx_unlock_spin(&umtx_lock); + mtx_unlock(&umtx_lock); thread_lock(td); sched_lend_user_prio(td, PRI_MAX); thread_unlock(td); diff --git a/sys/kern/subr_witness.c b/sys/kern/subr_witness.c index 518fb49..f80026a 100644 --- a/sys/kern/subr_witness.c +++ b/sys/kern/subr_witness.c @@ -492,6 +492,11 @@ static struct witness_order_list_entry order_lists[] = { { "time lock", &lock_class_mtx_sleep }, { NULL, NULL }, /* + * umtx + */ + { "umtx lock", &lock_class_mtx_sleep }, + { NULL, NULL }, + /* * Sockets */ { "accept", &lock_class_mtx_sleep }, @@ -637,7 +642,6 @@ static struct witness_order_list_entry order_lists[] = { #endif { "process slock", &lock_class_mtx_spin }, { "sleepq chain", &lock_class_mtx_spin }, - { "umtx lock", &lock_class_mtx_spin }, { "rm_spinlock", &lock_class_mtx_spin }, { "turnstile chain", &lock_class_mtx_spin }, { "turnstile lock", &lock_class_mtx_spin }, From owner-freebsd-threads@FreeBSD.ORG Thu Feb 26 11:11:53 2015 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C8DCB8E for ; Thu, 26 Feb 2015 11:11:53 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 231161FF for ; Thu, 26 Feb 2015 11:11:53 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t1QBBqp9043791 for ; Thu, 26 Feb 2015 11:11:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 198050] mtx_trylock from libstdthreads is blocking Date: Thu, 26 Feb 2015 11:11:52 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 11:11:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198050 Konstantin Belousov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kib@FreeBSD.org --- Comment #1 from Konstantin Belousov --- Created attachment 153543 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=153543&action=edit Use pthread_mutex_trylock(). This is the typo, code correctly tests for EBUSY, but called wrong function. Please test. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-threads@FreeBSD.ORG Thu Feb 26 16:02:39 2015 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DBCEDCA2 for ; Thu, 26 Feb 2015 16:02:39 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C2031B9E for ; Thu, 26 Feb 2015 16:02:39 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t1QG2dFI017821 for ; Thu, 26 Feb 2015 16:02:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 198050] mtx_trylock from libstdthreads is blocking Date: Thu, 26 Feb 2015 16:02:39 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: vineela_17@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 16:02:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198050 --- Comment #2 from Vineela --- Comment on attachment 153543 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=153543 Use pthread_mutex_trylock(). Works fine. Thank you. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-threads@FreeBSD.ORG Thu Feb 26 16:40:53 2015 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F41F9D13 for ; Thu, 26 Feb 2015 16:40:52 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DA739B1 for ; Thu, 26 Feb 2015 16:40:52 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t1QGeqcR061171 for ; Thu, 26 Feb 2015 16:40:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 198050] mtx_trylock from libstdthreads is blocking Date: Thu, 26 Feb 2015 16:40:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 16:40:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198050 --- Comment #3 from commit-hook@freebsd.org --- A commit references this bug: Author: kib Date: Thu Feb 26 16:39:57 UTC 2015 New revision: 279326 URL: https://svnweb.freebsd.org/changeset/base/279326 Log: Use pthread_mutex_trylock(3) to implement mtx_trylock(3). Noted and tested by: Vineela PR: 198050 Sponsored by: The FreeBSD Foundation MFC after: 1 week Changes: head/lib/libstdthreads/mtx.c -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-threads@FreeBSD.ORG Thu Feb 26 17:15:29 2015 Return-Path: Delivered-To: freebsd-threads@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 45D12883 for ; Thu, 26 Feb 2015 17:15:29 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1EC4A658 for ; Thu, 26 Feb 2015 17:15:29 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 21525B926; Thu, 26 Feb 2015 12:15:27 -0500 (EST) From: John Baldwin To: freebsd-threads@freebsd.org Subject: Re: umtx_lock MTX_SPIN->MTX_DEF Date: Thu, 26 Feb 2015 09:54:43 -0500 Message-ID: <2605108.iA580FgBvu@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <20150226103941.GI2379@kib.kiev.ua> References: <20150226103941.GI2379@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 26 Feb 2015 12:15:27 -0500 (EST) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 17:15:29 -0000 On Thursday, February 26, 2015 12:39:41 PM Konstantin Belousov wrote: > Recent silly discussion on arch@ reminded me about umtx_lock, which is > used by top-half of the kernel, but which is spin lock. Apparently, the > only reason for this is that umtx_thread_exit() is called under the > process spinlock, which put the requirement on the umtx_lock. Note that > the witness static order list is wrong for the umtx_lock, umtx_lock is > explicitely before any thread lock, so it is also before sleepq locks. > I think it went unnoticed because witness for spinlocks currently broken > due to console locks. > > Below is the patch which changes umtx_lock to the sleepable mutex. For the > reason above, I have to move calls to umtx_thread_exit() from thread_exit() > earlier in each caller, when the process spin lock is not yet taken. > > Patch was lightly tested. Please review the idea. Definitely a fan of the idea, and after a cursory look, the patch seems ok. -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Fri Feb 27 21:28:05 2015 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A08466EF for ; Fri, 27 Feb 2015 21:28:05 +0000 (UTC) Received: from cgi15.web.eu.clara.net (cgi15.web.eu.clara.net [81.171.239.165]) by mx1.freebsd.org (Postfix) with ESMTP id 4C766C67 for ; Fri, 27 Feb 2015 21:28:04 +0000 (UTC) Received: from localhost ([127.0.0.1]:35709 helo=cgi15.web.eu.clara.net ident=Debian-exim) by cgi15.web.eu.clara.net with esmtpa (Exim 4.69) (envelope-from ) id 1YRSS2-0008Uq-3H for freebsd-threads@freebsd.org; Fri, 27 Feb 2015 21:28:02 +0000 Received: from web40926 by cgi15.web.eu.clara.net with local (Exim 4.69) (envelope-from ) id 1YRSRu-0008Um-Tj for freebsd-threads@freebsd.org; Fri, 27 Feb 2015 21:27:54 +0000 To: freebsd-threads@freebsd.org Subject: FREE, Payment for driving on toll road, invoice #000228022 Date: Fri, 27 Feb 2015 21:27:54 +0000 From: "E-ZPass Support" Reply-To: "E-ZPass Support" Message-ID: <459f04c5536c18cdb505d49aa59f6945@bed-11.uk.clara.net> X-Priority: 3 MIME-Version: 1.0 Sender: web40926 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 21:28:05 -0000 Dear Free, You have a unpaid bill for using toll road. You are kindly asked to service your debt in the shortest time possible. You can review the invoice in the attachment. Yours faithfully, Oscar Rowland, E-ZPass Support. From owner-freebsd-threads@FreeBSD.ORG Sat Feb 28 04:31:50 2015 Return-Path: Delivered-To: threads@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 614DF4AE; Sat, 28 Feb 2015 04:31:50 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E25A3F5E; Sat, 28 Feb 2015 04:31:49 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t1S4ViX8082098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Feb 2015 06:31:44 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t1S4ViX8082098 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t1S4ViRX082097; Sat, 28 Feb 2015 06:31:44 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 28 Feb 2015 06:31:44 +0200 From: Konstantin Belousov To: fs@freebsd.org Subject: ZFS port and thread_exit() Message-ID: <20150228043144.GQ2379@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2015 04:31:50 -0000 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 ? From owner-freebsd-threads@FreeBSD.ORG Sat Feb 28 06:23:53 2015 Return-Path: Delivered-To: threads@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 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 , 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-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. From owner-freebsd-threads@FreeBSD.ORG Sat Feb 28 07:36:32 2015 Return-Path: Delivered-To: threads@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 EA35145C; Sat, 28 Feb 2015 07:36:32 +0000 (UTC) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B6530C5; Sat, 28 Feb 2015 07:36:32 +0000 (UTC) Received: by padbj1 with SMTP id bj1so2908113pad.11; Fri, 27 Feb 2015 23:36:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=8lQMRl9788W2sRuLfOjF9I3SXtGuBMhdsPrhwY4rnkQ=; b=iR0Dwh3DRuvk+GPJ0CoNSD/gnM2yezis7olLaxIEkjDo9BhQst/Rxh4Sf3qRQJ8QKl orMRbL9m/Wxvdi49sEQ8wW9XmNGtj9zwGHSvaiq/7AUNd1E3+X9Ri7q57uHf3Fe86ERW 8vpb5GHwbCIMmmjhJKHxmALER7Xtjmn+U8+cuJ7eccv5D5dQ1+E/yoUGJQemtvc8m1Tc 6ARPjTOUSsm6AeEE7U0F1dMxij+st2v9BdEfspa/Esoyb+23LkjVWkwqdgMhe/iw0aLI yLO9z/bzW7iN6bfioQCCSPKQhrzQ9xSYgYIlf9Azup4Oa3ANtlLujJXLee+ODwFhOKj8 t25w== X-Received: by 10.67.7.10 with SMTP id cy10mr29448764pad.151.1425108992214; Fri, 27 Feb 2015 23:36:32 -0800 (PST) Received: from raichu (216-243-33-91.users.condointernet.net. [216.243.33.91]) by mx.google.com with ESMTPSA id qn14sm5961247pab.33.2015.02.27.23.36.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Feb 2015 23:36:31 -0800 (PST) Sender: Mark Johnston Date: Fri, 27 Feb 2015 23:36:26 -0800 From: Mark Johnston To: Konstantin Belousov Subject: Re: ZFS port and thread_exit() Message-ID: <20150228073625.GA2627@raichu> References: <20150228043144.GQ2379@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150228043144.GQ2379@kib.kiev.ua> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: threads@freebsd.org, fs@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2015 07:36:33 -0000 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. > > Could somebody interested in ZFS look into the issues ? > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-threads@FreeBSD.ORG Sat Feb 28 11:19:33 2015 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C3AEAA3; Sat, 28 Feb 2015 11:19:33 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 739FB846; Sat, 28 Feb 2015 11:19:32 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t1SBJQ0U071852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Feb 2015 13:19:26 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t1SBJQ0U071852 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t1SBJQQK071851; Sat, 28 Feb 2015 13:19:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 28 Feb 2015 13:19:26 +0200 From: Konstantin Belousov To: Mark Johnston Subject: Re: ZFS port and thread_exit() Message-ID: <20150228111926.GR2379@kib.kiev.ua> References: <20150228043144.GQ2379@kib.kiev.ua> <20150228073625.GA2627@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150228073625.GA2627@raichu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: threads@freebsd.org, fs@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2015 11:19:33 -0000 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.