From owner-freebsd-bugs  Mon Sep 29 01:43:19 1997
Return-Path: <owner-freebsd-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id BAA28031
          for bugs-outgoing; Mon, 29 Sep 1997 01:43:19 -0700 (PDT)
Received: from schizo.dk.tfs.com (mail.trw.dk [195.8.133.123])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA28025;
          Mon, 29 Sep 1997 01:43:11 -0700 (PDT)
Received: from critter.freebsd.dk (critter.dk.tfs.com [140.145.230.252]) by schizo.dk.tfs.com (8.8.7/8.7.3) with ESMTP id KAA22334; Mon, 29 Sep 1997 10:42:40 +0200 (MET DST)
Received: from critter.freebsd.dk (localhost.dk.tfs.com [127.0.0.1])
	by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id KAA00729;
	Mon, 29 Sep 1997 10:41:44 +0200 (CEST)
To: Peter Wemm <peter@netplex.com.au>
cc: Tor Egge <Tor.Egge@idi.ntnu.no>, 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 16:05:18 +0800."
             <199709290805.QAA10988@spinner.netplex.com.au> 
Date: Mon, 29 Sep 1997 10:41:43 +0200
Message-ID: <727.875522503@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In message <199709290805.QAA10988@spinner.netplex.com.au>, Peter Wemm writes:
>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.

yes.

>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. :-)

I looked at putting DDB output in the buffer and have DDB do a "trace"
when it is entered, but it didn't prove much help.  I can try to dig
up the code...

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."