From owner-freebsd-bugs  Mon Feb  5 02:02:09 1996
Return-Path: owner-bugs
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id CAA16027
          for bugs-outgoing; Mon, 5 Feb 1996 02:02:09 -0800 (PST)
Received: from sting.artisoft.com (sting.Artisoft.COM [198.17.250.50])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA16003
          Mon, 5 Feb 1996 02:01:50 -0800 (PST)
Received: (from mday@localhost) by sting.artisoft.com (8.6.9/8.6.9) id DAA26813; Mon, 5 Feb 1996 03:01:28 -0700
Date: Mon, 5 Feb 1996 03:01:28 -0700
From: Matt Day <mday@artisoft.com>
Message-Id: <199602051001.DAA26813@sting.artisoft.com>
To: freebsd-bugs@freebsd.org, freebsd-hackers@freebsd.org
Subject: Bad bug in ffs_sync() & friends
Sender: owner-bugs@freebsd.org
Precedence: bulk

Hi,

I think there is a very rare, yet fatal, bug in ffs_sync() in the
-CURRENT code (and the -STABLE code, and NetBSD 1.1, etc...).
This bug has occured twice on my system in the past 6 months.

Consider this scenario:
ffs_vget() calls getnewvnode(), and then calls MALLOC() to allocate
memory for the incore inode.  That MALLOC() blocks.
While that MALLOC() is blocked, ffs_sync() gets called.  ffs_sync()
finds the vnode just set up by that getnewvnode() on the mnt_vnodelist
(because getnewvnode() put it there) and proceeds to dereference
vp->v_data by calling VOP_ISLOCKED(), but v_data is still zero because
that MALLOC() blocked.

It looks like this bug is lurking in many other routines as well --
pretty much any routine that runs down the mnt_vnodelist.

What do you think?  Please e-mail me directly, as I do not subscribe to
these mailing lists.

Thanks,

Matt Day <mday@artisoft.com>