Can a process stop with a locked inode?

[John F Haugh II]

In article <1991Jun26.093356.12661 at prl.dec.com> boyd at prl.dec.com (Boyd Roberts) writes:
>In article <1991Jun25.232436.1215039 at locus.com>, richard at locus.com (Richard M. Mathews) writes:
>> It sounds like that is what is happening.  This is possible if you ever
>> sleep at pri>PZERO while the inode is locked.
>
>This is nonsense.  When the inode is locked no process, apart
>from the one with the lock, can operate on it.  Sleeping with
>the inode locked may make things worse, but the priority is irrelevant.

No, it isn't nonsense.  The reason that a level like "PZERO" exists is
to distinguish between things that can happen real fast (short term
sleeps) versus real slow (longer term sleeps).  PINOD is as low as it
is to insure that the sleeping process 1) isn't interrupted (including
SIGSTOP or SIGTSTP) and 2) gets the CPU back.  No process should =ever=
sleep with an inode locked above PZERO for many very simple and obvious
reasons.

>Unless you're really sure about what you're doing, any kernel data you observe
>will just confuse you.  Even in a static system (a crash dump) it is often
>far from obvious what is going on.  Maybe the `problem' isn't with `cp'.

Trust me, Richard knows exactly what he is talking about.  Arguing with
him is not unlike arguing with Guy Harris or Doug Gwyn.  It gives you this
warm feeling in your stomach that is often confused with "warm fuzzies",
but which is really heartburn.  Richard's analysis is dead on.  Unless you
don't have source code access, crash is almost always your best friend.
-- 
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) |  Domain: jfh at rpp386.cactus.org
"UNIX signals are not interrupts.  Worse, SIGCHLD/SIGCLD is not even a UNIX
 signal, it's an abomination."  -- Doug Gwyn