From owner-freebsd-bugs Wed Jul 19 13:25:40 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id NAA09164 for bugs-outgoing; Wed, 19 Jul 1995 13:25:40 -0700 Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id NAA09142 ; Wed, 19 Jul 1995 13:25:31 -0700 Received: from venus.cs.utah.edu by cs.utah.edu (8.6.12/utah-2.21-cs) id OAA01851; Wed, 19 Jul 1995 14:24:37 -0600 Received: by venus.cs.utah.edu (8.6.10/utah-2.15sun-leaf) id OAA26702; Wed, 19 Jul 1995 14:24:13 -0600 Date: Wed, 19 Jul 1995 14:24:13 -0600 From: mike@cs.utah.edu (Mike Hibler) Message-Id: <199507192024.OAA26702@venus.cs.utah.edu> To: bde@zeta.org.au, dillon@blob.best.net Subject: Re: possible ffs_vget() race condition Cc: arch@FreeBSD.org, bugs@FreeBSD.org, davidg@Root.COM Sender: bugs-owner@FreeBSD.org Precedence: bulk > Urk... The OS just hit the hole, so I guess it's a real problem! > And, unfortunately, panic'd trying to access the inode through > vp->v_data which I had NULL'd out in my patch... so, obviously, I > am not freeing it properly. > > If someone could email me the proper way to free it at this point (where > we've allocated the vnode but then determine we have to throw it out > due to a duplicate before we setup the inode for it), I'd appreciate it. > > -Matt > You may have hit another race caused by the blocking malloc. Here is how it bit us (in our 4.3/4.4-ish BSD on hp700): getnewvnode() puts the new vnode on the mount list (insmntque), malloc blocks so v_data doesn't get set, some process runs that does a sync(), ffs_sync traverses the mountlist and dereferences the 0 v_data field. Our particular scenerio was using a large MFS. MFS is uniquely suited to exposing this race since it not only uses the racy code, it uses lots of memory too! P.S. We "fixed" it by having the caller of getnewvnode put the vnode on the mount list when it is completely initialized. This won't fix your original problem though.