From: Mike Rapoport <rppt@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Jann Horn <jannh@google.com>,
Ard Biesheuvel <ardb+git@google.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ryan Roberts <ryan.roberts@arm.com>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Liz Prucka <lizprucka@google.com>,
Seth Jenkins <sethjenkins@google.com>,
Kees Cook <kees@kernel.org>, David Hildenbrand <david@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH v4 02/15] mm: Make empty_zero_page __ro_after_init
Date: Wed, 13 May 2026 13:28:51 +0300 [thread overview]
Message-ID: <agRSY-VLLdSqeMT5@kernel.org> (raw)
In-Reply-To: <49d30ffe-b7e1-4b05-89e0-c3fe01348bb6@app.fastmail.com>
On Wed, May 13, 2026 at 10:53:08AM +0200, Ard Biesheuvel wrote:
>
> On Wed, 13 May 2026, at 10:50, Mike Rapoport wrote:
> > On Tue, May 12, 2026 at 02:56:16PM +0200, Ard Biesheuvel wrote:
> >> On Mon, 11 May 2026, at 16:40, Jann Horn wrote:
> >> > On Mon, May 11, 2026 at 10:59 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> >> >> I think we should simply do something along the lines of the below,
> >> >> considering that the size of a data object tends to correlate with
> >> >> its minimum alignment.
> >> >>
> >> >> I do find it rather puzzling that the compiler emits empty_zero_page
> >> >> *after* zero_page_pfn - ideally, we'd combine the below with
> >> >> -fdata-sections so that the linker sees all individual objects, but
> >> >> I suspect that would create some problems elsewhere.
> >> >>
> >> >>
> >> >> --- a/include/asm-generic/vmlinux.lds.h
> >> >> +++ b/include/asm-generic/vmlinux.lds.h
> >> >> @@ -452,7 +452,7 @@
> >> >> #define RO_AFTER_INIT_DATA \
> >> >> . = ALIGN(8); \
> >> >> __start_ro_after_init = .; \
> >> >> - *(.data..ro_after_init) \
> >> >> + *(SORT_BY_ALIGNMENT(.data..ro_after_init)) \
> >> >
> >> > Oh, neat, I didn't realize that's possible. That seems like a nicer
> >> > approach...
> >>
> >> Neat but rather ineffective, unfortunately. (I don't see a size
> >> difference with the arm64 defconfig kernel)
> >>
> >> Given that empty_zero_page only ever gets its address taken, we
> >> might just move it into the linker script if that requires tweaking
> >> anyway. We can just place it at the start of .rodata, which is
> >> already page aligned on most architectures (and will become page
> >> aligned unless EMPTY_ZERO_PAGE is #define'd by the arch linker
> >> script to something else)
> >>
> >>
> >> --- a/include/asm-generic/vmlinux.lds.h
> >> +++ b/include/asm-generic/vmlinux.lds.h
> >> @@ -472,6 +472,17 @@
> >> #endif
> >> #endif
> >>
> >> +#ifndef EMPTY_ZERO_PAGE
> >> +#ifndef __HAVE_COLOR_ZERO_PAGE
> >
> > I don't think we want let architectures that don't use colored zero pages
> > redefine it.
> > If it will be really required we can add the ability to redefine
> > EMPTY_ZERO_PAGE later.
> >
>
> I was actually intending to add use this for arm64 in the next patch. It
> already has a reserved_pg_dir in .rodata which is page-sized (i.e., up
> to 64k in size) and guaranteed to remain all zeroes, so empty_zero_page
> could actually be an alias for that. This is what I had in a previous
> revision, before you turned the empty_zero_page definition into common
> code:
Works for me if from arm64 perspective that's ok :)
> https://lore.kernel.org/all/20260320145934.2349881-16-ardb+git@google.com/
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2026-05-13 10:29 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-27 15:34 [PATCH v4 00/15] arm64: Unmap linear alias of kernel data/bss Ard Biesheuvel
2026-04-27 15:34 ` [PATCH v4 01/15] arm64: mm: Map the linear alias of text/rodata as tagged Ard Biesheuvel
2026-04-28 14:16 ` Kevin Brodsky
2026-04-28 16:23 ` Ard Biesheuvel
2026-04-29 7:57 ` Kevin Brodsky
2026-04-29 7:58 ` Ard Biesheuvel
2026-04-27 15:34 ` [PATCH v4 02/15] mm: Make empty_zero_page __ro_after_init Ard Biesheuvel
2026-04-28 12:27 ` Mike Rapoport
2026-04-28 14:16 ` Kevin Brodsky
2026-04-28 19:51 ` David Hildenbrand (Arm)
2026-05-09 11:04 ` Kiryl Shutsemau
2026-05-08 17:02 ` Jann Horn
2026-05-11 8:59 ` Ard Biesheuvel
2026-05-11 14:40 ` Jann Horn
2026-05-12 12:56 ` Ard Biesheuvel
2026-05-13 8:50 ` Mike Rapoport
2026-05-13 8:53 ` Ard Biesheuvel
2026-05-13 10:28 ` Mike Rapoport [this message]
2026-05-11 18:45 ` Kees Cook
2026-05-11 19:01 ` Jann Horn
2026-05-11 2:55 ` Feng Tang
2026-04-27 15:34 ` [PATCH v4 03/15] arm64: mm: Preserve existing table mappings when mapping DRAM Ard Biesheuvel
2026-04-27 15:34 ` [PATCH v4 04/15] arm64: mm: Preserve non-contiguous descriptors " Ard Biesheuvel
2026-04-27 15:34 ` [PATCH v4 05/15] arm64: mm: Remove bogus stop condition from map_mem() loop Ard Biesheuvel
2026-04-28 14:33 ` Kevin Brodsky
2026-04-27 15:34 ` [PATCH v4 06/15] arm64: mm: Drop redundant pgd_t* argument from map_mem() Ard Biesheuvel
2026-04-28 14:33 ` Kevin Brodsky
2026-04-27 15:34 ` [PATCH v4 07/15] arm64: mm: Permit contiguous descriptors to be rewritten Ard Biesheuvel
2026-04-27 15:34 ` [PATCH v4 08/15] arm64: kfence: Avoid NOMAP tricks when mapping the early pool Ard Biesheuvel
2026-04-27 15:34 ` [PATCH v4 09/15] arm64: mm: Permit contiguous attribute for preliminary mappings Ard Biesheuvel
2026-04-27 15:34 ` [PATCH v4 10/15] arm64: Move fixmap page tables to end of kernel image Ard Biesheuvel
2026-04-29 13:52 ` Kevin Brodsky
2026-04-27 15:34 ` [PATCH v4 11/15] arm64: mm: Don't abuse memblock NOMAP to check for overlaps Ard Biesheuvel
2026-04-29 10:54 ` Kevin Brodsky
2026-04-29 14:23 ` Ard Biesheuvel
2026-04-29 14:30 ` Kevin Brodsky
2026-04-27 15:34 ` [PATCH v4 12/15] arm64: mm: Map the kernel data/bss read-only in the linear map Ard Biesheuvel
2026-04-29 13:54 ` Kevin Brodsky
2026-04-29 14:46 ` Ard Biesheuvel
2026-05-04 8:50 ` Kevin Brodsky
2026-04-27 15:34 ` [PATCH v4 13/15] arm64: mm: Unmap kernel data/bss entirely from " Ard Biesheuvel
2026-04-29 13:55 ` Kevin Brodsky
2026-04-29 17:37 ` Ard Biesheuvel
2026-05-04 8:52 ` Kevin Brodsky
2026-04-27 15:34 ` [PATCH v4 14/15] arm64: mm: Generalize manipulation code of read-only descriptors Ard Biesheuvel
2026-04-29 13:57 ` Kevin Brodsky
2026-04-27 15:34 ` [PATCH v4 15/15] arm64: mm: Remap linear aliases of the fixmap page tables read-only Ard Biesheuvel
2026-04-29 13:57 ` Kevin Brodsky
2026-04-29 14:08 ` Ard Biesheuvel
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=agRSY-VLLdSqeMT5@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=ardb+git@google.com \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=david@kernel.org \
--cc=jannh@google.com \
--cc=kees@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizprucka@google.com \
--cc=mark.rutland@arm.com \
--cc=ryan.roberts@arm.com \
--cc=sethjenkins@google.com \
--cc=will@kernel.org \
/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.