From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-189.mta0.migadu.com (out-189.mta0.migadu.com [91.218.175.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 018113DB992 for ; Thu, 11 Jun 2026 11:58:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.189 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781179120; cv=none; b=gZaI58m5CSPPBdy3bTGTDhhc+sX9VDKBnHMO7UqQJY/Iv6gDeivm22EXPLAbydawBzZgE4cNdqPALmsZuxFKvnhXFkBuuDayH+Tj+2oXkaqzQ8V1M9OLs+XzjvrIGmInwP2a0a5tDRV4MSgOdMXvgM6IvSGWJqt6dM4GbWJlZuk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781179120; c=relaxed/simple; bh=dZL8AAh/0DGauukHECo/2s2ae3DZH63glezQHdUDSaI=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=qGbWx8zT5faG7qRBvtTvuGRPq3SGzIf+n46qzxuhxlOEdkXfyu82z4OnLJWXuXshyfO1rSGrkvPStrkZCIBgD7ftTJ2xqKLEdnn04Tts+KJeJ5BlvO4RDPR284vQwaGO0gEFO5uK0Q4aBvYQjbeBLuoaqsmhu6rlDTGn6ZIkLaE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=iIHiRXWY; arc=none smtp.client-ip=91.218.175.189 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="iIHiRXWY" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1781179115; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cRjngGChT72OdyfI+6mmhcUVkfKxErUrhBdzRmYMjJY=; b=iIHiRXWYOhkM76qqJ9NisfEY53PmcKcHbWDyAMpH5wWbBTNYdSqIzaeRLlrN4krVp50OP2 755dQym1KT2Pw5aIBAYR1d/urcLO1QWd316sODKCu21CC2S6CM6GD4YRL+g7+XaZ1/bl1X 7ykplj8gDBkU3rW5EXse1dcgY0A8G1E= From: Lance Yang To: david@kernel.org Cc: lance.yang@linux.dev, akpm@linux-foundation.org, xueyuan.chen21@gmail.com, 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, luto@kernel.org, peterz@infradead.org, hpa@zytor.com, ljs@kernel.org, liam@infradead.org, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, ziy@nvidia.com, baolin.wang@linux.alibaba.com, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, yang@os.amperecomputing.com, jannh@google.com, dave.hansen@intel.com Subject: Re: [RFC PATCH v2 1/3] mm/huge_memory: make persistent huge zero folio read-only Date: Thu, 11 Jun 2026 19:58:17 +0800 Message-Id: <20260611115817.59353-1-lance.yang@linux.dev> In-Reply-To: <8c36a91d-288f-4ffb-b2ec-41e3ef789d72@kernel.org> References: <8c36a91d-288f-4ffb-b2ec-41e3ef789d72@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On Thu, Jun 11, 2026 at 01:28:58PM +0200, David Hildenbrand (Arm) wrote: >On 6/10/26 04:15, Lance Yang wrote: >> >> On Tue, Jun 09, 2026 at 12:45:49PM -0700, Andrew Morton wrote: >>> On Tue, 9 Jun 2026 22:37:59 +0800 Xueyuan Chen wrote: >>> >>>> The huge zero folio is shared globally, and its contents should never >>>> change after initialization. As Jann Horn pointed out[1], the kernel has >>>> had bugs, including security bugs, where read-only pages were later written >>>> to. If the persistent huge zero folio is read-only in the direct map, such >>>> writes fault instead of silently corrupting the shared zero contents. >>>> >>>> Add arch_make_pages_readonly() so mm code can request read-only direct-map >>>> protection for a page range. Direct-map protection is >>>> architecture-specific, so the generic weak implementation does nothing. >>>> >>>> This was inspired by Jann Horn's read-only zero page work[1] and follow-up >>>> discussion[2] with Yang Shi. >>>> >>>> [1] https://lore.kernel.org/linux-mm/20260508-ro-zeropage-v1-1-9808abc20b49@google.com/ >>>> [2] https://lore.kernel.org/linux-mm/CAHbLzkrXXe7r3n3jXgDKtwZhRqj=jDx9E6dLOULohnhBguvi9A@mail.gmail.com/ >>>> >>>> ... >>>> >>>> --- a/mm/huge_memory.c >>>> +++ b/mm/huge_memory.c >>>> @@ -308,6 +308,11 @@ static unsigned long shrink_huge_zero_folio_scan(struct shrinker *shrink, >>>> return 0; >>>> } >>>> >>>> +bool __weak arch_make_pages_readonly(struct page *page, int nr_pages) >>>> +{ >>>> + return false; >>>> +} >>>> + >>>> static struct shrinker *huge_zero_folio_shrinker; >>>> >>>> #ifdef CONFIG_SYSFS >>>> @@ -982,8 +987,14 @@ static int __init thp_shrinker_init(void) >>>> * that get_huge_zero_folio() will most likely not fail as >>>> * thp_shrinker_init() is invoked early on during boot. >>>> */ >>>> - if (!get_huge_zero_folio()) >>>> + if (!get_huge_zero_folio()) { >>>> pr_warn("Allocating persistent huge zero folio failed\n"); >>>> + return 0; >>>> + } >>>> + >>>> + arch_make_pages_readonly(folio_page(huge_zero_folio, 0), >>>> + HPAGE_PMD_NR); >>> >>> Can it simply pass the folio? >> >> Right, this came from the RFC v1 discussion[1]. David preferred a page- >> range helper for possible future non-folio callers, not something folio- >> only. >> >> Of course, we could also add a folio wrapper on top of that if needed :) > >Best to document that as part of the patch description: we don't really expect >to have a lot of read-only folios in the near future (zero page is rather >special; maybe it won't even be a folio in the future). Ah, good to know, thanks. Will spell that out in RFC v3. Maybe something like this? The huge zero page is pretty special case, and maybe it won't even be a folio in the future. Since read-only folios are unlikely to become a common thing, a page-range helper is the cleaner fit.