[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 3/7] arm64: mm: fully support nested lazy_mmu sections


  • To: Kevin Brodsky <kevin.brodsky@xxxxxxx>
  • From: Yeoreum Yun <yeoreum.yun@xxxxxxx>
  • Date: Mon, 8 Sep 2025 10:30:29 +0100
  • Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=kvack.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MKTinqRY9lAauBy2OZ6xKaVx1KArO4xGTgKQBxwBbBU=; b=n8Eme9DMXzXHq+v6jprIkWaToz4ew0hGv4IOG/L9Z66Zp++jakaqXCM78jVq1M41wS8Ff0jKB4Vm5tEMg9MAg4ao45ex16wmWWGPlCFPMlvcE1R3DIM2AUhXBuDVqeJBvqBSQFnPM2QOTzdkgA8Y+K4s464Ybx0vDrUKua5aLigSdgr4xcxdSfyZ6HEL7StX72e0SpyvPOD7bXuNY8YRLkm3LVHu6Oaao87IWXvRyou/gOfMPGbUfYwV19fPiLEYBRPxVLxiThb+1AHyvbakpB/DV5K9UvBurus/F3rZAOrBauMvmvl6c49M5p3T+Snuol1pK6PBRBvqJgb8eU37HQ==
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MKTinqRY9lAauBy2OZ6xKaVx1KArO4xGTgKQBxwBbBU=; b=AV1nazIXpxD8dOmXWvBV9esB0nB9F8zbiw5TR1Fae0gD48znvAcKRq2qAJY00vCCR+hsRqn4vMip6Z+6QsNQy1IpAv2dNce9Gr+h4LPie1SMpzx8AHJ18eS6m+CuBiDg50ynT/TdVfGDYxVEO5D8h3IG+i4R5e2PPFaBztK7oaqTZuWkV9qA/q5o/l5MLJyg/NjQC72SWVy598pGSfW+EV1d8GoQt1dqtDjIo+o1GTw5RmS7QbGMBsLW4qhyunEu/67i8skJNQYpWpT/Ls2ANl0IxU8k/4AfWtlJTj2QYuop+trjV8GZUYeKZd2HvbsPEO4oKPCx6QFsnCpJW/l8Ig==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=PhoHYCGu+IVt8ylPivj9rNzrNKAGhdqmTANALmKCXAVAZXVGUgbubEQXajlethE5pwoC2QC3LNhqbVIud7rBskTWNQ8GCMuBgQMogo1PnO2o39bhp+3wRCfcpmmYi9MgYPEqOmQ6AIbyeE9DGkWZeTm7YYn/1IMHr0FTglczLvpgQTbYlqCV5Bs6jZMn4sE+6mss3YV7R+R86AMnoUXtx4tufCwvN1Jp/m06zrP3FIIf3BABT4GSiBCMk+5JSv1n+BxTIz5OgDsv4dY3ezqohxAdm5hRxMSXTHgj4mGZ0BifwCONBfi1sNRTr6/IjOrM1C1DyBHgHf9u2nxSBKV2Qw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JD6aR2JTcCSzlmcmkxP0JuYyrJKOmFes4KgPYG9jU+TtHX+5KZLWOXvcYFCNYPAjprpslWYb17vHW0JHSgx6nbEl/Tg0ar3ccarocg5ScFpyGajStJifvlClUHYRdxod2aqsmdzVGhUpzk65y6OFpXwXwPM8OpGUJIaLPdWNxpgDQbn7YBWOTWv7wVFUCLM2XvAkV3DZ2Fpbze8srmJ1gGrBjec7opGhkDjij5oLDc4QxvvSSRECmz9GLiLjFBd7TdhZfr97NDnYBXmGcjB5V9UVtedqKAjbi6km/qSjpPH3tIZx2BwTAqIsQChZneYDIDumL4pJ4ahmHNQK6ariRA==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: linux-mm@xxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, Alexander Gordeev <agordeev@xxxxxxxxxxxxx>, Andreas Larsson <andreas@xxxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, Borislav Petkov <bp@xxxxxxxxx>, Catalin Marinas <catalin.marinas@xxxxxxx>, Christophe Leroy <christophe.leroy@xxxxxxxxxx>, Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>, David Hildenbrand <david@xxxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Jann Horn <jannh@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, "Liam R. Howlett" <Liam.Howlett@xxxxxxxxxx>, Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx>, Madhavan Srinivasan <maddy@xxxxxxxxxxxxx>, Michael Ellerman <mpe@xxxxxxxxxxxxxx>, Michal Hocko <mhocko@xxxxxxxx>, Mike Rapoport <rppt@xxxxxxxxxx>, Nicholas Piggin <npiggin@xxxxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Ryan Roberts <ryan.roberts@xxxxxxx>, Suren Baghdasaryan <surenb@xxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Vlastimil Babka <vbabka@xxxxxxx>, Will Deacon <will@xxxxxxxxxx>, linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, linuxppc-dev@xxxxxxxxxxxxxxxx, sparclinux@xxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 08 Sep 2025 09:31:15 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true

Reviewed-by: Yeoreum Yun <yeoreum.yun@xxxxxxx>

On Mon, Sep 08, 2025 at 08:39:27AM +0100, Kevin Brodsky wrote:
> Despite recent efforts to prevent lazy_mmu sections from nesting, it
> remains difficult to ensure that it never occurs - and in fact it
> does occur on arm64 in certain situations (CONFIG_DEBUG_PAGEALLOC).
> Commit 1ef3095b1405 ("arm64/mm: Permit lazy_mmu_mode to be nested")
> made nesting tolerable on arm64, but without truly supporting it:
> the inner leave() call clears TIF_LAZY_MMU, disabling the batching
> optimisation before the outer section ends.
>
> Now that the lazy_mmu API allows enter() to pass through a state to
> the matching leave() call, we can actually support nesting. If
> enter() is called inside an active lazy_mmu section, TIF_LAZY_MMU
> will already be set, and we can then return LAZY_MMU_NESTED to
> instruct the matching leave() call not to clear TIF_LAZY_MMU.
>
> The only effect of this patch is to ensure that TIF_LAZY_MMU (and
> therefore the batching optimisation) remains set until the outermost
> lazy_mmu section ends. leave() still emits barriers if needed,
> regardless of the nesting level, as the caller may expect any
> page table changes to become visible when leave() returns.
>
> Signed-off-by: Kevin Brodsky <kevin.brodsky@xxxxxxx>
> ---
>  arch/arm64/include/asm/pgtable.h | 19 +++++--------------
>  1 file changed, 5 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/include/asm/pgtable.h 
> b/arch/arm64/include/asm/pgtable.h
> index 816197d08165..602feda97dc4 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -85,24 +85,14 @@ typedef int lazy_mmu_state_t;
>
>  static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
>  {
> -     /*
> -      * lazy_mmu_mode is not supposed to permit nesting. But in practice this
> -      * does happen with CONFIG_DEBUG_PAGEALLOC, where a page allocation
> -      * inside a lazy_mmu_mode section (such as zap_pte_range()) will change
> -      * permissions on the linear map with apply_to_page_range(), which
> -      * re-enters lazy_mmu_mode. So we tolerate nesting in our
> -      * implementation. The first call to arch_leave_lazy_mmu_mode() will
> -      * flush and clear the flag such that the remainder of the work in the
> -      * outer nest behaves as if outside of lazy mmu mode. This is safe and
> -      * keeps tracking simple.
> -      */
> +     int lazy_mmu_nested;
>
>       if (in_interrupt())
>               return LAZY_MMU_DEFAULT;
>
> -     set_thread_flag(TIF_LAZY_MMU);
> +     lazy_mmu_nested = test_and_set_thread_flag(TIF_LAZY_MMU);
>
> -     return LAZY_MMU_DEFAULT;
> +     return lazy_mmu_nested ? LAZY_MMU_NESTED : LAZY_MMU_DEFAULT;
>  }
>
>  static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
> @@ -113,7 +103,8 @@ static inline void 
> arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
>       if (test_and_clear_thread_flag(TIF_LAZY_MMU_PENDING))
>               emit_pte_barriers();
>
> -     clear_thread_flag(TIF_LAZY_MMU);
> +     if (state != LAZY_MMU_NESTED)
> +             clear_thread_flag(TIF_LAZY_MMU);
>  }
>
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> --
> 2.47.0
>

--
Sincerely,
Yeoreum Yun



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.