This patch implements the FIEMAP ioctl for GFS2. We can use the generic
code (aside from a lock order issue, solved as per Ted Tso's suggestion)
for which I've introduced a new variant of the generic function. We also
have one exception to deal with, namely stuffed files, so we do that
"by hand", setting all the required flags.
This has been tested with a modified (I could only find an old version) of
Eric's test program, and appears to work correctly.
This patch does not currently support FIEMAP of xattrs, but the plan is to add
that feature at some future point.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Cc: Theodore Tso <tytso@mit.edu>
Cc: Eric Sandeen <sandeen@redhat.com>
-/*
+/**
+ * __generic_block_fiemap - FIEMAP for block based inodes (no locking)
* @inode - the inode to map
* @arg - the pointer to userspace where we copy everything to
* @get_block - the fs's get_block function
@@ -242,11 +243,15 @@ static int ioctl_fiemap(struct file *filp, unsigned long arg)
*
* If it is possible to have data blocks beyond a hole past @inode->i_size, then
* please do not use this function, it will stop at the first unmapped block
- * beyond i_size
+ * beyond i_size.
+ *
+ * If you use this function directly, you need to do your own locking. Use
+ * generic_block_fiemap if you want the locking done for you.
*/
-int generic_block_fiemap(struct inode *inode,
- struct fiemap_extent_info *fieinfo, u64 start,
- u64 len, get_block_t *get_block)
+
+int __generic_block_fiemap(struct inode *inode,
+ struct fiemap_extent_info *fieinfo, u64 start,
+ u64 len, get_block_t *get_block)
{
struct buffer_head tmp;
unsigned int start_blk;
@@ -260,9 +265,6 @@ int generic_block_fiemap(struct inode *inode,
@@ -334,14 +336,36 @@ int generic_block_fiemap(struct inode *inode,
cond_resched();
} while (1);
- mutex_unlock(&inode->i_mutex);
-
/* if ret is 1 then we just hit the end of the extent array */
if (ret == 1)
ret = 0;
return ret;
}
+EXPORT_SYMBOL(__generic_block_fiemap);
+
+/**
+ * generic_block_fiemap - FIEMAP for block based inodes
+ * @inode: The inode to map
+ * @fieinfo: The mapping information
+ * @start: The initial block to map
+ * @len: The length of the extect to attempt to map
+ * @get_block: The block mapping function for the fs
+ *
+ * Calls __generic_block_fiemap to map the inode, after taking
+ * the inode's mutex lock.
+ */
+
+int generic_block_fiemap(struct inode *inode,
+ struct fiemap_extent_info *fieinfo, u64 start,
+ u64 len, get_block_t *get_block)
+{
+ int ret;
+ mutex_lock(&inode->i_mutex);
+ ret = __generic_block_fiemap(inode, fieinfo, start, len, get_block);
+ mutex_unlock(&inode->i_mutex);
+ return ret;
+}
EXPORT_SYMBOL(generic_block_fiemap);
On Thu, 18 Dec 2008 10:29:04 +0000
Steven Whitehouse <swhiteho@redhat.com> wrote:
> Hi,
>
> On Wed, 2008-12-17 at 17:22 -0800, Andrew Morton wrote:
> > On Wed, 17 Dec 2008 11:30:00 +0000
> > swhiteho@redhat.com wrote:
> >
> > > +static int gfs2_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
> > > + u64 start, u64 len)
> > > +{
> > > + struct gfs2_inode *ip = GFS2_I(inode);
> > > + struct gfs2_holder gh;
> > > + int ret;
> > > +
> > > + ret = fiemap_check_flags(fieinfo, FIEMAP_FLAG_SYNC);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + mutex_lock(&inode->i_mutex);
> > > +
> > > + ret = gfs2_glock_nq_init(ip->i_gl, LM_ST_SHARED, 0, &gh);
> > > + if (ret)
> > > + goto out;
> > > +
> > > + if (gfs2_is_stuffed(ip)) {
> > > + u64 phys = ip->i_no_addr << inode->i_blkbits;
> > > + u64 size = i_size_read(inode);
> >
> > It's actually safe to directly access i_size inside i_mutex. Although
> > not terribly maintainable.
> >
> >
> I did wonder about that at the time, but I'm not quite sure if you are
> suggesting that I should change this now, or leave it as it is?
No strong opinion, really. If it's a performance-sensitive path (it
isn't) then bypassing i_size_read() might be advantageous. Leaving the
i_size_read() there provides some future-safety and sets a good
example.
It would be an easier decision if the SMP, 32-bit version of
i_size_read() wasn't inlined, and tremendously huge