From owner-freebsd-bugs Thu Jul 20 17:34:56 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id RAA00522 for bugs-outgoing; Thu, 20 Jul 1995 17:34:56 -0700 Received: from blob.best.net (blob.best.net [204.156.128.88]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id RAA00516 for ; Thu, 20 Jul 1995 17:34:55 -0700 Received: (root@localhost) by blob.best.net (8.6.12/8.6.5) id RAA05301; Thu, 20 Jul 1995 17:34:17 -0700 Date: Thu, 20 Jul 1995 17:34:17 -0700 From: Matt Dillon Message-Id: <199507210034.RAA05301@blob.best.net> To: root@corbin.Root.COM Cc: bugs@freebsd.org Subject: Re: possible ffs_vget() race condition Sender: bugs-owner@freebsd.org Precedence: bulk I think a better solution would be to have the vnode allocation routine install dummy functions/data such that it can be freed at any time. This would incidently solve the second problem as well (where sync comes along and gets confused by the partially allocated vnode that someone mentioned a few messages back). -Matt >> Doesn't vrele() call VOP_INACTIVE and therefore >> ufs_inactive, which will try to dereference >> vp->v_data which is NULL? > > Hmmm. You're right. Any thoughts, Kirk? What happens if the v_op pointer is >set to NULL before doing the vrele()? ...Does the VOP_INACTIVE become a nop, or >does the machine panic when dereferencing the pointer? :-) > The only other solution I can think of would be to create a special routine >for releasing vnodes with no FS specific data yet attached...but that seems >like another kludge. > >-DG >