Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932809AbdCGOq4 (ORCPT ); Tue, 7 Mar 2017 09:46:56 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:35723 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932698AbdCGOqC (ORCPT ); Tue, 7 Mar 2017 09:46:02 -0500 Date: Tue, 7 Mar 2017 16:52:58 +0300 From: "Kirill A. Shutemov" To: "Aneesh Kumar K.V" Cc: "Kirill A. Shutemov" , Andrea Arcangeli , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Minchan Kim Subject: Re: [PATCH 3/4] thp: fix MADV_DONTNEED vs. MADV_FREE race Message-ID: <20170307135258.GA2412@node> References: <20170302151034.27829-1-kirill.shutemov@linux.intel.com> <20170302151034.27829-4-kirill.shutemov@linux.intel.com> <871subdsrk.fsf@skywalker.in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871subdsrk.fsf@skywalker.in.ibm.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1501 Lines: 40 On Mon, Mar 06, 2017 at 08:19:03AM +0530, Aneesh Kumar K.V wrote: > "Kirill A. Shutemov" writes: > > > Basically the same race as with numa balancing in change_huge_pmd(), but > > a bit simpler to mitigate: we don't need to preserve dirty/young flags > > here due to MADV_FREE functionality. > > > > Signed-off-by: Kirill A. Shutemov > > Cc: Minchan Kim > > --- > > mm/huge_memory.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > > index bb2b3646bd78..324217c31ec9 100644 > > --- a/mm/huge_memory.c > > +++ b/mm/huge_memory.c > > @@ -1566,8 +1566,6 @@ bool madvise_free_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma, > > deactivate_page(page); > > > > if (pmd_young(orig_pmd) || pmd_dirty(orig_pmd)) { > > - orig_pmd = pmdp_huge_get_and_clear_full(tlb->mm, addr, pmd, > > - tlb->fullmm); > > orig_pmd = pmd_mkold(orig_pmd); > > orig_pmd = pmd_mkclean(orig_pmd); > > > > Instead can we do a new interface that does something like > > pmdp_huge_update(tlb->mm, addr, pmd, new_pmd); > > We do have a variant already in ptep_set_access_flags. What we need is > something that can be used to update THP pmd, without converting it to > pmd_none and one which doens't loose reference and change bit ? Sounds like a good idea. Would you volunteer to implement it? I don't have time for this right now. -- Kirill A. Shutemov