From owner-freebsd-drivers@FreeBSD.ORG Tue Feb 17 19:29:24 2015 Return-Path: Delivered-To: freebsd-drivers@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 5C33AF24 for ; Tue, 17 Feb 2015 19:29:24 +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 33C69771 for ; Tue, 17 Feb 2015 19:29:24 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 67187B918; Tue, 17 Feb 2015 14:29:22 -0500 (EST) From: John Baldwin To: freebsd-drivers@freebsd.org Subject: Re: Locking a MTX_DEF inside an interrupt thread Date: Tue, 17 Feb 2015 13:15:39 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20141211195821.GA3827@ox> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201502171315.39554.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 17 Feb 2015 14:29:22 -0500 (EST) Cc: Martin Galvan X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 19:29:24 -0000 On Friday, December 12, 2014 2:34:10 am Martin Galvan wrote: > 2014-12-11 16:58 GMT-03:00 Navdeep Parhar : > > MTX_DEF mutexes can block but never sleep, and it is perfectly safe to acquire > > them in an ithread. > > Thanks a lot for your answer. At first I was a bit confused on what > the actual difference between "blocking" and "sleeping" was, but then > I read the "Bounded vs Unbounded Sleep" section from locking(9) and it > cleared things out a bit. > > I still don't understand why can't we sleep (i.e. do an 'unbounded > sleep') inside an ithread. What would be the problem, exactly? Interrupts (and ithreads) need to "work" during low-memory conditions when malloc() could block. Consider the case of shared interrupts where your driver shares an ithread with the storage driver that needs to use its interrupt to complete a DMA write of a dirty page to free up memory. If you sleep in the shared ithread then the storage interrupt handler will never run and the system would deadlock. This also means that even in non-ithread context unbounded sleeps cannot be done while holding a mutex. This ensures that as long as CPU is available, you can always make forward progress. You can always defer slower, more expensive tasks to a different context via a taskqueue that your interrupt handler schedules. -- John Baldwin