diff mbox

Btrfs: fix off-by-one in fiemap

Message ID 1367425421-10598-1-git-send-email-bo.li.liu@oracle.com (mailing list archive)
State New, archived
Headers show

Commit Message

Liu Bo May 1, 2013, 4:23 p.m. UTC 
lock_extent/unlock_extent expect an exclusive end.

Tested-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
---
 fs/btrfs/extent_io.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

Comments

Josef Bacik May 6, 2013, 7:45 p.m. UTC | #1 
On Wed, May 01, 2013 at 10:23:41AM -0600, Liu Bo wrote:
> lock_extent/unlock_extent expect an exclusive end.
> 

Can you make an xfstest for this so we can make sure we don't screw this up in
the future?  Thanks,

Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Liu Bo May 7, 2013, 10:52 a.m. UTC | #2 
On Mon, May 06, 2013 at 03:45:16PM -0400, Josef Bacik wrote:
> On Wed, May 01, 2013 at 10:23:41AM -0600, Liu Bo wrote:
> > lock_extent/unlock_extent expect an exclusive end.
> > 
> 
> Can you make an xfstest for this so we can make sure we don't screw this up in
> the future?  Thanks,

Hi Josef,

I wish I could, but I don't know how to test this in a xfstest case...
David has made a debug checker in kernel to cover this.

thanks,
liubo
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Sterba May 7, 2013, 12:25 p.m. UTC | #3 
On Tue, May 07, 2013 at 06:52:49PM +0800, Liu Bo wrote:
> On Mon, May 06, 2013 at 03:45:16PM -0400, Josef Bacik wrote:
> > Can you make an xfstest for this so we can make sure we don't screw this up in
> > the future?  Thanks,
> 
> I wish I could, but I don't know how to test this in a xfstest case...
> David has made a debug checker in kernel to cover this.

If CONFIG_BTRFS_DEBUG is on, a test similar to what I used back then
would cover the boundary conditions.

http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg21021.html

Looking at existing tests, 285 is a 'seek sanity test' that has several
subtests inside. This looks like the right place to put it in.

david
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index cdee391..e3aafce 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -3913,7 +3913,7 @@  int extent_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
 		last_for_get_extent = isize;
 	}
 
-	lock_extent_bits(&BTRFS_I(inode)->io_tree, start, start + len, 0,
+	lock_extent_bits(&BTRFS_I(inode)->io_tree, start, start + len - 1, 0,
 			 &cached_state);
 
 	em = get_extent_skip_holes(inode, start, last_for_get_extent,
@@ -4000,7 +4000,7 @@  int extent_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
 out_free:
 	free_extent_map(em);
 out:
-	unlock_extent_cached(&BTRFS_I(inode)->io_tree, start, start + len,
+	unlock_extent_cached(&BTRFS_I(inode)->io_tree, start, start + len - 1,
 			     &cached_state, GFP_NOFS);
 	return ret;
 }