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 54A4B165F1A for ; Sat, 30 May 2026 07:47:11 +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=1780127233; cv=none; b=u/xlMO8iRWhyRrShCwXLeHnIS4+cYr+hzUSdlY4DhciJG/Xrjf/5EBbd+C3ky1SzIM7Jzlctdq+xlvWhW2Qtql8tF6qdAesW1PuMXfOsod0kSoFR10LZYgaYom+fBA4bbVQVLFkp2joJmTF7TbVMlsN4i0PGd9ABxUbH4qbKH8w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780127233; c=relaxed/simple; bh=KxXQXGjA8Ez+LLNGezkt0TxaGdPDqNizkUCvoA6K7p0=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=gApE/wUj3XGRc/9jl6oszH6PeFTGHDdP5DTXadd/imas/vFfy1EE8xRWTozDzH9JjNoJLY5jr5urG3suTCmsLfwrKvnDxM8IbhPLl1aXbQqEsaljdp83IomKwS4cknbj5KSJFKFpO0NlKjuWJJS7kulfOpZi+zuKgmjROz56bFA= 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=XlU47XZ7; 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="XlU47XZ7" 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=1780127229; 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=KxXQXGjA8Ez+LLNGezkt0TxaGdPDqNizkUCvoA6K7p0=; b=XlU47XZ7t70fUvpZtLoR7bU5qgPv3nVY/flIm+FlY+aCJVaW/2OcOM37f9BjQ1OEGJvAaI OZwER44ej+Z8rnIZum1fy9fCFDR8gZ0vOuRCpNdMO4klHc3Ei1+TdY1vtL2fGXk3go69Md ozbTnRO59SwW8/C48shqyJgtE1VzN6g= From: Lance Yang To: dave.hansen@intel.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, yang@os.amperecomputing.com, jannh@google.com Subject: Re: [RFC PATCH 0/3] make persistent huge zero folio read-only Date: Sat, 30 May 2026 15:46:48 +0800 Message-Id: <20260530074648.33513-1-lance.yang@linux.dev> In-Reply-To: <54986350-dfd4-4065-b960-e1ba30fee4b8@intel.com> References: <54986350-dfd4-4065-b960-e1ba30fee4b8@intel.com> 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 Hi Dave, Sorry for the late reply. On Wed, May 27, 2026 at 08:58:38AM -0700, Dave Hansen wrote: >On 5/26/26 20:56, Xueyuan chen wrote: >> The motivation comes from Jann Horn's read-only zero page work[1] and the >> follow-up discussion[2] with Yang Shi. As Jann pointed out, the kernel has >> had bugs, including security bugs, where pages taken with read-only >> semantics were later written to. > >My overall concern with this is that it's just a code hack for the huge >zero page and nothing else. It's a total one-off. Fair point. I was trying to keep the first version simple, so I special-cased the persistent huge zero folio. But agreed, the arch side should not grow a huge-zero-folio-only hook :) >I think you need to make the case here that the huge zero page truly is >a special snowflake and deserves a one-off special snowflake solution. >Because it doesn't seem *that* crazy that there are more things that the >kernel dynamically allocates that it wants to keep read only. > >Maybe there aren't many things that get mapped to userspace like this. >But the case needs to get made either way. For RFC v2, I think we should make the arch hook generic, probably arch_make_folio_readonly(), with a weak default implementation. The persistent huge zero folio would just be the first user. But even with a generic helper, we still need to be careful about the model. I see two possible ones: 1) Treat "read-only in the direct map" as real folio state. Then core MM has to know about it and carry or clear that state in paths like migration and freeing. It also makes the possible direct-map split / TLB cost a more general MM issue, not just a cost tied to one caller ... 2) Only use the helper for folios with a simple lifetime: allocated once, not migrated, not freed, and not written after they are made read-only. I'd start with 2. Keeps the arch API generic, but avoids teaching core MM a new folio state before we have a user that really needs that. The persistent huge zero folio still works fine with that model. It just becomes the first user instead of the special case :) Thoughts? Cheers, Lance