From owner-freebsd-bugs Mon Sep 29 01:07:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA26288 for bugs-outgoing; Mon, 29 Sep 1997 01:07:28 -0700 (PDT) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA26282; Mon, 29 Sep 1997 01:07:15 -0700 (PDT) Received: from spinner.netplex.com.au (localhost.dialix.com.au [127.0.0.1]) by spinner.netplex.com.au with ESMTP id QAA10988; Mon, 29 Sep 1997 16:05:19 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199709290805.QAA10988@spinner.netplex.com.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Poul-Henning Kamp cc: Tor Egge , freebsd-bugs@FreeBSD.ORG, dyson@FreeBSD.ORG Subject: Re: kern/4630: buffer_map might become corrupted In-reply-to: Your message of "Mon, 29 Sep 1997 08:46:45 +0200." <242.875515605@critter.freebsd.dk> Date: Mon, 29 Sep 1997 16:05:18 +0800 From: Peter Wemm Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp wrote: > > > This means that both vm_map_entry_dispose and vm_map_entry_create might > > be called in an interrupt context, manipulating buffer_map and the free > > pool of vm map entries. > > I think the problem here is calling brelse() at interrupt time, isn't it ? IMHO We _really_ need some low-cost assertions of assumptions that are on by default but can be disabled via compile option perhaps.. Kinda like an inverse of DIAGNOSTIC. Simple catching of things like 'must be called at splbio or greater', 'must not be called from interrupt' etc at strategic points (eg: tsleep and the various VM and bio utility functions etc) would help shake out these sorts of problems once and for all. After all, we still don't know the cause of the runqueue trashing under 2.2 unless swapping is disabled.. Perhaps a series of machine-independent macros that are implemented per-arch as needed might help. eg: assert_nointerrupt("tsleep"); assert_splbio("vm_function_foo()"); etc. BTW2; I wish there was an easy way of producing a stack trace automatically on a panic or fatal trap, or as a diagnostic tool. Having a machine panic and reboot is near for unattended machines. Having a stack trace in the console log would be fantastic. :-) > Poul-Henning > Cheers, -Peter -- Peter Wemm Netplex Consulting