Date: Sun, 18 Mar 2007 20:23:12 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, freebsd-current@freebsd.org, Tillman Hodgson <tillman@seekingfire.com> Subject: Re: Experiencing hangs on SMP box with no console messages given for clues. Details inside. Message-ID: <20070318202228.L7579@fledge.watson.org> In-Reply-To: <45FD8906.2060700@elischer.org> References: <20070308125927.GA1265@seekingfire.com> <20070308204041.GA55240@xor.obsecurity.org> <20070310153206.GF1230@seekingfire.com> <3bbf2fe10703100749h14e9b075wb6d730ed7c9189f8@mail.gmail.com> <20070310161423.GA1256@seekingfire.com> <20070310193946.GA96514@xor.obsecurity.org> <20070311044033.GB1256@seekingfire.com> <20070311062637.GA1256@seekingfire.com> <20070318125635.N62476@maildrop.int.zabbadoz.net> <20070318154536.U20456@fledge.watson.org> <45FD8906.2060700@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 18 Mar 2007, Julian Elischer wrote: >> If using uid/gid firewall rules, make sure to read the pertinent man pages >> regarding setting debug.mpsafenet=0 in loader.conf to avoid deadlocks. This >> is only a workaround for the issue, and when debug.mpsafenet is removed, >> this workaround will no longer be available. The authors/maintainers of >> the various firewall packages need to correct these problems or the lock >> order reversals (and associated deadlocks) will persist. > > I actually have some work on this in an experimental branch.. it removes the > requirement for users of ipfw to hold a lock on it by making the firewall > table an array rather than a lined list and then using a read-copy-replace > write semantic with reference conts on the array.. a bit like the cred > structures that processes and threads have.. i.e. you never change it, just > replace it with a new one.. previosu users ofthe structure just keep using > the one they have and release the reference when they are done.. (freeing if > it goes to 0). the result is that since the firewall lock goes away, so does > the lock order reversal. Great -- this is precisely the sort of fix we require. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070318202228.L7579>