[Top] [All Lists]

Re: xfs vs. lockdep

To: Timothy Shimmin <tes@xxxxxxx>
Subject: Re: xfs vs. lockdep
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Mon, 09 Oct 2006 21:21:10 -0500
Cc: David Chinner <dgc@xxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <C013892BDA68824F76A0474A@xxxxxxxxxxxxxxxxxxxxxxx>
References: <452A8DE2.4000608@xxxxxxxxxxx> <20061010004726.GO11034@xxxxxxxxxxxxxxxxx> <C013892BDA68824F76A0474A@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird (Macintosh/20060909)
Timothy Shimmin wrote:
Hence by the time we have the lock here in xfs_ireclaim we have guaranteed
that there are no other outstanding references and no new references
can occur. Therefore it should be safe to drop the lock before destroying

Yeah, there really seems like something would be wrong if you can't
unlock it before destroying it.

I thought so too; if anybody else might catch it post-unlock pre-free, they're in for a big surprise anyway :)

I would have thought you'd need to guarantee that you are the only
one with access to it before destroying it otherwise there'd be problems :)
(Which as you say we do)


This one rings a bell. I seem to recall multiple places where we destroy
without releasing the lock first.
And I vaguely remember Nathan mentioning that this was causing grief
for lockdep:)

Ok, cool.  Want a formal patch or you guys want to just free it up...

         * Free all memory associated with the inode.
+       xfs_iunlock(ip, XFS_ILOCK_EXCL | XFS_IOLOCK_EXCL);



<Prev in Thread] Current Thread [Next in Thread>