From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-183.mta1.migadu.com (out-183.mta1.migadu.com [95.215.58.183]) (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 4CDA8346E51 for ; Fri, 29 May 2026 03:09:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.183 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780024181; cv=none; b=WL/xjPIxbrdNrb8GLEgwTPua95WrwSnFGuHtQKBROMl4f7dGPNCnUr/pg9PXDcKhpvOLxJoUFTJA0pxjOoacYprzzASUoymF24icpmS8p0unK/qTMrdSsFx1Y5yiUuUUD5xOqeKqGxBRz01B5CZ6lSY0HSW/qqks+rLCDain34s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780024181; c=relaxed/simple; bh=tHhE4fAqZmaDXk88JghFFGHIfwZJ1fiIsfLco3BETO0=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=lJ00IB4kvD+fbptr56EjdFUGcztK+tT51t6xDKnwYQB9sWZoZ/YaWrsrOr0JgsNwsPGuik37o5FKUmi8aEbOZeadd8DG23TpYCUxxOu4D2wD2ZLkoSAw12FUT1h/ndneSKERnE839Dtzi1Z9JlMG+d1RQZUf0L2pFYfhm6f1t5U= 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=rPW2L/Aw; arc=none smtp.client-ip=95.215.58.183 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="rPW2L/Aw" 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=1780024177; 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=TK0Ooz++M6ADTeqrK3RvYBVcHOibgpzwEbnFPIpXtyg=; b=rPW2L/AwIYHoiWPp2eOwE0adHHwnFnOKbGhcWqGIMYN5aqkat2mrGz4RqBT4mgPHOoKR/b ZlE0dx4rkYNhcztLXz5+G/x9mfCdx/BjU9xVDTgp6qacNPe3uEONvKerIPhutbo1UvuEGS AoYMONqZpJtbsaFd0uo/gZtTNsBzZwo= From: Lance Yang 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 Message-Id: <20260529030915.37767-1-lance.yang@linux.dev> In-Reply-To: References: 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, 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 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