From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 22:31:20 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7422F16A4CE for ; Sat, 1 Nov 2003 22:31:20 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9DC643F85 for ; Sat, 1 Nov 2003 22:31:18 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id RAA17732; Sun, 2 Nov 2003 17:31:03 +1100 Date: Sun, 2 Nov 2003 17:31:03 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: peter.edwards@openet-telecom.com In-Reply-To: <3F6FE91100001039@mail.openet-telecom.com> Message-ID: <20031102164510.Y7482@gamplex.bde.org> References: <3F6FE91100001039@mail.openet-telecom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: RE: lockmgr panic on shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2003 06:31:20 -0000 On Sun, 2 Nov 2003 peter.edwards@openet-telecom.com wrote: > The obvious solution might be to change line 1161 of ffs_vfsops to > pass vget() "curthread" rather than td. I assume there's a good > reason why "thread0" is passed from boot(), but I can't see why > that's of any use to the vnode locking. Passing &thread0 in boot() is a quick (and not even wrong) fix for the problem that there is no valid current process^Wthread in the panic case. Long ago in Net/2 (still in Lite2 for at least the i386 version), sync() in boot() was passed the completely bogus parameters ((struct sigcontext *)0) (instead of (p, uap, retval). This worked to the extent that sync()'s proc pointer was not passed further or not dereferenced. Now there are lots of locks, and since thread0 is never the corerect lock holder, things work at most to the extent that sync()'s proc pointer is not passed further. curthread is never null in -current, so upgrading to the version that passes it (i386/i386/machdep.c 1.111 (actually passes curproc)) would probably help in the non-panic case without increasing bugs for the panic case. However, passing curthread is still wrong for the panic case due to the following complications: - panics may occur during context switches or in other critical regions when curthread is not quite current. - under SMP, curthread is per-CPU, so having it non-null doesn't really help. Locks may be held by curproc's running on other CPUs, and in panic() it is difficult to handle the other CPUs correctly -- if you stop them then they won't be able to release their locks, and if you let them run they may run into you. Hopefully in the case of a normal shutdown all the other CPUs release their locks and stop before the sync(). Bruce