Re: Best way to find where a lock is taken and not released?

[Nigel Cunningham]

Hi.

On Sun, 2004-10-17 at 02:46, Andreas Dilger wrote:
> On Oct 16, 2004  19:30 +1000, Nigel Cunningham wrote:
> > I saw a hang the other day (2.6.8.1) where all other processes except
> > the suspending to disk one were refrigerated and the process doing the
> > suspending was stuck trying to take the dcache_lock via
> > shrink_all_memory. Obviously some path called via shrink_all_memory had
> > taken the lock and not released it, then tried to retake it _or_ another
> > process had taken the lock and then not released it when backing out and
> > entering the refrigator. My question is, what's the best way to find the
> > path on which this occurs? Grepping, I see dcache_lock all over the
> > show, so if there's a more efficient method that reading the files, I'd
> > like to learn it. It occurs to me that I might try wrapping calls to
> > lock and unlock that lock in printks, but I'm wondering if there's some
> > better way I don't yet know.
> 
> Probably the easiest would be to add to the lock struct a pointer to
> the task_struct and the EIP when it gets the lock, and clear them when
> it releases the lock.  That way, when you see processes blocking on the
> lock you can use crash or other tool to examine the lock and see which
> process got the lock and also where.

Okee doke. I saw that kgdb uses that method. I'll give it a go.

Thanks!

Nigel
-- 
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901

Many today claim to be tolerant. True tolerance, however, can cope with others
being intolerant.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/