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