Date: Tue, 2 Oct 2001 23:25:52 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Kirk McKusick <mckusick@mckusick.com> Cc: Ian Dowse <iedowse@maths.tcd.ie>, Yevgeniy Aleynikov <eugenea@infospace.com>, peter@FreeBSD.ORG, ache@FreeBSD.ORG, Ken Pizzini <kenp@infospace.com>, hackers@FreeBSD.ORG Subject: Re: bleh. Re: ufs_rename panic Message-ID: <200110030625.f936Pq363645@earth.backplane.com> References: <200110030610.f936AbR11859@beastie.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110030625.f936Pq363645>