From owner-freebsd-hackers Thu Nov 7 18:53:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA01115 for hackers-outgoing; Thu, 7 Nov 1996 18:53:39 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA01109; Thu, 7 Nov 1996 18:53:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id SAA04382; Thu, 7 Nov 1996 18:49:56 -0800 (PST) Message-Id: <199611080249.SAA04382@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: ponds!rivers@dg-rtp.dg.com, dyson@freefall.freebsd.org, freebsd-hackers@freefall.freebsd.org Subject: Re: More info on the daily panics... In-reply-to: Your message of "Thu, 07 Nov 1996 11:13:59 MST." <199611071813.LAA10315@phaeton.artisoft.com> From: David Greenman Reply-To: dg@root.com Date: Thu, 07 Nov 1996 18:49:56 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >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