Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!mejac!orchard.la.locus.com!devnet.la.locus.com!richard
From: richard@locus.com (Richard M. Mathews)
Newsgroups: comp.unix.wizards
Subject: Re: Can a process stop with a locked inode?
Message-ID: <1991Jun25.232436.1215039@locus.com>
Date: 25 Jun 91 23:24:36 GMT
References: <4200@island.COM>
Organization: Locus Computing Corporation, Los Angeles, California
Lines: 26

hue@coney.island.COM (Pond Scum) writes:

>No data is lost or anything else, but if I do an ls -l it hangs until
>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
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.

If a quick glance at the 2nd arguments to your sleep calls doesn't find
the bad sleep call, you could use "crash" or equivalent to look at the
kernel stack of the "cp" process.  (If a program to find the kernel
stack is not available for you, you might have to check out page table
entries or page pointers in the proc structure to find that process's
kernel stack.)  That should help you find exactly where the process is
sleeping.

Richard M. Mathews			 Freedom for Lithuania
richard@locus.com				Laisve!
lcc!richard@seas.ucla.edu
...!{uunet|ucla-se|turnkey}!lcc!richard