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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 887F7E7718C for ; Fri, 20 Dec 2024 13:50:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0E0996B0085; Fri, 20 Dec 2024 08:50:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 091CD6B0088; Fri, 20 Dec 2024 08:50:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EC19C6B0089; Fri, 20 Dec 2024 08:50:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id CAE816B0085 for ; Fri, 20 Dec 2024 08:50:28 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5AE71140A23 for ; Fri, 20 Dec 2024 13:50:28 +0000 (UTC) X-FDA: 82915471128.22.7D79412 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf07.hostedemail.com (Postfix) with ESMTP id 75E4740012 for ; Fri, 20 Dec 2024 13:49:33 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf07.hostedemail.com: domain of kevin.brodsky@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=kevin.brodsky@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734702610; a=rsa-sha256; cv=none; b=TaWZu0tgpROu/DIYd4HcFCMaevK4HTVxxxb1n8zx+/0Ivuk/TTnvhCv/jjGnjlcjgk5dXc 51VSDZim6tMaI2miJJhvC2nFVtpJTA8iYbeHr2dfGlJNkjoR8jyuC+NBWZi+USsbfyOT1O lmEOAuIyRnC/HylelxX5nAebM/UPCK8= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf07.hostedemail.com: domain of kevin.brodsky@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=kevin.brodsky@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734702610; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tOIKmNQEMGn9hjJIR0rcaMsoO1iRnTK3X02bB4ePQuA=; b=t9dqbBZe5qatGQRbJcEDFkyNfSCyfU6D3JGerdlDwDm63+zUAzBVnjqxNajLCmyd65UDk3 XItuw6Mbrt2yO/frLTiYvhUDm2P05xhOD5qyIqPndMnvQuS5tLaWj50UyF+hmqQ34UPbtm S5EgC4cKDm/J7mOz8XM9Dl1BaCXZ+tQ= 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 4E7851480; Fri, 20 Dec 2024 05:50:53 -0800 (PST) Received: from [10.57.72.191] (unknown [10.57.72.191]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BF2793F720; Fri, 20 Dec 2024 05:50:19 -0800 (PST) Message-ID: <2f65f93e-9d44-4acc-b63c-8f5a35f59699@arm.com> Date: Fri, 20 Dec 2024 14:50:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 01/10] mm: Move common parts of pagetable_*_[cd]tor to helpers To: Qi Zheng Cc: Peter Zijlstra , linux-mm@kvack.org, Andrew Morton , Catalin Marinas , Dave Hansen , Linus Walleij , Andy Lutomirski , "Mike Rapoport (IBM)" , Ryan Roberts , Thomas Gleixner , Will Deacon , Matthew Wilcox , linux-alpha@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org, linux-hexagon@vger.kernel.org, linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-openrisc@vger.kernel.org, linux-parisc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-um@lists.infradead.org, loongarch@lists.linux.dev, x86@kernel.org, Alexander Gordeev References: <20241219164425.2277022-1-kevin.brodsky@arm.com> <20241219164425.2277022-2-kevin.brodsky@arm.com> <20241219171920.GB26279@noisy.programming.kicks-ass.net> <75cb4ff8-eb0c-4519-a30a-f8be717ba278@arm.com> <0daabd32-cba4-4345-baa8-e8c66bc899ff@bytedance.com> Content-Language: en-GB From: Kevin Brodsky In-Reply-To: <0daabd32-cba4-4345-baa8-e8c66bc899ff@bytedance.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 75E4740012 X-Stat-Signature: dt3n6pws4z6r8hf1wh6h3x45dubfxzme X-HE-Tag: 1734702573-759576 X-HE-Meta: U2FsdGVkX1/HntaI2pJQPWFz/zmJ0HEVPYmlw5xok/MZZsJHDrGbyY3YV2CjjHrNJrNtF6H7oglLGH+4NXuzVEn263749TrB7m4uu4ednKhqusOb9VlUGksc9P+61zhMUUw5UliC3e7Ej6ab/9/nM8UgRTnefRiD4SJdBTcsBst549gOyLogPC6bwo2QHPQkGLQAl9329IEqw2M0dUYgAyHozUEDLS/1D6glAplny5jcA4PXhZEG79XMAUU4XuoaHqSImikZGJpafD9MCfnCBsqzoSgw1MJ+Bgg9FmqokK5FpbourMab4zLeP2lxFeLpLLqwGsWA7rUQDmCJoerrv3txd3CL0tqXUjlSI3y1Rq7JPnlK9ajHQXxlQc4IYxufyaSzcVlx6eg6oc4x/Sc3jKjhHdZw1TMWc1+EznDttK+06kca7OaJ91+C+XnU9SbpOdr5FO6KaClSu3l0kT9FhhFeDnn0KAKNuF6Y2V6EmHtiw/tfT+o5bnCzEHx1nGOclYtig4mIELml6n7Bx8ayZFQUonPlgBRcNVJKHQ3hMOwSTzCl6zuFNaazNrZ0AKqQC95qE2ehmvcUFWKHgmeG9tCV9BFMgBm0JMmilNM+vL5ha1/gr9VG0u1I4SVSMTtQ53z1jzlHebHqExrjR5eRVSrl8uLlijvDeqeffvHO3cvGIOHjakiwaAVoWX2UKKexmnj/fLUwJG2p5N6acd9J6dSi3u++TkIvQthSLBOGh99aIASSR2XR0bunZbYEZNhTS584gEve6gj9vN8A0U6hQsDGTdzBzbUYVZ8jSY7P5WE/kSj84uwatTcnhF/L4HXsmBpGlezu3KnCfKobzsPIZKh7RHa1kMjXbcmqWQhvVcWbWQsxDzI2uKg1Mg8VDER14PUfi+VWCLQzp+ShHJmP7E+Qu7R9fRZbBHy5dOnespa18JdyBDEjP3h6QnEBtwuI1t/iVzOJyQlQloDiU5F xUtAsyKL 4GLQJOkCYomWBIS1c48R7NhOgBYMMyo63Knlc99KWd1yode1JkXscLRUQHR38xmHKZ7YZVG/fKnupIDaZrma57uNkBl3RbBFfLmqat6JWlroLXSIqzi3Opwy4PpoZqk82k72XsCPndyaOHeS1gZbRJG3+t/SbyO0DDT01ohpi7i2+ulBLJQQ1WGSuOaWg/cEM17Of2mVJGWCY7rOZM/VJ5ntZ64/uvnoheJ8eQOFXwxkXCdO8/FAQkotfaWBlLsw/QSByT/vXQriMQ1l+5bUgi7jwNqASRGxinnAn6+R/8akigimeyDHMGbA/GJUHBpjFjF+Q81ZRg+9jTn4oSILtyFfgoTt43xObaVt1dMShAumMdKx5BL4FQ7csQoxyrPeM+RWD 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: List-Subscribe: List-Unsubscribe: On 20/12/2024 12:46, Qi Zheng wrote: > Hi Kevin, > > On 2024/12/20 18:49, Kevin Brodsky wrote: >> [...] >> >> Qi, shall we collaborate to make our series complementary? I believe my >> series covers patch 2 and 4 of your series, but it goes further by >> covering all levels and all architectures, and patches introducing >> ctor/dtor are already split as Alexander suggested on your series. So my >> suggestion would be: >> >> * Remove patch 1 in my series - I'd just introduce >> pagetable_{p4d,pgd}_[cd]tor with the same implementation as >> pagetable_pud_[cd]tor. >> * Remove patch 2 and 4 from your series and rebase it on mine. > > I quickly went through your patch series. It looks like my patch 2 and > your patch 6 are duplicated, so you want me to remove my patch 2. > > But I think you may not be able to simple let arm64, riscv and x86 to > use generic p4d_{alloc_one,free}(). Because even if > CONFIG_PGTABLE_LEVELS > 4, the pgtable_l5_enabled() may not be true. > > For example, in arm64: > > #if CONFIG_PGTABLE_LEVELS > 4 > > static __always_inline bool pgtable_l5_enabled(void) > { >     if (!alternative_has_cap_likely(ARM64_ALWAYS_BOOT)) >         return vabits_actual == VA_BITS; >     return alternative_has_cap_unlikely(ARM64_HAS_VA52); > } Correct. That's why the implementation of p4d_free() I introduce in patch 6 checks mm_p4d_folded(), which is implemented as !pgtable_l5_enabled() on those architectures (see last paragraph in commit message). In fact it turns out Alexander suggested exactly this approach [2]. > > Did I miss something? > > My patch series is not only for cleanup, but also for fixes of > UAF issue [1], so is it possible to rebase your patch series onto > mine? I can post v3 ASAP. I see, yours should be merged first then. The issue is that yours would depend on some of the patches in mine, not the other way round. My suggestion would then be for you to take patch 5, 6 and 7 from my series, as they match Alexander's suggestions (and patch 5 is I think a useful simplification), and replace patch 2 in your series with those. I would then rebase my series on top and adapt it accordingly. Does that sound reasonable? - Kevin [2] https://lore.kernel.org/all/Z2RKpdv7pL34MIEt@tuxmaker.boeblingen.de.ibm.com/