All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lance Yang <lance.yang@linux.dev>
To: yang@os.amperecomputing.com, dave.hansen@intel.com, jannh@google.com
Cc: xueyuan.chen21@gmail.com, akpm@linux-foundation.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, x86@kernel.org,
	catalin.marinas@arm.com, will@kernel.org, tglx@kernel.org,
	mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
	hpa@zytor.com, david@kernel.org, ljs@kernel.org, ziy@nvidia.com,
	baolin.wang@linux.alibaba.com, ryan.roberts@arm.com,
	dev.jain@arm.com, lance.yang@linux.dev
Subject: Re: [RFC PATCH 1/3] mm: make persistent huge zero folio read-only
Date: Fri, 29 May 2026 11:09:15 +0800	[thread overview]
Message-ID: <20260529030915.37767-1-lance.yang@linux.dev> (raw)
In-Reply-To: <c0f9a811-0286-4e1c-8790-8e31d95e5819@os.amperecomputing.com>


On Thu, May 28, 2026 at 11:43:40AM -0700, Yang Shi wrote:
>
>
>On 5/27/26 9:20 AM, Jann Horn wrote:
>> On Wed, May 27, 2026 at 5:55 PM Dave Hansen <dave.hansen@intel.com> wrote:
>>> On 5/26/26 20:56, Xueyuan chen wrote:
>>>> +config READONLY_HUGE_ZERO_FOLIO
>>>> +     bool "Map the huge zero folio read-only in the direct map"
>>>> +     depends on PERSISTENT_HUGE_ZERO_FOLIO
>>>> +     depends on ARCH_HAS_READONLY_HUGE_ZERO_FOLIO
>>>> +     help
>>>> +       The persistent huge zero folio is shared globally, and nothing
>>>> +       should ever change its contents after initialization.
>>>> +
>>>> +       When supported, mark the folio read-only in the direct map so such
>>>> +       writes trigger a fault instead of silently corrupting the zero contents.
>>>> +
>>>> +       If the permission change is not supported, the kernel keeps using
>>>> +       the writable persistent huge zero folio.
>>> I vote for no Kconfig options here. Why? This adds "security" with
>>> _basically_ no extra runtime cost. The runtime cost is, what, usually
>>> one kernel TLB invalidation during boot?
>> Plus potentially a bit more TLB pressure from losing a huge PUD in the
>> linear map, IDK how much we care about that.
>
>This shouldn't be a big issue on ARM64. The most ARM64 machines have 
>linear mapping mapped with PTE if rodata is on. Some machines with 
>BBML2_NOABORT support have linear mapping mapped with PUD/PMD, but those 
>machines typically have large memory, having 512 PMDs instead of 1 PUD 
>shouldn't be a noticeable issue IMHO.

Cool! Thanks Dave, Jann, Yang!

Yeah, that sounds reasonable. No need for another Kconfig option here;
one less knob for people to care about :D

For arm64, I think Yang has it:

1) Without BBML2_NOABORT, rodata=on already forces the linear map down
to PTEs, so nothing really changes there for most machines.

2) With BBML2_NOABORT, this may cost us 512 PMDs instead of one PUD for
that. I don't expect that to be noticeable either ;)

So let's drop the option in the next version.

Cheers, Lance


  reply	other threads:[~2026-05-29  3:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-27  3:56 [RFC PATCH 0/3] make persistent huge zero folio read-only Xueyuan chen
2026-05-27  3:56 ` [RFC PATCH 1/3] mm: " Xueyuan chen
2026-05-27 13:32   ` Dev Jain
2026-05-27 23:03     ` Xueyuan Chen
2026-05-27 15:55   ` Dave Hansen
2026-05-27 16:20     ` Jann Horn
2026-05-28 18:43       ` Yang Shi
2026-05-29  3:09         ` Lance Yang [this message]
2026-06-01 13:49     ` David Hildenbrand (Arm)
2026-06-01 15:43       ` Lance Yang
2026-06-01 15:46         ` David Hildenbrand (Arm)
2026-05-27  3:56 ` [RFC PATCH 2/3] arm64/mm: make huge zero folio read-only in linear map Xueyuan chen
2026-05-27  3:56 ` [RFC PATCH 3/3] x86/mm: make huge zero folio read-only in direct map Xueyuan chen
2026-05-27 15:58 ` [RFC PATCH 0/3] make persistent huge zero folio read-only Dave Hansen
2026-05-30  7:46   ` Lance Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260529030915.37767-1-lance.yang@linux.dev \
    --to=lance.yang@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@kernel.org \
    --cc=dev.jain@arm.com \
    --cc=hpa@zytor.com \
    --cc=jannh@google.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mingo@redhat.com \
    --cc=ryan.roberts@arm.com \
    --cc=tglx@kernel.org \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=xueyuan.chen21@gmail.com \
    --cc=yang@os.amperecomputing.com \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.