cvs commit: src/sys/vfs/ufs ffs_alloc.c ufs_extern.h ufs_ihash.c

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxxxxx>]

dillon      2005/01/20 10:08:54 PST

DragonFly src repository

  Modified files:
    sys/vfs/ufs          ffs_alloc.c ufs_extern.h ufs_ihash.c 
  Log:
  The vnode reclamation code contains a race whereby a blocking condition may
  occur between the clearing of an inode's bitmap bit, the removal of the
  inode from the hash table, and the reclamation of the related vnode.
  
  This can cause a file create to block on the vnode undergoing reclamation
  if it happens to select the same inode (a case which is more likely these
  days due to dirpref).  To avoid the race, adjust UFS to *NOT* allocate
  inode numbers which are still present in the inode hash table.
  
  This race is NOT a bug, or at least it is not a known cause for existing bugs,
  but both the standard vnode code and especially the softupdates code is
  so complex that I am not taking any chances.  As of this commit both FreeBSD-4,
  FreeBSD-5, and DragonFly are known to have rare 'dup alloc' and other
  related filesystem/inode panics and this commit removes one variable from
  that equation.
  
  Revision  Changes    Path
  1.12      +83 -28    src/sys/vfs/ufs/ffs_alloc.c
  1.11      +1 -0      src/sys/vfs/ufs/ufs_extern.h
  1.15      +27 -0     src/sys/vfs/ufs/ufs_ihash.c


http://www.dragonflybsd.org/cvsweb/src/sys/vfs/ufs/ffs_alloc.c.diff?r1=1.11&r2=1.12&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/ufs/ufs_extern.h.diff?r1=1.10&r2=1.11&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/ufs/ufs_ihash.c.diff?r1=1.14&r2=1.15&f=u