Date: Wed, 12 Apr 2017 11:53:42 -0700 (PDT) From: Chris Torek <torek@elf.torek.net> To: ablacktshirt@gmail.com, imp@bsdimp.com Cc: ed@nuxi.nl, freebsd-hackers@freebsd.org, rysto32@gmail.com Subject: Re: Understanding the FreeBSD locking mechanism Message-ID: <201704121853.v3CIrg5d055158@elf.torek.net> In-Reply-To: <aa5f22f4-0bec-f2a4-554b-f0055398eb7d@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> If you obtain the locks in the other order -- i.e., if you grab >> the PROC_STATLOCK first, then try to lock PROC_LOCK -- you are >> trying to take a spin-type mutex while holding a default mutex, >Is this a typo? I guess you mean something like "you are trying >to take a blocking mutex while holding spin-type mutex". Yes, or rather brain-o (swapping words) -- these most often happen if I am interrupted while composing a message :-) >I think I get your point: if you take a spin-type mutex, you >already disable interrupt, which in effect means that no other >code can preempt you. Under this circumstance, if you continue to >take a blocking mutex, you may get blocked. Since you already >disable interrupt and nobody can interrupt/preempt you, you are blocked >on that CPU, not being able to do anything, which is pretty much a >"deadlock" (actually this is not a deadlock, but, it is similar) Right. It *may* deadlock, and it is definitely not good -- and the INVARIANTS kernel will check and panic. Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201704121853.v3CIrg5d055158>