Subject: kern/14090: "panic: lockmgr: locking against myself" with nullfs
To: None <email@example.com>
From: None <firstname.lastname@example.org>
Date: 09/28/2001 17:16:55
>Synopsis: "panic: lockmgr: locking against myself" with nullfs
>Arrival-Date: Fri Sep 28 08:21:00 PDT 2001
>Originator: Alan Barrett
>Release: NetBSD-current 'Sun Sep 23 21:12:12 EDT 2001'
Built from sources checked out from CVS with -D'Sun Sep 23 21:12:12 EDT 2001'
This is a new problem in NetBSD-1.5Y. It was not present in a kernel
built on 5 Sep 2001 from sources that were probably a few days older
In an environment that makes heavy use of nullfs and raid0 filesystems,
one of the "find" commands run from the daily cron jobs causes a panic.
I don't yet know for sure which find command was responsible, but I
suspect the find|xargs|sort pipeline in the check_devices section of
Here's the panic message and a hand-transcribed backtrace (with function
panic: lockmgr: locking against myself
stopped in pid 28479 (find) at cpu_Debugger+0x4: leave
The only printable string that I was easily able to discover was the
second arg passed to lookup(), and that string was "ircsearch". I
believe that two paths match that name: /r1a/USR-PKG/bin/ircsearch is a
directory on an ordinary FFS filesystem on a raid0 partition, and
/usr/pkg/bin/ircsearch is a nullfs image of the same underlying file.
The /etc/fstab entries for the /r1a and /usr/pkg filesystems are as
/dev/raid1a /r1a ffs rw,softdep 1 3
/r1a/USR-PKG /usr/pkg null rw 0 0
1) Fix the locking bug.
2) It might be a good idea to add "-o -fstype null" to the set of
exclusions in the find command. There's no point in walking
both the nullfs tree and the underlying tree.