From owner-freebsd-hackers Wed Oct 3 10:56: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 1E0C437B405; Wed, 3 Oct 2001 10:55:59 -0700 (PDT) Received: (from dillon@localhost) by earth.backplane.com (8.11.6/8.11.2) id f93HttH66964; Wed, 3 Oct 2001 10:55:55 -0700 (PDT) (envelope-from dillon) Date: Wed, 3 Oct 2001 10:55:55 -0700 (PDT) From: Matt Dillon Message-Id: <200110031755.f93HttH66964@earth.backplane.com> To: Ian Dowse Cc: Peter Wemm , Yevgeniy Aleynikov , ache@FreeBSD.ORG, mckusick@mckusick.com, Ken Pizzini , hackers@FreeBSD.ORG Subject: Re: patch #3 (was Re: bleh. Re: ufs_rename panic) References: <200110031223.aa26174@salmon.maths.tcd.ie> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :The addition of the SOFTLOCKLEAF code is quite a major change, so :it would be very useful if you could describe exactly what it does, :what its semantics are, and how it fits into the rename problem. Setting SOFTLOCKLEAF in namei will set the VSOFTLOCK flag in the returned vnode (whether the returned vnode is locked or not), and namei() will fail with EAGAIN if the VSOFTLOCK flag is already set. An extra reference is added to the returned vnode which either the caller must free or NDFREE must free (note that VOP_RENAME is not responsible for freeing this extra reference, so the API itself does not actually change). The caller must either call vclearsoftlock() or call NDFREE() with the appropriate flags to clear the flag and dereference the vnode. int gc = 0; vagain(&gc); vagain() is a routine that falls through the first time, initializing 'gc' to a global counter. If later on you get an EAGAIN from a SOFTLOCK failure and loop back up to the vagain(), it will block the process until whomever owns the softlock has 'probably' released it. This allows the system call to restart internally and attempt the operation again from scratch. :Because the source node and parent are not locked, there is the :possibility that the source node could be renamed or removed at :any time before VOP_RENAME finally gets around to locking it and :removing it. Something needs to protect the source node against :being renamed/removed between the point that the source node is :initially looked up and the point that it is finally locked. Both :Matt's SOFTLOCKLEAF and the VRENAME flag are there to provide this :protection. : :It is the fact that this problem is entirely unique to VOP_RENAME :that leads me to think that adding the generic SOFTLOCKLEAF code :is overkill. The following fragment also suggests that maybe the :approach doesn't actually fit in that well: Well, maybe. I have my eye on possibly seeing a way to fix the race-to-root directory scanning program too, so I decided to implement VSOFTLOCK formally rather then as a hack. :The way that vclearsoftlock() is used to clear a flag in an unlocked :vnode is also not ideal. This should probably be protected at least :by v_interlock as other flags are. : :Ian In -current, definitely. I'm not sure why v_interlock even exists in -stable. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message