From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1809FC433DF for ; Wed, 12 Aug 2020 09:13:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BEDF52078B for ; Wed, 12 Aug 2020 09:13:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BEDF52078B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 38C0A6B0082; Wed, 12 Aug 2020 05:13:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 33BBC6B0083; Wed, 12 Aug 2020 05:13:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 252016B0087; Wed, 12 Aug 2020 05:13:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0222.hostedemail.com [216.40.44.222]) by kanga.kvack.org (Postfix) with ESMTP id 0FC7D6B0082 for ; Wed, 12 Aug 2020 05:13:03 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id BC7BD181AEF1A for ; Wed, 12 Aug 2020 09:13:02 +0000 (UTC) X-FDA: 77141352204.06.spade92_51176cd26fea Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin06.hostedemail.com (Postfix) with ESMTP id 95EB8100B631A for ; Wed, 12 Aug 2020 09:13:02 +0000 (UTC) X-HE-Tag: spade92_51176cd26fea X-Filterd-Recvd-Size: 3786 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf09.hostedemail.com (Postfix) with ESMTP for ; Wed, 12 Aug 2020 09:13:02 +0000 (UTC) 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 1202BD6E; Wed, 12 Aug 2020 02:13:01 -0700 (PDT) Received: from [10.163.66.87] (unknown [10.163.66.87]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 42F4E3F22E; Wed, 12 Aug 2020 02:12:58 -0700 (PDT) Subject: Re: [PATCH 03/16] debug_vm_pgtable/set_pte: Don't use set_pte_at to update an existing pte entry To: "Aneesh Kumar K.V" , linux-mm@kvack.org, akpm@linux-foundation.org Cc: mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org References: <20200812063358.369514-1-aneesh.kumar@linux.ibm.com> <20200812063358.369514-3-aneesh.kumar@linux.ibm.com> From: Anshuman Khandual Message-ID: <94ed519a-2cf2-af50-82be-2a559dee7d86@arm.com> Date: Wed, 12 Aug 2020 14:42:31 +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: <20200812063358.369514-3-aneesh.kumar@linux.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 95EB8100B631A X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 08/12/2020 12:03 PM, Aneesh Kumar K.V wrote: > set_pte_at() should not be used to set a pte entry at locations that > already holds a valid pte entry. Architectures like ppc64 don't do TLB > invalidate in set_pte_at() and hence expect it to be used to set locations > that are not a valid PTE. Even though set_pte_at() is not really a arch page table helper and very much arch specific, I just wonder why this deviation on ppc64 as compared to other platforms. Detecting such semantics variation across platforms is an objective of this test. As small nit. Please follow the existing subject format for all patches in here. It will improve readability and also help understand these changes better, later on. mm/debug_vm_pgtable: > > Signed-off-by: Aneesh Kumar K.V > --- > mm/debug_vm_pgtable.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c > index 4c32063a8acf..02a7c20aa4a2 100644 > --- a/mm/debug_vm_pgtable.c > +++ b/mm/debug_vm_pgtable.c > @@ -81,8 +81,6 @@ static void __init pte_advanced_tests(struct mm_struct *mm, > pte = ptep_get(ptep); > WARN_ON(pte_write(pte)); > > - pte = pfn_pte(pfn, prot); > - set_pte_at(mm, vaddr, ptep, pte); > ptep_get_and_clear(mm, vaddr, ptep); > pte = ptep_get(ptep); > WARN_ON(!pte_none(pte)); This makes sense. But could you please fold this code stanza with the previous one in order to imply that 'ptep' did have some valid entry before being cleared and checked against pte_none(). > @@ -97,12 +95,14 @@ static void __init pte_advanced_tests(struct mm_struct *mm, > pte = ptep_get(ptep); > WARN_ON(!(pte_write(pte) && pte_dirty(pte))); > > - pte = pfn_pte(pfn, prot); > - set_pte_at(mm, vaddr, ptep, pte); > ptep_get_and_clear_full(mm, vaddr, ptep, 1); > pte = ptep_get(ptep); > WARN_ON(!pte_none(pte)); Same, please fold back. > > + /* > + * We should clear pte before we do set_pte_at > + */ > + pte = ptep_get_and_clear(mm, vaddr, ptep); > pte = pte_mkyoung(pte); > set_pte_at(mm, vaddr, ptep, pte); > ptep_test_and_clear_young(vma, vaddr, ptep); > The comment above should also explain details that are mentioned in the commit message i.e how platforms such as ppc64 expects a clear pte entry for set_pte_at() to work.