On Sun, Jan 04, 2026 at 08:56:45PM +0000, Russell King (Oracle) wrote: > On Sun, Jan 04, 2026 at 02:01:40PM +0200, Mike Rapoport wrote: > > From 35d016bbf5da7c08cc5c5547c85558fc50cb63aa Mon Sep 17 00:00:00 2001 > > From: Klara Modin <[email protected]> > > Date: Sat, 3 Jan 2026 20:40:09 +0200 > > Subject: [PATCH] arm: make initialization of zero page independent of the > > memory map > > > > Unlike most architectures, arm keeps a struct page pointer to the > > empty_zero_page and to initialize it requires conversion of a virtual > > address to page which makes it necessary to have memory map initialized > > before creating the empty_zero_page. > > > > Make empty_zero_page a stataic array in BSS to decouple it's > > initialization from the initialization of the memory map. > > I see you haven't considered _why_ ARM does this. > > You are getting rid of the flush_dcache_page() call, which ensures > that the zeroed contents of the page are pushed out of the cache > into memory. This is necessary. > > BSS is very similar. It's memset() during the kernel boot _after_ > the caches are enabled. Without an explicit flush, nothing > guarantees that those writes will be visible to userspace.
There's a call to flush_cache_all() paging_init()->devicemaps_init() that will guarantee that those writes are flushed long before userspace starts. > To me, this seems like a bad idea, which will cause userspace to > break. > > We need to call flush_dcache_page(), and _that_ requires a struct > page. Right now there's __flush_dcache_folio() that will break anyway when folio divorces from struct page. -- Sincerely yours, Mike.
