[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <571C410F.6020601@linux.vnet.ibm.com>
Date: Sun, 24 Apr 2016 11:44:15 +0800
From: Yongji Xie <xyjxie@...ux.vnet.ibm.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
kirill.shutemov@...ux.intel.com, jmarchan@...hat.com,
mingo@...nel.org, vbabka@...e.cz, dave.hansen@...ux.intel.com,
dan.j.williams@...el.com, matthew.r.wilcox@...el.com,
aarcange@...hat.com, mhocko@...e.com, luto@...nel.org,
dahi@...ux.vnet.ibm.com
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 <xyjxie@...ux.vnet.ibm.com> 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
Powered by blists - more mailing lists