From owner-freebsd-hackers Tue Oct 2 23:26:13 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 BA44637B403; Tue, 2 Oct 2001 23:26:03 -0700 (PDT) Received: (from dillon@localhost) by earth.backplane.com (8.11.6/8.11.2) id f936Pq363645; Tue, 2 Oct 2001 23:25:52 -0700 (PDT) (envelope-from dillon) Date: Tue, 2 Oct 2001 23:25:52 -0700 (PDT) From: Matt Dillon Message-Id: <200110030625.f936Pq363645@earth.backplane.com> To: Kirk McKusick Cc: Ian Dowse , Yevgeniy Aleynikov , peter@FreeBSD.ORG, ache@FreeBSD.ORG, Ken Pizzini , hackers@FreeBSD.ORG Subject: Re: bleh. Re: ufs_rename panic References: <200110030610.f936AbR11859@beastie.mckusick.com> 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 problems all arise from the fact that we unlock the source :while we look up the destination, and when we return to relookup :the source, it may have changed/moved/disappeared. The reason to :unlock the source before looking up the destination was to avoid :deadlocking against ourselves on a lock that we held associated :with the source. Since we now allow recursive locks on vnodes, it :is no longer necessary to release the source before looking up :the destination. So, it seems to me that the correct fix is to :*not* release the source after looking it up, but rather hold it :locked while we look up the destination. We can completely get :rid of relookup and lots of other hairy code and generally make :rename much simpler. Am I missing something here? : : ~Kirk That was the first thing I thought of, but unfortunately it is still possible to deadlock against another process... for example, a process doing an (unrelated) rename in the reverse direction. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message