Subject: Re: processes block in vnlock
To: Johan Danielsson <firstname.lastname@example.org>
From: Jason Thorpe <email@example.com>
Date: 07/20/1999 10:18:06
On 20 Jul 1999 12:48:34 +0200
firstname.lastname@example.org (Johan Danielsson) wrote:
> Sometimes processes blocks in vnlock. I've seen this when compiling in
> emacs (when it's about to start the process), and when running su.
> The blocked process looks like this:
> 0 5422 5421 0 -2 -2 64 392 vnlock D<s+ p4 0:00.02 /usr/bin/su
> Typing a few characters in some other terminal usually unblocks the
> I assume this is because of some subtle bug in the recent vnode
> locking changes.
> This is what I have mounted:
> /dev/wd0a on / type ffs (local)
> /dev/wd0e on /usr type ffs (local)
> /dev/wd0f on /usr/misc type ffs (local)
> /dev/wd0g on /usr/misc/src/netbsd type ffs (local)
> mfs:307 on /tmp type mfs (asynchronous, local)
> procfs on /proc type procfs (local)
> kernfs on /kern type kernfs (local)
> fdesc on /dev type fdesc (local, union)
Yes, it was a bug in the fdesc file system. I committed a fix from Bill
$NetBSD: fdesc_vnops.c,v 1.49 1999/07/19 23:00:47 thorpej Exp $
It was a bug in handling the "/dev/tty" node. The bug actually existed
forever, but wasn't noticed until now because fdescfs didn't actually
lock its vnodes at all (it used a noop vnode lock vector).
> Hard to tell. It doesn't always happen, but I think it might happen
> when I have forground processes running in some other terminal (but
> this is just speculation).
It's actually very easy to reproduce. Using two xterm windows:
a% cd /usr/src/bin/cat
b% cd /usr/src/bin/ls
a% more cat.c
b% more ls.c
Watch in amazement as the more(1) in window b doesn't scroll until you
press a key in window a.
-- Jason R. Thorpe <email@example.com>