public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] brtfs: less- and greater than confusion
@ 2009-07-12 22:30 Roel Kluin
  2009-07-13 13:22 ` Chris Mason
  0 siblings, 1 reply; 6+ messages in thread
From: Roel Kluin @ 2009-07-12 22:30 UTC (permalink / raw)
  To: chris.mason, linux-btrfs, Andrew Morton

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;

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] brtfs: less- and greater than confusion
  2009-07-12 22:30 [PATCH] brtfs: less- and greater than confusion Roel Kluin
@ 2009-07-13 13:22 ` Chris Mason
  2009-07-13 13:26   ` Chris Mason
                     ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Chris Mason @ 2009-07-13 13:22 UTC (permalink / raw)
  To: Roel Kluin; +Cc: linux-btrfs, Andrew Morton, yan.zheng

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] brtfs: less- and greater than confusion
  2009-07-13 13:22 ` Chris Mason
@ 2009-07-13 13:26   ` Chris Mason
  2009-07-13 13:57     ` Yan Zheng
  2009-07-13 13:28   ` David Woodhouse
  2009-07-13 13:43   ` Yan Zheng
  2 siblings, 1 reply; 6+ messages in thread
From: Chris Mason @ 2009-07-13 13:26 UTC (permalink / raw)
  To: Roel Kluin, linux-btrfs, Andrew Morton, Yan Zheng

[ 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
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] brtfs: less- and greater than confusion
  2009-07-13 13:22 ` Chris Mason
  2009-07-13 13:26   ` Chris Mason
@ 2009-07-13 13:28   ` David Woodhouse
  2009-07-13 13:43   ` Yan Zheng
  2 siblings, 0 replies; 6+ messages in thread
From: David Woodhouse @ 2009-07-13 13:28 UTC (permalink / raw)
  To: Chris Mason; +Cc: Roel Kluin, linux-btrfs, Andrew Morton, yan.zheng

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] brtfs: less- and greater than confusion
  2009-07-13 13:22 ` Chris Mason
  2009-07-13 13:26   ` Chris Mason
  2009-07-13 13:28   ` David Woodhouse
@ 2009-07-13 13:43   ` Yan Zheng
  2 siblings, 0 replies; 6+ messages in thread
From: Yan Zheng @ 2009-07-13 13:43 UTC (permalink / raw)
  To: Chris Mason, Roel Kluin, linux-btrfs, Andrew Morton, yan.zheng

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,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>> =A0 =A0 =A0 }
>>
>> - =A0 =A0 for (i =3D 0; i > nr; i++) {
>> + =A0 =A0 for (i =3D 0; i < nr; i++) {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct btrfs_multi_bio *multi;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct btrfs_bio_stripe *stripe;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 int ret;
>
> Thanks, this does look buggy. =A0That second loop should just be to v=
erify
> the first loop didn't mess things up. =A0Yan Zheng, is there any reas=
on 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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] brtfs: less- and greater than confusion
  2009-07-13 13:26   ` Chris Mason
@ 2009-07-13 13:57     ` Yan Zheng
  0 siblings, 0 replies; 6+ messages in thread
From: Yan Zheng @ 2009-07-13 13:57 UTC (permalink / raw)
  To: Chris Mason, Roel Kluin, linux-btrfs, Andrew Morton

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2009-07-13 13:57 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-12 22:30 [PATCH] brtfs: less- and greater than confusion Roel Kluin
2009-07-13 13:22 ` Chris Mason
2009-07-13 13:26   ` Chris Mason
2009-07-13 13:57     ` Yan Zheng
2009-07-13 13:28   ` David Woodhouse
2009-07-13 13:43   ` Yan Zheng

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox