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=-2.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 657D0C76190 for ; Fri, 26 Jul 2019 04:46:42 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3E8C022BE8 for ; Fri, 26 Jul 2019 04:46:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="JZ/3Fps6" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3E8C022BE8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:References:To:Subject:From:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=EQrJM7Mive1yGHUFFn2rEudtBg9ThMNiKrRte2PmrYU=; b=JZ/3Fps6SS2rJP WJDX7htD6i9y85/b/F4bB6mzqHlw8pYiaK5HCm4yJ/2xRNvXqFey96A3XfpH4V2F7aCDq49M7xURr XOx6+B6vTcHL946kpX7cbR8/5OsBjfA6bDFDBMR30vWfM24cJauiSFrsBy3gj0Hn1dUB/TKj0D38h 2oHhX+2RzVbTebJSGT0M7tm9snME1q7FEjB2oUI90xMBhet4bhzBOzvdrLeJWMSYY1+w5I891DQWs +YC8tMcQlmHmMnb/ldvN0hYXZBbfE8GFfOA2c5JWW+8UJnV+4b64DcR1GETgtJAdhhY+dgc73mV4n uQt5aRuoQWoPOntxABxg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hqs7t-0002lV-K5; Fri, 26 Jul 2019 04:46:41 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hqs7q-0002l7-QA for linux-arm-kernel@lists.infradead.org; Fri, 26 Jul 2019 04:46:40 +0000 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 B6593337; Thu, 25 Jul 2019 21:46:37 -0700 (PDT) Received: from [10.163.1.197] (unknown [10.163.1.197]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4CBE13F694; Thu, 25 Jul 2019 21:46:33 -0700 (PDT) From: Anshuman Khandual Subject: Re: [RFC] mm/pgtable/debug: Add test validating architecture page table helpers To: Matthew Wilcox References: <1564037723-26676-1-git-send-email-anshuman.khandual@arm.com> <1564037723-26676-2-git-send-email-anshuman.khandual@arm.com> <20190725143920.GW363@bombadil.infradead.org> Message-ID: Date: Fri, 26 Jul 2019 10:17:11 +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: <20190725143920.GW363@bombadil.infradead.org> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190725_214638_938865_06BA8FEA X-CRM114-Status: GOOD ( 23.77 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Kees Cook , Sri Krishna chowdary , Ard Biesheuvel , Masahiro Yamada , Tetsuo Handa , x86@kernel.org, Dave Hansen , linux-kernel@vger.kernel.org, Steven Price , linux-mm@kvack.org, Mark Brown , Andrew Morton , Michal Hocko , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 07/25/2019 08:09 PM, Matthew Wilcox wrote: > On Thu, Jul 25, 2019 at 12:25:23PM +0530, Anshuman Khandual wrote: >> This adds a test module which will validate architecture page table helpers >> and accessors regarding compliance with generic MM semantics expectations. >> This will help various architectures in validating changes to the existing >> page table helpers or addition of new ones. > > I think this is a really good idea. > >> lib/Kconfig.debug | 14 +++ >> lib/Makefile | 1 + >> lib/test_arch_pgtable.c | 290 ++++++++++++++++++++++++++++++++++++++++++++++++ > > Is this the right place for it? I worry that lib/ is going to get overloaded > with test code, and this feels more like mm/ test code. Sure this can be moved to mm/ but unlike existing test configs there (following) lets keep some config description in mm/Kconfig. Will probably rename this as CONFIG_DEBUG_ARCH_PGTABLE_TEST to match other tests. CONFIG_DEBUG_KMEMLEAK_TEST CONFIG_DEBUG_RODATA_TEST CONFIG_MEMTEST After moving to mm/ directory I guess it does not need a loadable module option. > >> +#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE >> +static void pmd_basic_tests(void) >> +{ >> + pmd_t pmd; >> + >> + pmd = mk_pmd(page, prot); > > But 'page' isn't necessarily PMD-aligned. I don't think we can rely on > architectures doing the right thing if asked to make a PMD for a randomly > aligned page. > > How about finding the physical address of something like kernel_init(), Physical address corresponding to the symbol in the kernel text segment ? > and using the corresponding pte/pmd/pud/p4d/pgd that encompasses that So I guess this will help us use pte/pmd/pud/p4d/pgd entries from a real and present mapping rather then making them up for test purpose. Although we are not creating real page tables here just wondering if this could some how affect these real mapping in anyway from some accessors. The current proposal stays clear from anything real - allocates, evaluates and releases. Also table entries at pmd/pud/p4d/pgd cannot be operated with accessors in the test. THP and PUD THP will operate on leaf entries at pmd or pud levels. We need them as leaf entries created from allocated (aligned) pfns. While determining pte/pmd/pud/p4d/pgd for kernel_init() some of them will be table entries. > address? It's also better to pass in the pfn/page rather than using global > variables to communicate to the test functions. Sure those can be allocated and passed from the main function. Just wanted to avoid page allocation in each individual tests. > >> + /* >> + * A huge page does not point to next level page table >> + * entry. Hence this must qualify as pmd_bad(). >> + */ >> + WARN_ON(!pmd_bad(pmd_mkhuge(pmd))); > > I didn't know that rule. This is helpful because it gives us somewhere > to document all these tricksy little rules. That is another objective this test has which will help settle semantics in a clear and documented manner. > >> +#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD >> +static void pud_basic_tests(void) > > Is this the right ifdef? IIUC THP at PUD is where the pud_t entries are directly operated upon and the corresponding accessors are present only when HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD is enabled. Am I missing something here ? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel