On Wed, 14 Apr 1999, Matthew Orgass wrote:

> On Wed, 14 Apr 1999, Matthew Orgass wrote:
> 
> > On Wed, 14 Apr 1999, Simon Burge wrote:
> > 
> > > [[ CC list trimmed back to current-users ]]
> > > 
> > > > 	% ln -s ./ test
> > > > 	% ln -s ./ test
> > > 
> > > I don't get this problem with my 1.3.{almost4} pmax, either on a local
> > > ffs filesystem or an nfs filesystem.  Is this a "guaranteed to happen
> > > every time" problem?
> > 
> >   I don't know the technical details, but apparently some ports don't have
> > it. It should happen every time on those that do.

I don't understand why it wouldn't happen on some ports. There is
definitly a double lock happening in the code, and it SHOULD be causing a
panic - it's in MI code so I don't understand why it'd panic in some
arch's and not others.

I've tried this on a pmax, and I do not get a hang. I'm not sure why, but
the process has gone to sleep on a bogus wait channel (40470f00). That
process, is solidly hung. I can't even reboot the machine.

> >   However, the advisory was unclear in that on 1.3.3 it is not the ln that
> > triggers the hang but an ls afterwards.
> 
>   Also unclear in the advisory is that 1.4_ALPHA only panics if you try
> linking your current directory.  If you do the same thing (+ ls) but link 
> a different directory, it too hangs.

You're right that the advisory was unclear, but it's not "a different
directory" which is the problem, but if the text of the symlink starts
with a "/" or not.

Say you're in /tmp/a, and /tmp/b exists.

ln -s ../b/ foo
ln -s ../b/ foo

will give  the locking panic.

ln -s /tmp/b/ foo
ln -s /tmp/b/ foo

will hang whenever you do something like an ls.

The important difference is that if the text of the link (the "../b/" or
"/tmp/b/" above) starts with a slash, we end up leaving around a locked
vnode which will never be unlocked. Any subsequent process to touch it
will hang indefinitly. If it does NOT have a begining slash, we get the
panic: locking against myself (or should :-)

Take care,

Bill