* 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: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
* 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