Subject: Re: [PATCH] mm: Fix incorrect pfn passed to untrack_pfn in
 remap_pfn_range
To: Andrew Morton <akpm@linux-foundation.org>
References: <1461321088-3247-1-git-send-email-xyjxie@linux.vnet.ibm.com>
 <20160422113831.6294e65dbc4fe7a2d3421539@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        kirill.shutemov@linux.intel.com, jmarchan@redhat.com, mingo@kernel.org,
        vbabka@suse.cz, dave.hansen@linux.intel.com, dan.j.williams@intel.com,
        matthew.r.wilcox@intel.com, aarcange@redhat.com, mhocko@suse.com,
        luto@kernel.org, dahi@linux.vnet.ibm.com
From: Yongji Xie <xyjxie@linux.vnet.ibm.com>
Message-ID: <571C410F.6020601@linux.vnet.ibm.com>
Date: Sun, 24 Apr 2016 11:44:15 +0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <20160422113831.6294e65dbc4fe7a2d3421539@linux-foundation.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1209
Lines: 40

On 2016/4/23 2:38, Andrew Morton wrote:
> On Fri, 22 Apr 2016 18:31:28 +0800 Yongji Xie <xyjxie@linux.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