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=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 ED9DDC4CECD for ; Fri, 20 Sep 2019 04:06:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A11ED20882 for ; Fri, 20 Sep 2019 04:06:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A11ED20882 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 119628E000F; Fri, 20 Sep 2019 00:06:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0CAC68E0003; Fri, 20 Sep 2019 00:06:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EFAF58E000F; Fri, 20 Sep 2019 00:06:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0220.hostedemail.com [216.40.44.220]) by kanga.kvack.org (Postfix) with ESMTP id C9D2C8E0003 for ; Fri, 20 Sep 2019 00:06:12 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 438ED181AC9AE for ; Fri, 20 Sep 2019 04:06:12 +0000 (UTC) X-FDA: 75953961384.20.jar28_36098026ec42f X-HE-Tag: jar28_36098026ec42f X-Filterd-Recvd-Size: 5375 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Fri, 20 Sep 2019 04:06:11 +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 08718337; Thu, 19 Sep 2019 21:06:10 -0700 (PDT) Received: from [10.162.40.137] (p8cg001049571a15.blr.arm.com [10.162.40.137]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 85C4F3F67D; Thu, 19 Sep 2019 21:05:57 -0700 (PDT) Subject: Re: [PATCH V2 2/2] mm/pgtable/debug: Add test validating architecture page table helpers To: Gerald Schaefer , Christophe Leroy Cc: linux-mm@kvack.org, Andrew Morton , Vlastimil Babka , Greg Kroah-Hartman , Thomas Gleixner , Mike Rapoport , Jason Gunthorpe , Dan Williams , Peter Zijlstra , Michal Hocko , Mark Rutland , Mark Brown , Steven Price , Ard Biesheuvel , Masahiro Yamada , Kees Cook , Tetsuo Handa , Matthew Wilcox , Sri Krishna chowdary , Dave Hansen , Russell King - ARM Linux , Michael Ellerman , Paul Mackerras , Martin Schwidefsky , Heiko Carstens , "David S. Miller" , Vineet Gupta , James Hogan , Paul Burton , Ralf Baechle , "Kirill A . Shutemov" , linux-snps-arc@lists.infradead.org, linux-mips@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org References: <1568268173-31302-1-git-send-email-anshuman.khandual@arm.com> <1568268173-31302-3-git-send-email-anshuman.khandual@arm.com> <502c497a-9bf1-7d2e-95f2-cfebcd9cf1d9@arm.com> <95ed9d92-dd43-4c45-2e52-738aed7f2fb5@c-s.fr> <64504101-d9dd-f273-02f9-e9a8b178eecc@c-s.fr> <20190918202243.37e709df@thinkpad> From: Anshuman Khandual Message-ID: <5a6045af-bcfb-12c2-0f4a-3b49a905ec4d@arm.com> Date: Fri, 20 Sep 2019 09:36:12 +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: <20190918202243.37e709df@thinkpad> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 09/18/2019 11:52 PM, Gerald Schaefer wrote: > On Wed, 18 Sep 2019 18:26:03 +0200 > Christophe Leroy wrote: > > [..] >> My suggestion was not to completely drop the #ifdef but to do like you >> did in pgd_clear_tests() for instance, ie to add the following test on >> top of the function: >> >> if (mm_pud_folded(mm) || is_defined(__ARCH_HAS_5LEVEL_HACK)) >> return; >> > > Ah, very nice, this would also fix the remaining issues for s390. Since > we have dynamic page table folding, neither __PAGETABLE_PXX_FOLDED nor > __ARCH_HAS_XLEVEL_HACK is defined, but mm_pxx_folded() will work. Like Christophe mentioned earlier on the other thread, we will convert all __PGTABLE_PXX_FOLDED checks as mm_pxx_folded() but looks like ARCH_HAS_[4 and 5]LEVEL_HACK macros will still be around. Will respin the series with all agreed upon changes first and probably we can then discuss pending issues from there. > > mm_alloc() returns with a 3-level page table by default on s390, so we > will run into issues in p4d_clear/populate_tests(), and also at the end > with p4d/pud_free() (double free). > > So, adding the mm_pud_folded() check to p4d_clear/populate_tests(), > and also adding mm_p4d/pud_folded() checks at the end before calling> p4d/pud_free(), would make it all work on s390. Atleast p4d_clear/populate_tests() tests will be taken care. > > BTW, regarding p4d/pud_free(), I'm not sure if we should rather check > the folding inside our s390 functions, similar to how we do it for > p4d/pud_free_tlb(), instead of relying on not being called for folded > p4d/pud. So far, I see no problem with this behavior, all callers of > p4d/pud_free() should be fine because of our folding check within > p4d/pud_present/none(). But that doesn't mean that it is correct not > to check for the folding inside p4d/pud_free(). At least, with this > test module we do now have a caller of p4d/pud_free() on potentially > folded entries, so instead of adding pxx_folded() checks to this > test module, we could add them to our p4d/pud_free() functions. > Any thoughts on this? Agreed, it seems better to do the check inside p4d/pud_free() functions.