* [PATCH] mm: fix uninitialized variables for find_vma_prepare callers
@ 2008-06-30 16:54 Benny Halevy
2008-06-30 19:00 ` Hugh Dickins
0 siblings, 1 reply; 3+ messages in thread
From: Benny Halevy @ 2008-06-30 16:54 UTC (permalink / raw)
To: linux-mm; +Cc: linux-kernel, Benny Halevy
gcc 4.3.0 correctly emits the following warnings.
When a vma covering addr is found, find_vma_prepare indeed returns without
setting pprev, rb_link, and rb_parent.
/usr0/export/dev/bhalevy/git/linux-pnfs-bh-nfs41/mm/mmap.c: In function a??insert_vm_structa??:
/usr0/export/dev/bhalevy/git/linux-pnfs-bh-nfs41/mm/mmap.c:2085: warning: a??rb_parenta?? may be used uninitialized in this function
/usr0/export/dev/bhalevy/git/linux-pnfs-bh-nfs41/mm/mmap.c:2085: warning: a??rb_linka?? may be used uninitialized in this function
/usr0/export/dev/bhalevy/git/linux-pnfs-bh-nfs41/mm/mmap.c:2084: warning: a??preva?? may be used uninitialized in this function
/usr0/export/dev/bhalevy/git/linux-pnfs-bh-nfs41/mm/mmap.c: In function a??copy_vmaa??:
/usr0/export/dev/bhalevy/git/linux-pnfs-bh-nfs41/mm/mmap.c:2124: warning: a??rb_parenta?? may be used uninitialized in this function
/usr0/export/dev/bhalevy/git/linux-pnfs-bh-nfs41/mm/mmap.c:2124: warning: a??rb_linka?? may be used uninitialized in this function
/usr0/export/dev/bhalevy/git/linux-pnfs-bh-nfs41/mm/mmap.c:2123: warning: a??preva?? may be used uninitialized in this function
/usr0/export/dev/bhalevy/git/linux-pnfs-bh-nfs41/mm/mmap.c: In function a??do_brka??:
/usr0/export/dev/bhalevy/git/linux-pnfs-bh-nfs41/mm/mmap.c:1951: warning: a??rb_parenta?? may be used uninitialized in this function
/usr0/export/dev/bhalevy/git/linux-pnfs-bh-nfs41/mm/mmap.c:1951: warning: a??rb_linka?? may be used uninitialized in this function
/usr0/export/dev/bhalevy/git/linux-pnfs-bh-nfs41/mm/mmap.c:1949: warning: a??preva?? may be used uninitialized in this function
/usr0/export/dev/bhalevy/git/linux-pnfs-bh-nfs41/mm/mmap.c: In function a??mmap_regiona??:
/usr0/export/dev/bhalevy/git/linux-pnfs-bh-nfs41/mm/mmap.c:1092: warning: a??rb_parenta?? may be used uninitialized in this function
/usr0/export/dev/bhalevy/git/linux-pnfs-bh-nfs41/mm/mmap.c:1092: warning: a??rb_linka?? may be used uninitialized in this function
/usr0/export/dev/bhalevy/git/linux-pnfs-bh-nfs41/mm/mmap.c:1089: warning: a??preva?? may be used uninitialized in this function
Signed-off-by: Benny Halevy <bhalevy@panasas.com>
---
mm/mmap.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 3354fdd..81b9873 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -366,7 +366,7 @@ find_vma_prepare(struct mm_struct *mm, unsigned long addr,
if (vma_tmp->vm_end > addr) {
vma = vma_tmp;
if (vma_tmp->vm_start <= addr)
- return vma;
+ break;
__rb_link = &__rb_parent->rb_left;
} else {
rb_prev = __rb_parent;
--
1.5.6.GIT
--
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>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] mm: fix uninitialized variables for find_vma_prepare callers
2008-06-30 16:54 [PATCH] mm: fix uninitialized variables for find_vma_prepare callers Benny Halevy
@ 2008-06-30 19:00 ` Hugh Dickins
2008-07-01 11:53 ` Benny Halevy
0 siblings, 1 reply; 3+ messages in thread
From: Hugh Dickins @ 2008-06-30 19:00 UTC (permalink / raw)
To: Benny Halevy; +Cc: Andrea Arcangeli, linux-mm, linux-kernel
On Mon, 30 Jun 2008, Benny Halevy wrote:
> gcc 4.3.0 correctly emits the following warnings.
> When a vma covering addr is found, find_vma_prepare indeed returns without
> setting pprev, rb_link, and rb_parent.
That's amusing, thank you.
You may wonder how the vma rb_tree has been working all these years
despite that. The answer is that we only use find_vma_prepare when
about to insert a new vma: if there's anything already there, it's
either an error condition, or we go off and unmap the overlap without
taking any interest in those uninitialized values for linking.
It would be nicer to initialize them, and your patch is certainly
nice and simple. Would it have the effect, that it returns with
vma == *pprev when addr falls within an existing vma?
That would be a sensible outcome, I think.
Hugh
> [warnings snipped]
>
> Signed-off-by: Benny Halevy <bhalevy@panasas.com>
> ---
> mm/mmap.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 3354fdd..81b9873 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -366,7 +366,7 @@ find_vma_prepare(struct mm_struct *mm, unsigned long addr,
> if (vma_tmp->vm_end > addr) {
> vma = vma_tmp;
> if (vma_tmp->vm_start <= addr)
> - return vma;
> + break;
> __rb_link = &__rb_parent->rb_left;
> } else {
> rb_prev = __rb_parent;
--
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>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] mm: fix uninitialized variables for find_vma_prepare callers
2008-06-30 19:00 ` Hugh Dickins
@ 2008-07-01 11:53 ` Benny Halevy
0 siblings, 0 replies; 3+ messages in thread
From: Benny Halevy @ 2008-07-01 11:53 UTC (permalink / raw)
To: Hugh Dickins; +Cc: Andrea Arcangeli, linux-mm, linux-kernel
On Jun. 30, 2008, 22:00 +0300, Hugh Dickins <hugh@veritas.com> wrote:
> On Mon, 30 Jun 2008, Benny Halevy wrote:
>> gcc 4.3.0 correctly emits the following warnings.
>> When a vma covering addr is found, find_vma_prepare indeed returns without
>> setting pprev, rb_link, and rb_parent.
>
> That's amusing, thank you.
>
> You may wonder how the vma rb_tree has been working all these years
> despite that. The answer is that we only use find_vma_prepare when
> about to insert a new vma: if there's anything already there, it's
> either an error condition, or we go off and unmap the overlap without
> taking any interest in those uninitialized values for linking.
>
> It would be nicer to initialize them, and your patch is certainly
> nice and simple. Would it have the effect, that it returns with
> vma == *pprev when addr falls within an existing vma?
> That would be a sensible outcome, I think.
No, *pprev will be set to the last parent encountered with this
patch, but doing what you suggested is possible, though I doubt
it matters since apparently nobody is using pprev in this path
otherwise stuff would've just broken.
Benny
>
> Hugh
>
>> [warnings snipped]
>>
>> Signed-off-by: Benny Halevy <bhalevy@panasas.com>
>> ---
>> mm/mmap.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/mm/mmap.c b/mm/mmap.c
>> index 3354fdd..81b9873 100644
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -366,7 +366,7 @@ find_vma_prepare(struct mm_struct *mm, unsigned long addr,
>> if (vma_tmp->vm_end > addr) {
>> vma = vma_tmp;
>> if (vma_tmp->vm_start <= addr)
>> - return vma;
>> + break;
>> __rb_link = &__rb_parent->rb_left;
>> } else {
>> rb_prev = __rb_parent;
--
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>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-07-01 11:53 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-06-30 16:54 [PATCH] mm: fix uninitialized variables for find_vma_prepare callers Benny Halevy
2008-06-30 19:00 ` Hugh Dickins
2008-07-01 11:53 ` Benny Halevy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox