2016-04-22 10:35:36

by Yongji Xie

Subject: [PATCH] mm: Fix incorrect pfn passed to untrack_pfn in remap_pfn_range

We used generic hooks in remap_pfn_range to help archs to
track pfnmap regions. The code is something like:

int remap_pfn_range()
{
...
track_pfn_remap(vma, &prot, pfn, addr, PAGE_ALIGN(size));
...
pfn -= addr >> PAGE_SHIFT;
...
untrack_pfn(vma, pfn, PAGE_ALIGN(size));
...
}

Here we can easily find the pfn is changed but not recovered
before untrack_pfn() is called. That's incorrect.

Signed-off-by: Yongji Xie <[email protected]>
---
mm/memory.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/mm/memory.c b/mm/memory.c
index 098f00d..cb9e0c4 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1755,6 +1755,7 @@ int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
break;
} while (pgd++, addr = next, addr != end);

+ pfn += (end - PAGE_ALIGN(size)) >> PAGE_SHIFT;
if (err)
untrack_pfn(vma, pfn, PAGE_ALIGN(size));

--
1.7.9.5

2016-04-22 18:38:34

by Andrew Morton

Subject: Re: [PATCH] mm: Fix incorrect pfn passed to untrack_pfn in remap_pfn_range

On Fri, 22 Apr 2016 18:31:28 +0800 Yongji Xie <[email protected]> wrote:

> We used generic hooks in remap_pfn_range to help archs to
> track pfnmap regions. The code is something like:
>
> int remap_pfn_range()
> {
> ...
> track_pfn_remap(vma, &prot, pfn, addr, PAGE_ALIGN(size));
> ...
> pfn -= addr >> PAGE_SHIFT;
> ...
> untrack_pfn(vma, pfn, PAGE_ALIGN(size));
> ...
> }
>
> Here we can easily find the pfn is changed but not recovered
> before untrack_pfn() is called. That's incorrect.

What are the runtime effects of this bug?

> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1755,6 +1755,7 @@ int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
> break;
> } while (pgd++, addr = next, addr != end);
>
> + pfn += (end - PAGE_ALIGN(size)) >> PAGE_SHIFT;
> if (err)
> untrack_pfn(vma, pfn, PAGE_ALIGN(size));

I'm having trouble understanding this. Wouldn't it be better to simply
save the track_pfn_remap() call's `pfn' arg in a new local variable?

2016-04-24 03:44:32

by Yongji Xie

Subject: Re: [PATCH] mm: Fix incorrect pfn passed to untrack_pfn in remap_pfn_range

On 2016/4/23 2:38, Andrew Morton wrote:
> On Fri, 22 Apr 2016 18:31:28 +0800 Yongji Xie <[email protected]> wrote:
>
>> We used generic hooks in remap_pfn_range to help archs to
>> track pfnmap regions. The code is something like:
>>
>> int remap_pfn_range()
>> {
>> ...
>> track_pfn_remap(vma, &prot, pfn, addr, PAGE_ALIGN(size));
>> ...
>> pfn -= addr >> PAGE_SHIFT;
>> ...
>> untrack_pfn(vma, pfn, PAGE_ALIGN(size));
>> ...
>> }
>>
>> Here we can easily find the pfn is changed but not recovered
>> before untrack_pfn() is called. That's incorrect.
> What are the runtime effects of this bug?

No， this is just a fix in theory:-) .

>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -1755,6 +1755,7 @@ int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
>> break;
>> } while (pgd++, addr = next, addr != end);
>>
>> + pfn += (end - PAGE_ALIGN(size)) >> PAGE_SHIFT;
>> if (err)
>> untrack_pfn(vma, pfn, PAGE_ALIGN(size));
> I'm having trouble understanding this. Wouldn't it be better to simply
> save the track_pfn_remap() call's `pfn' arg in a new local variable?
>

Yes, it's a little difficult to understand this. I will send a v2 soon.

Thanks,
Yongji