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 AC990C433F5 for ; Tue, 23 Nov 2021 09:58:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 263846B0071; Tue, 23 Nov 2021 04:58:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 213086B0072; Tue, 23 Nov 2021 04:58:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 12A386B0073; Tue, 23 Nov 2021 04:58:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0200.hostedemail.com [216.40.44.200]) by kanga.kvack.org (Postfix) with ESMTP id 0798D6B0071 for ; Tue, 23 Nov 2021 04:58:14 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id B6D7E8912C for ; Tue, 23 Nov 2021 09:58:03 +0000 (UTC) X-FDA: 78839744046.22.866372F Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf25.hostedemail.com (Postfix) with ESMTP id B2D48B000E0B for ; Tue, 23 Nov 2021 09:58:00 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 42B2F61057 for ; Tue, 23 Nov 2021 09:58:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1637661482; bh=c2af4cD82ZvlTLcEtFj3WN6w9IAHd0AVMeQM3gBpzWY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=KhB9zgBoY3dmtZR935W/ITrcH9pIB5gJwopsE2S7wAw73csvtucfJKOaKi8nEfqRA uR6WkaUYKWgCU0TtkYWiVJUhSyA+lOJiIWuIQBrh9Tz79Dk5NAgFGtL/ULwxJVHNuz f8ig5ftJp9Mapie97yPIcRg99MaJwmAgd5u695ByLrUJ3vjEWasQYwjaZ99cl5L5UU /OZ5T75ZXpcTSY8gMZQViqEUIvYJWVNFN8AtI1cZxUpk/cLf4Pz+B1yyxgLKSpC2rb IuIAYheemRZuCGiUyAFe2x5rPMxGwR96xOYa7f/zunzW0gcbQBHI83tyQF8zK5Z/Po zUB2eNxf0eH1A== Received: by mail-ot1-f50.google.com with SMTP id w6-20020a9d77c6000000b0055e804fa524so32976981otl.3 for ; Tue, 23 Nov 2021 01:58:02 -0800 (PST) X-Gm-Message-State: AOAM533Ys5kb9D7rAFqaFlzEs3ryR860AB3NxPSZuUGFeTdL7Nrfgg6h do3lsb1sga06NhmKTVbTosOPGqD21NuNKzmEGoQ= X-Google-Smtp-Source: ABdhPJx/bR0UUrC75aFHTkOtBjjnustA215aKRj+dEMm+J+VaQwZu36SrrjAOxDGbtWuBoOU8cT/kuqaPS1nnmMm+/s= X-Received: by 2002:a05:6830:1514:: with SMTP id k20mr3024125otp.147.1637661481511; Tue, 23 Nov 2021 01:58:01 -0800 (PST) MIME-Version: 1.0 References: <1637658760-5813-1-git-send-email-huangzhaoyang@gmail.com> In-Reply-To: <1637658760-5813-1-git-send-email-huangzhaoyang@gmail.com> From: Ard Biesheuvel Date: Tue, 23 Nov 2021 10:57:50 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH] mm: introduce alloc hook to apply PTE_CONT To: Huangzhaoyang Cc: Catalin Marinas , Will Deacon , Anshuman Khandual , Andrew Morton , Nicholas Piggin , Mike Rapoport , Pavel Tatashin , Christophe Leroy , Jonathan Marek , Zhaoyang Huang , Linux Memory Management List , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: B2D48B000E0B X-Stat-Signature: mun6hionyogt7g4874nb4zknjpyyx7eo Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=KhB9zgBo; spf=pass (imf25.hostedemail.com: domain of ardb@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-HE-Tag: 1637661480-699715 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 Tue, 23 Nov 2021 at 10:13, Huangzhaoyang wrote: > > From: Zhaoyang Huang > > Since there is no PTE_CONT when rodata_full in ARM64, introducing a > hook function to apply PTE_CONT on the proper page blocks. > Given the discussion around your previous patch, I would expect a meticulous explanation here why it is guaranteed to be safe to manipulate the PTE_CONT attribute like this, and how the proposed logic is correct for all supported page sizes. Without using an intermediate invalid mapping for the entire range, this is never going to work reliably (this is the break-before-make requirement). And given that marking the entire block invalid will create intermediate states that are not permitted (a valid PTE_CONT mapping and an invalid ~PTE_CONT mapping covering the same VA), the only way to apply changes like these is to temporarily switch all CPUs to a different translation via TTBR1. And this is not going to happen. Also, you never replied to my question regarding the use case and the performance gain. In summary, NAK to this patch or any of the previous ones regarding PTE_CONT. If you do insist on pursuing this further, please provide an elaborate and rock solid explanation why your approach is 100% valid and correct (for all page sizes). And make sure you include an explanation how your changes comply with the architectural break-before-make requirements around PTE_CONT attributes. > --- > arch/arm64/include/asm/page.h | 5 +++++ > arch/arm64/mm/pageattr.c | 45 +++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 50 insertions(+) > > diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h > index f98c91b..53cdd09 100644 > --- a/arch/arm64/include/asm/page.h > +++ b/arch/arm64/include/asm/page.h > @@ -46,6 +46,11 @@ struct page *alloc_zeroed_user_highpage_movable(struct vm_area_struct *vma, > > #include > > +#define HAVE_ARCH_ALLOC_PAGE > +#define HAVE_ARCH_FREE_PAGE > + > +extern void arch_alloc_page(struct page *page, int order); > +extern void arch_free_page(struct page *page, int order); > #endif /* !__ASSEMBLY__ */ > > #define VM_DATA_DEFAULT_FLAGS (VM_DATA_FLAGS_TSK_EXEC | VM_MTE_ALLOWED) > diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c > index a3bacd7..815a06d 100644 > --- a/arch/arm64/mm/pageattr.c > +++ b/arch/arm64/mm/pageattr.c > @@ -239,3 +239,48 @@ bool kernel_page_present(struct page *page) > ptep = pte_offset_kernel(pmdp, addr); > return pte_valid(READ_ONCE(*ptep)); > } > + > +void arch_alloc_page(struct page *page, int order) > +{ > + unsigned long addr; > + unsigned long cont_pte_low_bound; > + > + if (!rodata_full) > + return; > + > + addr = (u64)page_address(page); > + if ((order >= 4) && (addr & ~CONT_PTE_MASK) == 0) { > + order -= 4; > + do { > + cont_pte_low_bound = addr & CONT_PTE_MASK; > + __change_memory_common(cont_pte_low_bound, > + (~CONT_PTE_MASK + 1), __pgprot(PTE_CONT), __pgprot(0)); > + addr = (u64)page_address(page); > + page += 4; > + order--; > + }while (order >= 0); > + } > +} > + > +void arch_free_page(struct page *page, int order) > +{ > + unsigned long addr; > + unsigned long cont_pte_low_bound; > + > + if (!rodata_full) > + return; > + > + addr = (u64)page_address(page); > + if ((order >= 4) && (addr & ~CONT_PTE_MASK) == 0) { > + order -= 4; > + do { > + cont_pte_low_bound = addr & CONT_PTE_MASK; > + __change_memory_common(cont_pte_low_bound, > + (~CONT_PTE_MASK + 1), __pgprot(0), __pgprot(PTE_CONT)); > + addr = (u64)page_address(page); > + page += 4; > + order--; > + }while (order >= 0); > + } > +} > + > -- > 1.9.1 >