Date: Sun, 3 Mar 1996 13:10:57 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: coredump@nervosa.com (invalid opcode) Cc: current@FreeBSD.org Subject: Re: Another tmpfs bug in SunOS 4 (fwd) Message-ID: <199603032010.NAA04509@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.91.960303020306.2776C-100000@nervosa.com> from "invalid opcode" at Mar 3, 96 02:03:33 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 <Arfst.Ludwig@luxor.in-berlin.de> > To: Multiple recipients of list BUGTRAQ <BUGTRAQ@CRIMELAB.COM> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603032010.NAA04509>