Date: Wed, 19 Jul 1995 14:24:13 -0600 From: mike@cs.utah.edu (Mike Hibler) To: bde@zeta.org.au, dillon@blob.best.net Cc: arch@FreeBSD.org, bugs@FreeBSD.org, davidg@Root.COM Subject: Re: possible ffs_vget() race condition Message-ID: <199507192024.OAA26702@venus.cs.utah.edu>
next in thread | raw e-mail | index | archive | help
> Urk... The OS just hit the hole, so I guess it's a real problem! <grin> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507192024.OAA26702>