Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp2272881ybi; Sun, 28 Jul 2019 05:34:19 -0700 (PDT) X-Google-Smtp-Source: APXvYqz1uWexBg80qWw79GA4zGxlx4UsqtLzXAFNn5soGNBEMuWJU5lFtyelCoe+f0Ui5QcammLE X-Received: by 2002:a17:90a:cb18:: with SMTP id z24mr55276090pjt.108.1564317258972; Sun, 28 Jul 2019 05:34:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564317258; cv=none; d=google.com; s=arc-20160816; b=rlRQ2mLUZkOXfmQpsX5XKiA2+vDMjl+nbAYvoDDmdmI8NFCjsRV5x+1k3OBiqkhq5P RLjx96isNySvSQSRD5fLUN4GtjtRMYOsuHahk42recVt5Z3syDt0fBTR8VqjO0No4gib BJILCHA6uaSkkyI1zbU4aD+uRsLQS1uwNcvK+oVCS8JYhSLj8sUe4wre+GHOcXBBO2Hy on2NO2pWP5SF3eTs5TqeDFvAg+UzUz3BZLswE8YZ0VHpw1aUAiNhALBV4HkzP+2fwN+j h8p/5mPEZfdpLDeKCNNG6EqK/QIhiuh0q9c6I2iWODrhVYB91gYMfCtCM9Ia2Ky9KBFX A62Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=LeXrXNCJtYsasE0umdNfMj++oRQjgf4EdP5D01wmdFE=; b=a+lFxvQqmoqlPohBHrV+AjWd2CsSCREJgUArUPfnD6BXCQ2ImUgqkX/+OvJ8WteHPB kHLTwbOGmXvpx1O42ZOkFJQ+rnigDV2uJKBIqZmX5pCiMXzl8VuXR5/30e2B+OT0NnyG Qy6b3MGDOs7Tq8oKrTr9ugNgjSXO+ILVc2BuLWO+UfakDEiPSt8/vT3yGzMeuTOcwSWl aC7xVd6hZ9t7VNF/yAPEwQElAdmkjEzspFDLlppP1YXHXdHSTd3ZTpFRrnEizDadiLAt XJMHEXV62SlLBM5Hdis9ThWS7QZySeNDRHDj2Bl2anqiosxmZjcHyKjBlmMto2LU5ucz 2bmg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d5si20929113plo.396.2019.07.28.05.34.03; Sun, 28 Jul 2019 05:34:18 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726129AbfG1MdD (ORCPT + 99 others); Sun, 28 Jul 2019 08:33:03 -0400 Received: from foss.arm.com ([217.140.110.172]:60710 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726030AbfG1MdD (ORCPT ); Sun, 28 Jul 2019 08:33:03 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7D541337; Sun, 28 Jul 2019 05:33:02 -0700 (PDT) Received: from [10.163.1.126] (unknown [10.163.1.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B3BF13F71A; Sun, 28 Jul 2019 05:32:56 -0700 (PDT) Subject: Re: [PATCH v9 11/21] mm: pagewalk: Add p4d_entry() and pgd_entry() To: Steven Price , linux-mm@kvack.org Cc: Andy Lutomirski , Ard Biesheuvel , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Dave Hansen , Ingo Molnar , James Morse , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Peter Zijlstra , Thomas Gleixner , Will Deacon , x86@kernel.org, "H. Peter Anvin" , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Mark Rutland , "Liang, Kan" , Andrew Morton References: <20190722154210.42799-1-steven.price@arm.com> <20190722154210.42799-12-steven.price@arm.com> From: Anshuman Khandual Message-ID: Date: Sun, 28 Jul 2019 18:03:36 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190722154210.42799-12-steven.price@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/22/2019 09:12 PM, Steven Price wrote: > pgd_entry() and pud_entry() were removed by commit 0b1fbfe50006c410 > ("mm/pagewalk: remove pgd_entry() and pud_entry()") because there were > no users. We're about to add users so reintroduce them, along with > p4d_entry() as we now have 5 levels of tables. > > Note that commit a00cc7d9dd93d66a ("mm, x86: add support for > PUD-sized transparent hugepages") already re-added pud_entry() but with > different semantics to the other callbacks. Since there have never > been upstream users of this, revert the semantics back to match the > other callbacks. This means pud_entry() is called for all entries, not > just transparent huge pages. > > Signed-off-by: Steven Price > --- > include/linux/mm.h | 15 +++++++++------ > mm/pagewalk.c | 27 ++++++++++++++++----------- > 2 files changed, 25 insertions(+), 17 deletions(-) > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 0334ca97c584..b22799129128 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -1432,15 +1432,14 @@ void unmap_vmas(struct mmu_gather *tlb, struct vm_area_struct *start_vma, > > /** > * mm_walk - callbacks for walk_page_range > - * @pud_entry: if set, called for each non-empty PUD (2nd-level) entry > - * this handler should only handle pud_trans_huge() puds. > - * the pmd_entry or pte_entry callbacks will be used for > - * regular PUDs. > - * @pmd_entry: if set, called for each non-empty PMD (3rd-level) entry > + * @pgd_entry: if set, called for each non-empty PGD (top-level) entry > + * @p4d_entry: if set, called for each non-empty P4D entry > + * @pud_entry: if set, called for each non-empty PUD entry > + * @pmd_entry: if set, called for each non-empty PMD entry > * this handler is required to be able to handle > * pmd_trans_huge() pmds. They may simply choose to > * split_huge_page() instead of handling it explicitly. > - * @pte_entry: if set, called for each non-empty PTE (4th-level) entry > + * @pte_entry: if set, called for each non-empty PTE (lowest-level) entry > * @pte_hole: if set, called for each hole at all levels > * @hugetlb_entry: if set, called for each hugetlb entry > * @test_walk: caller specific callback function to determine whether > @@ -1455,6 +1454,10 @@ void unmap_vmas(struct mmu_gather *tlb, struct vm_area_struct *start_vma, > * (see the comment on walk_page_range() for more details) > */ > struct mm_walk { > + int (*pgd_entry)(pgd_t *pgd, unsigned long addr, > + unsigned long next, struct mm_walk *walk); > + int (*p4d_entry)(p4d_t *p4d, unsigned long addr, > + unsigned long next, struct mm_walk *walk); > int (*pud_entry)(pud_t *pud, unsigned long addr, > unsigned long next, struct mm_walk *walk); > int (*pmd_entry)(pmd_t *pmd, unsigned long addr, > diff --git a/mm/pagewalk.c b/mm/pagewalk.c > index c3084ff2569d..98373a9f88b8 100644 > --- a/mm/pagewalk.c > +++ b/mm/pagewalk.c > @@ -90,15 +90,9 @@ static int walk_pud_range(p4d_t *p4d, unsigned long addr, unsigned long end, > } > > if (walk->pud_entry) { > - spinlock_t *ptl = pud_trans_huge_lock(pud, walk->vma); > - > - if (ptl) { > - err = walk->pud_entry(pud, addr, next, walk); > - spin_unlock(ptl); > - if (err) > - break; > - continue; > - } > + err = walk->pud_entry(pud, addr, next, walk); > + if (err) > + break; But will not this still encounter possible THP entries when walking user page tables (valid walk->vma) in which case still needs to get a lock. OR will the callback take care of it ?