From owner-cvs-sys  Tue Dec 16 17:06:08 1997
Return-Path: <owner-cvs-sys>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA18412
          for cvs-sys-outgoing; Tue, 16 Dec 1997 17:06:08 -0800 (PST)
          (envelope-from owner-cvs-sys)
Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA18353;
          Tue, 16 Dec 1997 17:05:26 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word (localhost [127.0.0.1])
	by word.smith.net.au (8.8.8/8.8.5) with ESMTP id LAA00763;
	Wed, 17 Dec 1997 11:29:37 +1030 (CST)
Message-Id: <199712170059.LAA00763@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: dg@root.com
cc: cvs-committers@freebsd.org, cvs-all@freebsd.org, cvs-sys@freebsd.org
Subject: Re: cvs commit: src/sys/kern kern_exec.c 
In-reply-to: Your message of "Tue, 16 Dec 1997 08:22:17 -0800."
             <199712161622.IAA08136@implode.root.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 17 Dec 1997 11:29:36 +1030
From: Mike Smith <mike@smith.net.au>
Sender: owner-cvs-sys@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> >  Fix bug where a struct buf was free()'d back to the system malloc pool.
> >  Quite amazing that the system runs at all with this bug. Also present in
> >  2.2.5. The bug appears to have come in with changes in rev 1.53.
> >  
> >  PR:           might fix PR#5313
> >  Submitted by: bde
> > 
> >  Revision  Changes    Path
> >  1.70      +3 -4      src/sys/kern/kern_exec.c
> 
>    This log message is somewhat wrong. It's not the struct buf that was
> being free()'d, but rather the buffer mapping/target of the struct buf (the
> filesystem data). A serious bug nonetheless, and I can hardly imagine what
> this might do to the system.

Just reading things through; did you actually have any symptomatic 
evidence that indicated that this was occurring on a regular basis?  

I'd have expected to see a lot of people complaining about the "panic: 
multiple frees" in free() if it was, as the free rate would be 
outstripping the allocation rate for M_TEMP.

It looks as though you need some moderately obscure failure cases for 
this to pop up; bread() not allocating bp, or the interpreter search 
failing; ie. a case where brelse() is called on bp but imgp->img_header 
is not set to NULL before arriving at exec_fail_dealloc.

mike