From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-170.mta1.migadu.com (out-170.mta1.migadu.com [95.215.58.170]) (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 E48C018A92F for ; Wed, 10 Jun 2026 02:15:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781057749; cv=none; b=Ah+TXCaAeZs6ARH0QLHLsdMuW9TQ2++BUa5fJJQIGNWlEdnALyRP+5aF8qiGyjw+Vesdu5azqkzA3R4xkb65eEz+wPnpv9ZKVxIAzPIqd3neeeI30VLGBUcgTp0T2TlBh7e4CepwOW/6TC9zw1Vvt8h9SwX/8sCTmHc31ezU8f0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781057749; c=relaxed/simple; bh=RlK9d+UO2bleGlQtMvDHodu0EQEH9hazleY+G/Op3bA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=Uck7ncweLtte/QRM3qVgI1d17b0w3adsc4GMR1PFz3IZRKNADSJGsPt3x7yOgjjXN4y/bugGQkaYNu6jK8QySCtcTitzmJ9yiY8Bm+nboV8KsaZBhet1LyvSjVPz+SjZjagQooySSvi4e5tB7ZLD6tJngvj1983Ml++2/tT/5T0= 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=D6ijSBnP; arc=none smtp.client-ip=95.215.58.170 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="D6ijSBnP" 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=1781057722; 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=sUscgkaVB9GhkTyYmcNNOPyIpn4q5HzwEqwgoYRL1cI=; b=D6ijSBnPu590JadANQn6yWI4D34v3+8oS/4hsrM+AztYMR9ELQesm+n+bMbpuT5UnnPVdP 3Sm7CUM7F7pRDF+SZFmKWng6A/cUb4qDR+aUBv6agV1CvTEsE1Q0M3wyCDU3CXHWnk0aUn MwSKL8vK12126gyL1mz8G54ZZJd+g4c= From: Lance Yang To: akpm@linux-foundation.org Cc: 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, david@kernel.org, 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, lance.yang@linux.dev, 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: Wed, 10 Jun 2026 10:15:07 +0800 Message-Id: <20260610021508.46000-1-lance.yang@linux.dev> In-Reply-To: <20260609124549.aff7e774603c4af188009408@linux-foundation.org> References: <20260609124549.aff7e774603c4af188009408@linux-foundation.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 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 :) [1] https://lore.kernel.org/linux-mm/929875a2-9e94-4dbc-9c98-b342ccc3f4e2@kernel.org/ Thanks, Lance