From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754804AbbDQRL4 (ORCPT ); Fri, 17 Apr 2015 13:11:56 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:29809 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752155AbbDQRLz (ORCPT ); Fri, 17 Apr 2015 13:11:55 -0400 Message-ID: <55313ECD.3050604@oracle.com> Date: Fri, 17 Apr 2015 10:11:41 -0700 From: Mike Kravetz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Hillf Danton , "'Dave Hansen'" CC: linux-kernel , linux-mm@kvack.org, Michal Hocko Subject: Re: [RFC PATCH 4/4] mm: madvise allow remove operation for hugetlbfs References: <00e601d078da$9e762190$db6264b0$@alibaba-inc.com> <00ef01d078dd$96bfc480$c43f4d80$@alibaba-inc.com> In-Reply-To: <00ef01d078dd$96bfc480$c43f4d80$@alibaba-inc.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/17/2015 12:10 AM, Hillf Danton wrote: >> >> Now that we have hole punching support for hugetlbfs, we can >> also support the MADV_REMOVE interface to it. >> >> Signed-off-by: Dave Hansen >> Signed-off-by: Mike Kravetz >> --- >> mm/madvise.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/mm/madvise.c b/mm/madvise.c >> index d551475..c4a1027 100644 >> --- a/mm/madvise.c >> +++ b/mm/madvise.c >> @@ -299,7 +299,7 @@ static long madvise_remove(struct vm_area_struct *vma, >> >> *prev = NULL; /* tell sys_madvise we drop mmap_sem */ >> >> - if (vma->vm_flags & (VM_LOCKED | VM_HUGETLB)) >> + if (vma->vm_flags & VM_LOCKED) >> return -EINVAL; >> >> f = vma->vm_file; >> -- >> 2.1.0 > > After the above change offset is computed, > > offset = (loff_t)(start - vma->vm_start) > + ((loff_t)vma->vm_pgoff << PAGE_SHIFT); > > and I wonder if it is correct for huge page mapping. I think it will be correct. The above will be a (base) page size aligned offset into the file. This offset will be huge page aligned in the fallocate hole punch code. /* * For hole punch round up the beginning offset of the hole and * round down the end. */ hole_start = (offset + hpage_size - 1) & ~huge_page_mask(h); hole_end = (offset + len - (hpage_size - 1)) * ~huge_page_mask(h); Was the alignment your concern, or something else? -- Mike Kravetz