[Top] [All Lists]

Re: Locking bmap mappings

To: Steve Lord <lord@xxxxxxx>
Subject: Re: Locking bmap mappings
From: "Andi Kleen" <ak@xxxxxxx>
Date: Mon, 28 Aug 2000 22:28:50 +0200
Cc: "Andi Kleen" <ak@xxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <200008281921.OAA24286@xxxxxxxxxxxxxxxxxxxx>; from lord@xxxxxxx on Mon, Aug 28, 2000 at 02:21:04PM -0500
References: <ak@xxxxxxx> <200008281921.OAA24286@xxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Mon, Aug 28, 2000 at 02:21:04PM -0500, Steve Lord wrote:
> > 
> > In ext2 and most other file systems it is enough to hold the inode 
> > semaphore 
> to pin
> > blocks returned by bmap (because truncate and unlink are the only functions 
> > t
> hat
> > could steal blocks from under you). This seems to be mostly true for XFS 
> > too 
> because it is 
> > enforced in the VFS above XFS, but it has some loopholes with the space 
> > manag
> ement
> > ioctls and the fsr (swapext). The following patch plugs them by grabbing 
> > the 
> > respective linux inode semaphores. Did I forget any case where bmap could 
> > be 
> invalidated?
> You are correct, except for the fact that xfs is doing its own locking under
> the covers internally. These should be protecting XFS from stamping on itself.

Sorry, I should have been more clear. The locking is required for external
users, e.g. the loop device (the current version doesn't do it, but it will
be fixed to do so). loop device cannot access any internal XFS locks. 


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