On Thu, 15 Apr 1999, Bill Studenmund wrote:

> Depending on whether some_path starts with a "/" or not, you get different
> problens. If no slash, you (should) get the panic, and with slash, you get
> a node left locked which will never get unlocked.

 Um...

[1.3.3]

cd /tmp
ln -s /tmp/ test
ln -s /tmp/ test
[hangs]

cd /tmp
ln -s / test
ln -s / test
ls
[hangs]

  Sure looks to me like the directory matters...

  It seems to me that the first case gets a "locking against myself" panic
in 1.4_ALPHA because the symlink is in the directory that is being linked
(which presumably needs to be linked too), thus it encounters the
unreleased lock while still linking, detects this, and panics.   In the
second case, it never hits the unreleased lock while in ln, but when
something else trys to access it hangs.

  In which case it would seem that the pmax behavior is what *should* be
happening.  ls should see that it is locked and patiently wait until it
gets unlocked, as happens with other blocking processes (like the
scsipi(?) bug that caused something to be blocked when I tried to open
/dev/cd0a that was recently fixed).  An intersting note on that bug was
that when I tried to read the disklabel, it would hang and couldn't be
killed, but nothing else was affected.  However when I tried to mount it,
the mount point also remained locked, which eventually caused the entire
system to hang.

  Presumably, pmax does something to avert a system hang in the second
case which i386 does not do.  It seems rather strange to me that the
second case should hang the entire system while the first case just hangs
the process; both fail to release a lock on part of the file system, yet
in the first case only that process (and any other that accesses that
particular file) is affected, while in the second case the entire system
eventually locks up (I guess in the ln case, the rest of the system runs
into the lock sooner?).

  I've probably passed the point of being useful here, so I won't
speculate any more, but it seems to be that whatever pmax is doing (or not
doing) is a Good Thing, even though it should never be needed unless there
is a bug in the kernel...

Matthew Orgass
darkstar@pgh.net