From owner-freebsd-current Sun Mar 3 12:14:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA11147 for current-outgoing; Sun, 3 Mar 1996 12:14:27 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA11141 for ; Sun, 3 Mar 1996 12:14:22 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA04509; Sun, 3 Mar 1996 13:10:58 -0700 From: Terry Lambert Message-Id: <199603032010.NAA04509@phaeton.artisoft.com> Subject: Re: Another tmpfs bug in SunOS 4 (fwd) To: coredump@nervosa.com (invalid opcode) Date: Sun, 3 Mar 1996 13:10:57 -0700 (MST) Cc: current@FreeBSD.org In-Reply-To: from "invalid opcode" at Mar 3, 96 02:03:33 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk > Hmm, could this be similar to our current problems with mv and panics? > > == Chris Layne ============================================================= > == coredump@nervosa.com ================ http://www.nervosa.com/~coredump == > > ---------- Forwarded message ---------- > Date: Sat, 2 Dec 1995 23:50:40 +0100 > From: Arfst Ludwig > To: Multiple recipients of list BUGTRAQ > Subject: Another tmpfs bug in SunOS 4 > > Hi! > > Unprivileged users can crash the system such > that a power down power up cyle is needed. > > Vulnerable OS is (at least) SunOS 4.1.3. > > With the right permissions (umask) the following > sequence crahes the system. The kernel does not > panic, nor the abort sequece enters the boot > promt, the system is halted, need to power down. This is a problem with a starvation deadlock due to a problem in the implementation of the reeentrancy protections in the tmpfs in Solaris. This is a well known problem, and seems to result because of a bad lock placement in tmpfs, coupled with the fact that locks and mutexes in Solaris are not hierarchical in nature. I'd also say it results from Sun being unwilling to document the FS locking model, even internally. 8-|. Basically, this means that they can't detect a deadly embrace between the two locking systems when it occurs because they are incapable of computing transitive closure over the two graphs because their design is such that there is not a common root for both locking systems. This is not something we have to worry about now, and because we are well aware of the design issues in hierarchical locking for kernel multithreading and exception/interrupt reentrancy, it's something we will be avoiding when we get to SMP/kernel threading anyway. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.