linux-kernel - Re: [PATCH v2 0/6] mm/arm64: re-enable HVO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20241125152203.GA954@willie-the-truck>
Date: Mon, 25 Nov 2024 15:22:03 +0000
From: Will Deacon <will@...nel.org>
To: Yu Zhao <yuzhao@...gle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Marc Zyngier <maz@...nel.org>, Muchun Song <muchun.song@...ux.dev>,
	Thomas Gleixner <tglx@...utronix.de>,
	Douglas Anderson <dianders@...omium.org>,
	Mark Rutland <mark.rutland@....com>,
	Nanyong Sun <sunnanyong@...wei.com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [PATCH v2 0/6] mm/arm64: re-enable HVO

Hi Yu Zhao,

On Thu, Nov 07, 2024 at 01:20:27PM -0700, Yu Zhao wrote:
> HVO was disabled by commit 060a2c92d1b6 ("arm64: mm: hugetlb: Disable
> HUGETLB_PAGE_OPTIMIZE_VMEMMAP") due to the following reason:
> 
>   This is deemed UNPREDICTABLE by the Arm architecture without a
>   break-before-make sequence (make the PTE invalid, TLBI, write the
>   new valid PTE). However, such sequence is not possible since the
>   vmemmap may be concurrently accessed by the kernel.
> 
> This series presents one of the previously discussed approaches to
> re-enable HugeTLB Vmemmap Optimization (HVO) on arm64.

Before jumping into the new mechanisms here, I'd really like to
understand how the current code is intended to work in the relatively
simple case where the vmemmap is page-mapped to start with (i.e. when we
don't need to worry about block-splitting).

In that case, who are the concurrent users of the vmemmap that we need
to worry about? Is it solely speculative references via
page_ref_add_unless() or are there others?

Looking at page_ref_add_unless(), what serialises that against
__hugetlb_vmemmap_restore_folio()? I see there's a synchronize_rcu()
call in the latter, but what prevents an RCU reader coming in
immediately after that?

Even if we resolve the BBM issues, we still need to get the
synchronisation right so that we don't e.g. attempt a cmpxchg() to a
read-only mapping, as the CAS instruction requires write permission on
arm64 even if the comparison ultimately fails.

So please help me to understand the basics of HVO before we get bogged
down by the block-splitting on arm64.

Cheers,

Will