From owner-freebsd-hackers Mon Feb 19 08:57:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA08002 for hackers-outgoing; Mon, 19 Feb 1996 08:57:52 -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 IAA07997 for ; Mon, 19 Feb 1996 08:57:47 -0800 (PST) Received: (from mday@localhost) by sting.artisoft.com (8.6.9/8.6.9) id JAA06004 for freebsd-hackers@freebsd.org; Mon, 19 Feb 1996 09:57:14 -0700 Date: Mon, 19 Feb 1996 09:57:14 -0700 From: Matt Day Message-Id: <199602191657.JAA06004@sting.artisoft.com> To: freebsd-hackers@freebsd.org Subject: Bad bug in ffs_sync() & friends [RESEND] Sender: owner-hackers@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