From owner-freebsd-hackers  Tue Mar  4 16:21:00 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id QAA26678
          for hackers-outgoing; Tue, 4 Mar 1997 16:21:00 -0800 (PST)
Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA26604
          for <freebsd-hackers@freefall.FreeBSD.org>; Tue, 4 Mar 1997 16:20:38 -0800 (PST)
Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02)
	id AA01969; Tue, 4 Mar 1997 19:20:03 -0500
Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Tue,  4 Mar 1997 19:20 EST
Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id TAA01628; Tue, 4 Mar 1997 19:12:40 -0500 (EST)
Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id TAA27728; Tue, 4 Mar 1997 19:18:20 -0500 (EST)
Date: Tue, 4 Mar 1997 19:18:20 -0500 (EST)
From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com>
Message-Id: <199703050018.TAA27728@lakes.water.net>
To: ponds!root.com!dg, ponds!freefall.cdrom.com!freebsd-hackers,
        ponds!lambert.org!terry
Subject: Re: "dup alloc" and Re: kern/2875: vinvalbuf() clobbers b_vnbufs chain
Content-Type: text
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 
> >> Because disk I/O interruption is unmasked at (1), b_vnbufs is operated 
> >> without splbio() after `break' at (2).
> >> 
> >
> >
> >  This looks very interesting to me... does anything think it could
> > be the cause of my "dup alloc" problems?  I'm going to give it
> > a try later this evening...
> 
>    It might, but it seems like the more likely failure would be a bad pointer
> dereference. In any case, I suggest trying the patch I provided as a followup.
> 
> -DG
> 
> David Greenman

 Praise Be!

 Initial tests with the original patch are promising; I've tried 
three times now and can't get a demonstration of the problem (that is,
I trash the inode and newfs successfully writes 0!!! Yeah!!!!)

 However; I'm going to build a pristine kernel and make sure that I can

	1) Again reliable reproduce the problem.

	2) Make this one change and watch the problem go away (hopefully!)

 I'll report back as soon as I have the results on that... It looks
*very* promising!

	- Dave Rivers -