[PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

[PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

[zijun_hu]

From: zijun_hu <zijun_hu@htc.com>

correct a few logic error for __insert_vmap_area() since the else
if condition is always true and meaningless

in order to fix this issue, if vmap_area inserted is lower than one
on rbtree then walk around left branch; if higher then right branch
otherwise intersects with the other then BUG_ON() is triggered

Signed-off-by: zijun_hu <zijun_hu@htc.com>
---
 mm/vmalloc.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 91f44e7..cc6ecd6 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -321,10 +321,10 @@ static void __insert_vmap_area(struct vmap_area *va)
 
 		parent = *p;
 		tmp_va = rb_entry(parent, struct vmap_area, rb_node);
-		if (va->va_start < tmp_va->va_end)
-			p = &(*p)->rb_left;
-		else if (va->va_end > tmp_va->va_start)
-			p = &(*p)->rb_right;
+		if (va->va_end <= tmp_va->va_start)
+			p = &parent->rb_left;
+		else if (va->va_start >= tmp_va->va_end)
+			p = &parent->rb_right;
 		else
 			BUG();
 	}
-- 
1.9.1

[PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

[zijun_hu]

From: zijun_hu <zijun_hu@htc.com>

correct a few logic error for __insert_vmap_area() since the else
if condition is always true and meaningless

in order to fix this issue, if vmap_area inserted is lower than one
on rbtree then walk around left branch; if higher then right branch
otherwise intersects with the other then BUG_ON() is triggered

Signed-off-by: zijun_hu <zijun_hu@htc.com>
---
 mm/vmalloc.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 91f44e7..cc6ecd6 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -321,10 +321,10 @@ static void __insert_vmap_area(struct vmap_area *va)
 
 		parent = *p;
 		tmp_va = rb_entry(parent, struct vmap_area, rb_node);
-		if (va->va_start < tmp_va->va_end)
-			p = &(*p)->rb_left;
-		else if (va->va_end > tmp_va->va_start)
-			p = &(*p)->rb_right;
+		if (va->va_end <= tmp_va->va_start)
+			p = &parent->rb_left;
+		else if (va->va_start >= tmp_va->va_end)
+			p = &parent->rb_right;
 		else
 			BUG();
 	}
-- 
1.9.1

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

[David Rientjes]

On Wed, 21 Sep 2016, zijun_hu wrote:

> From: zijun_hu <zijun_hu@htc.com>
> 
> correct a few logic error for __insert_vmap_area() since the else
> if condition is always true and meaningless
> 
> in order to fix this issue, if vmap_area inserted is lower than one
> on rbtree then walk around left branch; if higher then right branch
> otherwise intersects with the other then BUG_ON() is triggered
> 

Under normal operation, you're right that the "else if" conditional should 
always succeed: we don't want to BUG() unless there's a bug.  The original 
code can catch instances when va->va_start == tmp_va->va_end where we 
should BUG().  Your code silently ignores it.

Re: [PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

[David Rientjes]

On Wed, 21 Sep 2016, zijun_hu wrote:

> From: zijun_hu <zijun_hu@htc.com>
> 
> correct a few logic error for __insert_vmap_area() since the else
> if condition is always true and meaningless
> 
> in order to fix this issue, if vmap_area inserted is lower than one
> on rbtree then walk around left branch; if higher then right branch
> otherwise intersects with the other then BUG_ON() is triggered
> 

Under normal operation, you're right that the "else if" conditional should 
always succeed: we don't want to BUG() unless there's a bug.  The original 
code can catch instances when va->va_start == tmp_va->va_end where we 
should BUG().  Your code silently ignores it.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

[zijun_hu]

On 2016/9/22 5:10, David Rientjes wrote:
> On Wed, 21 Sep 2016, zijun_hu wrote:
> 
>> From: zijun_hu <zijun_hu@htc.com>
>>
>> correct a few logic error for __insert_vmap_area() since the else
>> if condition is always true and meaningless
>>
>> in order to fix this issue, if vmap_area inserted is lower than one
>> on rbtree then walk around left branch; if higher then right branch
>> otherwise intersects with the other then BUG_ON() is triggered
>>
> 
> Under normal operation, you're right that the "else if" conditional should 
> always succeed: we don't want to BUG() unless there's a bug.  The original 
> code can catch instances when va->va_start == tmp_va->va_end where we 
> should BUG().  Your code silently ignores it.
> 
Hmm, the BUG_ON() appears in the original code, i don't introduce it.
it maybe be better to consider va->va_start == tmp_va->va_end as normal case
and should not BUG_ON() it since the available range of vmap_erea include
the start boundary but the end, BTW, represented as [start, end)

this patch correct the logic to that mentioned in the comments, it maybe be
more logical and more understandable

Re: [PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

[zijun_hu]

On 2016/9/22 5:10, David Rientjes wrote:
> On Wed, 21 Sep 2016, zijun_hu wrote:
> 
>> From: zijun_hu <zijun_hu@htc.com>
>>
>> correct a few logic error for __insert_vmap_area() since the else
>> if condition is always true and meaningless
>>
>> in order to fix this issue, if vmap_area inserted is lower than one
>> on rbtree then walk around left branch; if higher then right branch
>> otherwise intersects with the other then BUG_ON() is triggered
>>
> 
> Under normal operation, you're right that the "else if" conditional should 
> always succeed: we don't want to BUG() unless there's a bug.  The original 
> code can catch instances when va->va_start == tmp_va->va_end where we 
> should BUG().  Your code silently ignores it.
> 
Hmm, the BUG_ON() appears in the original code, i don't introduce it.
it maybe be better to consider va->va_start == tmp_va->va_end as normal case
and should not BUG_ON() it since the available range of vmap_erea include
the start boundary but the end, BTW, represented as [start, end)

this patch correct the logic to that mentioned in the comments, it maybe be
more logical and more understandable

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

[David Rientjes]

On Thu, 22 Sep 2016, zijun_hu wrote:

> >> correct a few logic error for __insert_vmap_area() since the else
> >> if condition is always true and meaningless
> >>
> >> in order to fix this issue, if vmap_area inserted is lower than one
> >> on rbtree then walk around left branch; if higher then right branch
> >> otherwise intersects with the other then BUG_ON() is triggered
> >>
> > 
> > Under normal operation, you're right that the "else if" conditional should 
> > always succeed: we don't want to BUG() unless there's a bug.  The original 
> > code can catch instances when va->va_start == tmp_va->va_end where we 
> > should BUG().  Your code silently ignores it.
> > 
> Hmm, the BUG_ON() appears in the original code, i don't introduce it.
> it maybe be better to consider va->va_start == tmp_va->va_end as normal case
> and should not BUG_ON() it since the available range of vmap_erea include
> the start boundary but the end, BTW, represented as [start, end)
> 

We don't support inserting when va->va_start == tmp_va->va_end, plain and 
simple.  There's no reason to do so.  NACK to the patch.

Re: [PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

[David Rientjes]

On Thu, 22 Sep 2016, zijun_hu wrote:

> >> correct a few logic error for __insert_vmap_area() since the else
> >> if condition is always true and meaningless
> >>
> >> in order to fix this issue, if vmap_area inserted is lower than one
> >> on rbtree then walk around left branch; if higher then right branch
> >> otherwise intersects with the other then BUG_ON() is triggered
> >>
> > 
> > Under normal operation, you're right that the "else if" conditional should 
> > always succeed: we don't want to BUG() unless there's a bug.  The original 
> > code can catch instances when va->va_start == tmp_va->va_end where we 
> > should BUG().  Your code silently ignores it.
> > 
> Hmm, the BUG_ON() appears in the original code, i don't introduce it.
> it maybe be better to consider va->va_start == tmp_va->va_end as normal case
> and should not BUG_ON() it since the available range of vmap_erea include
> the start boundary but the end, BTW, represented as [start, end)
> 

We don't support inserting when va->va_start == tmp_va->va_end, plain and 
simple.  There's no reason to do so.  NACK to the patch.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

[zijun_hu]

On 2016/9/22 6:45, David Rientjes wrote:
> On Thu, 22 Sep 2016, zijun_hu wrote:
> 
>>>> correct a few logic error for __insert_vmap_area() since the else
>>>> if condition is always true and meaningless
>>>>
>>>> in order to fix this issue, if vmap_area inserted is lower than one
>>>> on rbtree then walk around left branch; if higher then right branch
>>>> otherwise intersects with the other then BUG_ON() is triggered
>>>>
>>>
>>> Under normal operation, you're right that the "else if" conditional should 
>>> always succeed: we don't want to BUG() unless there's a bug.  The original 
>>> code can catch instances when va->va_start == tmp_va->va_end where we 
>>> should BUG().  Your code silently ignores it.
>>>
>> Hmm, the BUG_ON() appears in the original code, i don't introduce it.
>> it maybe be better to consider va->va_start == tmp_va->va_end as normal case
>> and should not BUG_ON() it since the available range of vmap_erea include
>> the start boundary but the end, BTW, represented as [start, end)
>>
> 
> We don't support inserting when va->va_start == tmp_va->va_end, plain and 
> simple.  There's no reason to do so.  NACK to the patch.
> 
i am sorry i disagree with you because
1) in almost all context of vmalloc, original logic treat the special case as normal
   for example, __find_vmap_area() or alloc_vmap_area()
2) don't use the limited vmap area effectively, it maybe causes BUG_ON() easy
3) consider below case
   it provided there have been two vmap_areas [4, 12) and [20, 28), what will happens
   when alloc_vmap_area(8, 4, 6, 24,...)?  should we use [12,20) for our request?

Re: [PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

[zijun_hu]

On 2016/9/22 6:45, David Rientjes wrote:
> On Thu, 22 Sep 2016, zijun_hu wrote:
> 
>>>> correct a few logic error for __insert_vmap_area() since the else
>>>> if condition is always true and meaningless
>>>>
>>>> in order to fix this issue, if vmap_area inserted is lower than one
>>>> on rbtree then walk around left branch; if higher then right branch
>>>> otherwise intersects with the other then BUG_ON() is triggered
>>>>
>>>
>>> Under normal operation, you're right that the "else if" conditional should 
>>> always succeed: we don't want to BUG() unless there's a bug.  The original 
>>> code can catch instances when va->va_start == tmp_va->va_end where we 
>>> should BUG().  Your code silently ignores it.
>>>
>> Hmm, the BUG_ON() appears in the original code, i don't introduce it.
>> it maybe be better to consider va->va_start == tmp_va->va_end as normal case
>> and should not BUG_ON() it since the available range of vmap_erea include
>> the start boundary but the end, BTW, represented as [start, end)
>>
> 
> We don't support inserting when va->va_start == tmp_va->va_end, plain and 
> simple.  There's no reason to do so.  NACK to the patch.
> 
i am sorry i disagree with you because
1) in almost all context of vmalloc, original logic treat the special case as normal
   for example, __find_vmap_area() or alloc_vmap_area()
2) don't use the limited vmap area effectively, it maybe causes BUG_ON() easy
3) consider below case
   it provided there have been two vmap_areas [4, 12) and [20, 28), what will happens
   when alloc_vmap_area(8, 4, 6, 24,...)?  should we use [12,20) for our request?



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

[David Rientjes]

On Thu, 22 Sep 2016, zijun_hu wrote:

> > We don't support inserting when va->va_start == tmp_va->va_end, plain and 
> > simple.  There's no reason to do so.  NACK to the patch.
> > 
> i am sorry i disagree with you because
> 1) in almost all context of vmalloc, original logic treat the special case as normal
>    for example, __find_vmap_area() or alloc_vmap_area()

The ranges are [start, end) like everywhere else.  __find_vmap_area() is 
implemented as such for the passed address.  The address is aligned in 
alloc_vmap_area(), there's no surprise here.  The logic is correct in 
__insert_vmap_area().

Re: [PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

[David Rientjes]

On Thu, 22 Sep 2016, zijun_hu wrote:

> > We don't support inserting when va->va_start == tmp_va->va_end, plain and 
> > simple.  There's no reason to do so.  NACK to the patch.
> > 
> i am sorry i disagree with you because
> 1) in almost all context of vmalloc, original logic treat the special case as normal
>    for example, __find_vmap_area() or alloc_vmap_area()

The ranges are [start, end) like everywhere else.  __find_vmap_area() is 
implemented as such for the passed address.  The address is aligned in 
alloc_vmap_area(), there's no surprise here.  The logic is correct in 
__insert_vmap_area().

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

[zijun_hu]

On 2016/9/22 7:15, David Rientjes wrote:
> On Thu, 22 Sep 2016, zijun_hu wrote:
> 
>>> We don't support inserting when va->va_start == tmp_va->va_end, plain and 
>>> simple.  There's no reason to do so.  NACK to the patch.
>>>
>> i am sorry i disagree with you because
>> 1) in almost all context of vmalloc, original logic treat the special case as normal
>>    for example, __find_vmap_area() or alloc_vmap_area()
> 
> The ranges are [start, end) like everywhere else.  __find_vmap_area() is 
> implemented as such for the passed address.  The address is aligned in 
> alloc_vmap_area(), there's no surprise here.  The logic is correct in 
> __insert_vmap_area().
> 
1) is the desire behavior of __insert_vmap_area() conform with that mentioned
   in my comments?
2) which way of code implementation can present the desire purpose more clear
   and more understandable?

Re: [PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

[zijun_hu]

On 2016/9/22 7:15, David Rientjes wrote:
> On Thu, 22 Sep 2016, zijun_hu wrote:
> 
>>> We don't support inserting when va->va_start == tmp_va->va_end, plain and 
>>> simple.  There's no reason to do so.  NACK to the patch.
>>>
>> i am sorry i disagree with you because
>> 1) in almost all context of vmalloc, original logic treat the special case as normal
>>    for example, __find_vmap_area() or alloc_vmap_area()
> 
> The ranges are [start, end) like everywhere else.  __find_vmap_area() is 
> implemented as such for the passed address.  The address is aligned in 
> alloc_vmap_area(), there's no surprise here.  The logic is correct in 
> __insert_vmap_area().
> 
1) is the desire behavior of __insert_vmap_area() conform with that mentioned
   in my comments?
2) which way of code implementation can present the desire purpose more clear
   and more understandable?


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

[zijun_hu]

On 09/21/2016 12:23 PM, zijun_hu wrote:
> From: zijun_hu <zijun_hu@htc.com>
> 
> correct a few logic error for __insert_vmap_area() since the else
> if condition is always true and meaningless
> 
> in order to fix this issue, if vmap_area inserted is lower than one
> on rbtree then walk around left branch; if higher then right branch
> otherwise intersects with the other then BUG_ON() is triggered
> 
> Signed-off-by: zijun_hu <zijun_hu@htc.com>
i give more explanation to the intent of my change
any comments is welcome
> ---
>  mm/vmalloc.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 91f44e7..cc6ecd6 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -321,10 +321,10 @@ static void __insert_vmap_area(struct vmap_area *va)
>  
>  		parent = *p;
>  		tmp_va = rb_entry(parent, struct vmap_area, rb_node);
> -		if (va->va_start < tmp_va->va_end)
> -			p = &(*p)->rb_left;
> -		else if (va->va_end > tmp_va->va_start)
> -			p = &(*p)->rb_right;
this else if condition is always true and meaningless as long as there are no
zero sized vamp_area due to the following expression
va->va_end > va->va_start >= tmp_va->va_end > tmp_va->va_start

> +		if (va->va_end <= tmp_va->va_start)
> +			p = &parent->rb_left;
if the vamp_area to be inserted is lower than that on the rbtree then
we walk around the left branch of the node given
consider va->va_end == tmp_va->va_start as legal case which represent
two neighbor areas tightly
BTW, the available range of a vmap area include the start boundary not the
end, namely, [start, end)
> +		else if (va->va_start >= tmp_va->va_end)
> +			p = &parent->rb_right;
if the vamp_area to be inserted is higher than that on the rbtree then
we walk around the right branch of the node given
>  		else
>  			BUG();
this indicate the vamp_area to be inserted have intersects with that on the rbtree
then we remain the BUG() logic
>  	}
> 

Re: [RFC PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

[zijun_hu]

On 09/21/2016 12:23 PM, zijun_hu wrote:
> From: zijun_hu <zijun_hu@htc.com>
> 
> correct a few logic error for __insert_vmap_area() since the else
> if condition is always true and meaningless
> 
> in order to fix this issue, if vmap_area inserted is lower than one
> on rbtree then walk around left branch; if higher then right branch
> otherwise intersects with the other then BUG_ON() is triggered
> 
> Signed-off-by: zijun_hu <zijun_hu@htc.com>
i give more explanation to the intent of my change
any comments is welcome
> ---
>  mm/vmalloc.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 91f44e7..cc6ecd6 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -321,10 +321,10 @@ static void __insert_vmap_area(struct vmap_area *va)
>  
>  		parent = *p;
>  		tmp_va = rb_entry(parent, struct vmap_area, rb_node);
> -		if (va->va_start < tmp_va->va_end)
> -			p = &(*p)->rb_left;
> -		else if (va->va_end > tmp_va->va_start)
> -			p = &(*p)->rb_right;
this else if condition is always true and meaningless as long as there are no
zero sized vamp_area due to the following expression
va->va_end > va->va_start >= tmp_va->va_end > tmp_va->va_start

> +		if (va->va_end <= tmp_va->va_start)
> +			p = &parent->rb_left;
if the vamp_area to be inserted is lower than that on the rbtree then
we walk around the left branch of the node given
consider va->va_end == tmp_va->va_start as legal case which represent
two neighbor areas tightly
BTW, the available range of a vmap area include the start boundary not the
end, namely, [start, end)
> +		else if (va->va_start >= tmp_va->va_end)
> +			p = &parent->rb_right;
if the vamp_area to be inserted is higher than that on the rbtree then
we walk around the right branch of the node given
>  		else
>  			BUG();
this indicate the vamp_area to be inserted have intersects with that on the rbtree
then we remain the BUG() logic
>  	}
> 


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

[zijun_hu]

On 09/22/2016 07:15 AM, David Rientjes wrote:
> On Thu, 22 Sep 2016, zijun_hu wrote:
> 
>>> We don't support inserting when va->va_start == tmp_va->va_end, plain and 
>>> simple.  There's no reason to do so.  NACK to the patch.
>>>
>> i am sorry i disagree with you because
>> 1) in almost all context of vmalloc, original logic treat the special case as normal
>>    for example, __find_vmap_area() or alloc_vmap_area()
> 
> The ranges are [start, end) like everywhere else.  __find_vmap_area() is 
> implemented as such for the passed address.  The address is aligned in 
> alloc_vmap_area(), there's no surprise here.  The logic is correct in 
> __insert_vmap_area().
> 
i am sorry to disagree with you
i will resend this patch with more detailed illustration

Re: [PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

[zijun_hu]

On 09/22/2016 07:15 AM, David Rientjes wrote:
> On Thu, 22 Sep 2016, zijun_hu wrote:
> 
>>> We don't support inserting when va->va_start == tmp_va->va_end, plain and 
>>> simple.  There's no reason to do so.  NACK to the patch.
>>>
>> i am sorry i disagree with you because
>> 1) in almost all context of vmalloc, original logic treat the special case as normal
>>    for example, __find_vmap_area() or alloc_vmap_area()
> 
> The ranges are [start, end) like everywhere else.  __find_vmap_area() is 
> implemented as such for the passed address.  The address is aligned in 
> alloc_vmap_area(), there's no surprise here.  The logic is correct in 
> __insert_vmap_area().
> 
i am sorry to disagree with you
i will resend this patch with more detailed illustration


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>