Can a process stop with a locked inode?

[Pond Scum]

In article <1991Jun25.232436.1215039 at locus.com> richard at locus.com (Richard M. Mathews) writes:
>hue at coney.island.COM (Pond Scum) writes:
>>the cp starts running again or exits.  It's as if the cp is getting stopped
>>while holding a lock on the inode for the destination file, and the stat
>>is sleeping until the inode is free.  Is this even possible?
>
>It sounds like that is what is happening.  This is possible if you ever
>sleep at pri>PZERO while the inode is locked.  First check the wchan

I don't call sleep except when I need a buf to do a special command,
and that isn't happening here (only through ioctl).  All this stuff
is coming through the strategy routine from the ufs file system, so I
figure someone higher up is calling iowait() (biowait()) when they need
to sleep, and sleeping at PRIBIO.

>of the "ls" process.  If it points at the incore inode, then you know
>SOMEONE has the inode locked, the "cp" is a good candidate, and you know
>that since it did get stopped it must have been at pri>PZERO; thus this
>is almost definitely the problem.

Well, I had another theory, but it doesn't explain everything.  Writes to
an ordinary file (a "fast device") are normally not interruptable because
they sleep at priorities higher than PZERO (lower numerically), correct?
In SunOS 4.1.1, they made some change to the kernel that makes writes to
an ordinary files interruptable (and not restartable!).  It seems to me that
this same change would allow a stop signal to interrupt cp while it had
an inode locked and stop it, and cause the ls to hang when it tried to
stat the file.


Jonathan Hue	Island Graphics Corporation, Graphic Arts Division
hue at island.COM	{sun,uunet}!island!hue