Date: Thu, 07 Nov 1996 18:49:56 -0800 From: David Greenman <dg@root.com> To: Terry Lambert <terry@lambert.org> Cc: ponds!rivers@dg-rtp.dg.com, dyson@freefall.freebsd.org, freebsd-hackers@freefall.freebsd.org Subject: Re: More info on the daily panics... Message-ID: <199611080249.SAA04382@root.com> In-Reply-To: Your message of "Thu, 07 Nov 1996 11:13:59 MST." <199611071813.LAA10315@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>This patch *is* a kludge: it's a kludge against the fact that there is >a two stage decommit (which is itself a kludge, with no way to recover >perfectly valid data hung off an in core vnode buffer list pointer once >the FS data has been dissociated from that vnode). The problem is the >race conditions in the two stage decommit during a period of incresing >demand and high vnode reuse. As always, trying to parse what you're saying is difficult. I interpret what you're saying above as there being a race condition when allocating inode+vnode pairs (since either one can block and thus someone else might get in there and try to do the same thing for the same inode). I fixed that race condition over a year ago by adding a mutex lock and by a series of allocation order changes. I might have missed a rarely used filesystem (msdosfs?), but the race condition for FFS has been fixed since July '95. ufs/ffs/ffs_vfsops.c: ---------------------------- revision 1.25 date: 1995/07/21 16:20:20; author: davidg; state: Exp; lines: +8 -14 Since ufs_ihashget can block, the lock must be checked for each time the function returns. Also, moved lock into .bss and made minor cosmetic changes. Submitted by: Bruce Evans ---------------------------- revision 1.24 date: 1995/07/21 03:52:40; author: davidg; state: Exp; lines: +34 -4 Implement a lock in ffs_vget to prevent a race condition where two processes try allocate the same inode/vnode, causing a duplicate. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611080249.SAA04382>