> Hmm, could this be similar to our current problems with mv and panics?
> == Chris Layne =============================================================
> == firstname.lastname@example.org ================ 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
> 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.
Any opinions in this posting are my own and not those of my present
or previous employers.