Without this the loop won''t start
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 3ab80e9..2c873c9 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -2795,7 +2795,7 @@ int btrfs_rmap_block(struct btrfs_mapping_tree *map_tree,
}
}
- for (i = 0; i > nr; i++) {
+ for (i = 0; i < nr; i++) {
struct btrfs_multi_bio *multi;
struct btrfs_bio_stripe *stripe;
int ret;
--
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
On Mon, Jul 13, 2009 at 12:30:48AM +0200, Roel Kluin wrote:> Without this the loop won''t start > > Signed-off-by: Roel Kluin <roel.kluin@gmail.com> > --- > diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c > index 3ab80e9..2c873c9 100644 > --- a/fs/btrfs/volumes.c > +++ b/fs/btrfs/volumes.c > @@ -2795,7 +2795,7 @@ int btrfs_rmap_block(struct btrfs_mapping_tree *map_tree, > } > } > > - for (i = 0; i > nr; i++) { > + for (i = 0; i < nr; i++) { > struct btrfs_multi_bio *multi; > struct btrfs_bio_stripe *stripe; > int ret;Thanks, this does look buggy. That second loop should just be to verify the first loop didn''t mess things up. Yan Zheng, is there any reason we shouldn''t delete it? -chris -- 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
[ sorry, fixed up cc ] On Mon, Jul 13, 2009 at 09:22:52AM -0400, Chris Mason wrote:> On Mon, Jul 13, 2009 at 12:30:48AM +0200, Roel Kluin wrote: > > Without this the loop won''t start > > > > Signed-off-by: Roel Kluin <roel.kluin@gmail.com> > > --- > > diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c > > index 3ab80e9..2c873c9 100644 > > --- a/fs/btrfs/volumes.c > > +++ b/fs/btrfs/volumes.c > > @@ -2795,7 +2795,7 @@ int btrfs_rmap_block(struct btrfs_mapping_tree *map_tree, > > } > > } > > > > - for (i = 0; i > nr; i++) { > > + for (i = 0; i < nr; i++) { > > struct btrfs_multi_bio *multi; > > struct btrfs_bio_stripe *stripe; > > int ret; > > Thanks, this does look buggy. That second loop should just be to verify > the first loop didn''t mess things up. Yan Zheng, is there any reason we > shouldn''t delete it? > > -chris >-- 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
On Mon, 2009-07-13 at 09:22 -0400, Chris Mason wrote:> On Mon, Jul 13, 2009 at 12:30:48AM +0200, Roel Kluin wrote: > > Without this the loop won''t start > > > > Signed-off-by: Roel Kluin <roel.kluin@gmail.com> > > --- > > diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c > > index 3ab80e9..2c873c9 100644 > > --- a/fs/btrfs/volumes.c > > +++ b/fs/btrfs/volumes.c > > @@ -2795,7 +2795,7 @@ int btrfs_rmap_block(struct btrfs_mapping_tree *map_tree, > > } > > } > > > > - for (i = 0; i > nr; i++) { > > + for (i = 0; i < nr; i++) { > > struct btrfs_multi_bio *multi; > > struct btrfs_bio_stripe *stripe; > > int ret; > > Thanks, this does look buggy. That second loop should just be to verify > the first loop didn''t mess things up. Yan Zheng, is there any reason we > shouldn''t delete it?I deleted it in my tree because it made my head hurt for RAID5: http://git.infradead.org/users/dwmw2/btrfs-raid56.git?a=commitdiff;h=93562d49 -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation -- 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
2009/7/13 Chris Mason <chris.mason@oracle.com>:> On Mon, Jul 13, 2009 at 12:30:48AM +0200, Roel Kluin wrote: >> Without this the loop won''t start >> >> Signed-off-by: Roel Kluin <roel.kluin@gmail.com> >> --- >> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c >> index 3ab80e9..2c873c9 100644 >> --- a/fs/btrfs/volumes.c >> +++ b/fs/btrfs/volumes.c >> @@ -2795,7 +2795,7 @@ int btrfs_rmap_block(struct btrfs_mapping_tree *map_tree, >> } >> } >> >> - for (i = 0; i > nr; i++) { >> + for (i = 0; i < nr; i++) { >> struct btrfs_multi_bio *multi; >> struct btrfs_bio_stripe *stripe; >> int ret; > > Thanks, this does look buggy. That second loop should just be to verify > the first loop didn''t mess things up. Yan Zheng, is there any reason we > shouldn''t delete it? >It''s OK to delete it. Yan Zheng -- 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
On 07/13/2009 09:26 PM, Chris Mason wrote:> [ sorry, fixed up cc ] > > On Mon, Jul 13, 2009 at 09:22:52AM -0400, Chris Mason wrote: >> On Mon, Jul 13, 2009 at 12:30:48AM +0200, Roel Kluin wrote: >>> Without this the loop won''t start >>> >>> Signed-off-by: Roel Kluin <roel.kluin@gmail.com> >>> --- >>> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c >>> index 3ab80e9..2c873c9 100644 >>> --- a/fs/btrfs/volumes.c >>> +++ b/fs/btrfs/volumes.c >>> @@ -2795,7 +2795,7 @@ int btrfs_rmap_block(struct btrfs_mapping_tree *map_tree, >>> } >>> } >>> >>> - for (i = 0; i > nr; i++) { >>> + for (i = 0; i < nr; i++) { >>> struct btrfs_multi_bio *multi; >>> struct btrfs_bio_stripe *stripe; >>> int ret; >> Thanks, this does look buggy. That second loop should just be to verify >> the first loop didn''t mess things up. Yan Zheng, is there any reason we >> shouldn''t delete it? >>It''s OK to delete it. Yan Zheng -- 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