Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp62634ybh; Fri, 6 Mar 2020 16:03:54 -0800 (PST) X-Google-Smtp-Source: ADFU+vs6YR9AuC+XRFtdJOEVidRBvGlS6n3VkXPS99Z02zjMlCwXEIoi41MeoS21HBaLHxGRM/V6 X-Received: by 2002:a05:6830:1599:: with SMTP id i25mr4696994otr.190.1583539434634; Fri, 06 Mar 2020 16:03:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583539434; cv=none; d=google.com; s=arc-20160816; b=cfg4SQxJwLzYB+HJYByHGQ/Va/q2159q6DT5wp9+MbK92JxoXuXmlT1PAec2u09yeB PwbO5S7Ilx2RT4ZS8rIUr461VFh+QuyodjdsVDZlffvugouX0r3kBIg50tlutZHvwiee ne+khxlEm/ClxQBhSARU9eQ0ID6eFeHBTGfM8nocxwPcs+z0i3SUMIdsuR32qY5H7qsy ugrVx0a2V7X2UisXBPqQAXmEyHvnhZlgRSYyTiszZL01DYgMeM4WdsNBd2vVA4b1GbV5 E1D63te8mUDKkg9qjS7oRuZqPq4vAe0NozXFhFCFsY34EA3A2GDdjDY0KWfRI/Galfdj 1txw== 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=OzPLIfTD7SGmIGhpUzhus7cMyTkyeetRotvYXtmGPik=; b=OZBfTk3cNm+5XEKml3veE1AYA4LLThsYQWDBdKcHhACDJEP4dc+9ldRkjyJwaXOF2x K4j7x7PfnphDWIEcUQ9qqD4hwOOCztz5TxLmJtHs9wo/M8wG35SlfRCK0+qe5VUhcC36 nT3rgevKNjtxggetubcGG7RYYiWYVXdPv9IrKYMTD96oCKImu2xuFrn2GLk/xOEYvlOO zGN8sDv2/TRcAx+QIIdiDuoG548U0/H8iCHMNJKEjkByBj0l2s0SQYB38dIuApC4G/rO uKZRjMXh8+2eSr0e1tj1t7jN9rgTAJFrzZg7jrr/KledPInOcbxTOsxB5G8VdEiTz2fB 5Jjg== 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 w21si2264514otj.321.2020.03.06.16.03.42; Fri, 06 Mar 2020 16:03:54 -0800 (PST) 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 S1726533AbgCGAD2 (ORCPT + 99 others); Fri, 6 Mar 2020 19:03:28 -0500 Received: from foss.arm.com ([217.140.110.172]:39500 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726245AbgCGAD1 (ORCPT ); Fri, 6 Mar 2020 19:03:27 -0500 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 9A3A530E; Fri, 6 Mar 2020 16:03:26 -0800 (PST) Received: from [10.163.1.59] (unknown [10.163.1.59]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 689F93F237; Fri, 6 Mar 2020 16:03:17 -0800 (PST) Subject: Re: [PATCH V15] mm/debug: Add tests validating architecture page table helpers To: Qian Cai , linux-mm@kvack.org Cc: Andrew Morton , Mike Rapoport , Vineet Gupta , Catalin Marinas , Will Deacon , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , "Kirill A . Shutemov" , Paul Walmsley , Palmer Dabbelt , linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-riscv@lists.infradead.org, x86@kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Christophe Leroy References: <1583452659-11801-1-git-send-email-anshuman.khandual@arm.com> <1583527481.7365.165.camel@lca.pw> From: Anshuman Khandual Message-ID: <61250cdc-f80b-2e50-5168-2ec67ec6f1e6@arm.com> Date: Sat, 7 Mar 2020 05:33:15 +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: <1583527481.7365.165.camel@lca.pw> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/07/2020 02:14 AM, Qian Cai wrote: > On Fri, 2020-03-06 at 05:27 +0530, Anshuman Khandual wrote: >> This adds tests which will validate architecture page table helpers and >> other accessors in their compliance with expected generic MM semantics. >> This will help various architectures in validating changes to existing >> page table helpers or addition of new ones. >> >> This test covers basic page table entry transformations including but not >> limited to old, young, dirty, clean, write, write protect etc at various >> level along with populating intermediate entries with next page table page >> and validating them. >> >> Test page table pages are allocated from system memory with required size >> and alignments. The mapped pfns at page table levels are derived from a >> real pfn representing a valid kernel text symbol. This test gets called >> inside kernel_init() right after async_synchronize_full(). >> >> This test gets built and run when CONFIG_DEBUG_VM_PGTABLE is selected. Any >> architecture, which is willing to subscribe this test will need to select >> ARCH_HAS_DEBUG_VM_PGTABLE. For now this is limited to arc, arm64, x86, s390 >> and ppc32 platforms where the test is known to build and run successfully. >> Going forward, other architectures too can subscribe the test after fixing >> any build or runtime problems with their page table helpers. Meanwhile for >> better platform coverage, the test can also be enabled with CONFIG_EXPERT >> even without ARCH_HAS_DEBUG_VM_PGTABLE. >> >> Folks interested in making sure that a given platform's page table helpers >> conform to expected generic MM semantics should enable the above config >> which will just trigger this test during boot. Any non conformity here will >> be reported as an warning which would need to be fixed. This test will help >> catch any changes to the agreed upon semantics expected from generic MM and >> enable platforms to accommodate it thereafter. > > OK, I get this working on powerpc hash MMU as well, so this? > > diff --git a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt > b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt > index 64d0f9b15c49..c527d05c0459 100644 > --- a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt > +++ b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt > @@ -22,8 +22,7 @@ >      |       nios2: | TODO | >      |    openrisc: | TODO | >      |      parisc: | TODO | > -    |  powerpc/32: |  ok  | > -    |  powerpc/64: | TODO | > +    |     powerpc: |  ok  | >      |       riscv: | TODO | >      |        s390: |  ok  | >      |          sh: | TODO | > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index 2e7eee523ba1..176930f40e07 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -116,7 +116,7 @@ config PPC >   # >   select ARCH_32BIT_OFF_T if PPC32 >   select ARCH_HAS_DEBUG_VIRTUAL > - select ARCH_HAS_DEBUG_VM_PGTABLE if PPC32 > + select ARCH_HAS_DEBUG_VM_PGTABLE >   select ARCH_HAS_DEVMEM_IS_ALLOWED >   select ARCH_HAS_ELF_RANDOMIZE >   select ARCH_HAS_FORTIFY_SOURCE > diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c > index 96a91bda3a85..98990a515268 100644 > --- a/mm/debug_vm_pgtable.c > +++ b/mm/debug_vm_pgtable.c > @@ -256,7 +256,8 @@ static void __init pte_clear_tests(struct mm_struct *mm, > pte_t *ptep, >   pte_t pte = READ_ONCE(*ptep); >   >   pte = __pte(pte_val(pte) | RANDOM_ORVALUE); > - WRITE_ONCE(*ptep, pte); > + set_pte_at(mm, vaddr, ptep, pte); Hmm, set_pte_at() function is not preferred here for these tests. The idea is to avoid or atleast minimize TLB/cache flushes triggered from these sort of 'static' tests. set_pte_at() is platform provided and could/might trigger these flushes or some other platform specific synchronization stuff. Just wondering is there specific reason with respect to the soft lock up problem making it necessary to use set_pte_at() rather than a simple WRITE_ONCE() ? > + barrier(); >   pte_clear(mm, vaddr, ptep); >   pte = READ_ONCE(*ptep); >   WARN_ON(!pte_none(pte)); >