From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A16AD217F27 for ; Wed, 17 Jun 2026 14:15:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781705760; cv=none; b=d7lYGPZThGvWX6EyEhDPsKyTRmGvEYLTHLvNNtbeYoJ13FdCTbbs+r9TJhLOemmmrOuma5kzsiP9mzA0QQwonIUhCBBFICLUdoFXCFQifP+T6HVWBKOtv6jBjdMlB4fr4suw2+TFRO23likZcK7cFEzoBlz0XY7WBrjmGjbVL/8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781705760; c=relaxed/simple; bh=2sVQD3SMMCaG16HsDtVUH/1ZjPSJI2+ctborFaAeaSU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=VWdV5OZc6eV+4hHW01PwOmC8WdZofng+I+I/12GI8BIW3OLdzEzLeZfvmG9v4FffrXqexML89sy5BcjitcpBasuZ0vLpo6LJy+pr0mfnlv4JtqGZBE/uKP203BuEArm5ay8E9p38yrqhTNFSfbkc+hG53Es/KWDWFIU24vwZspI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=rVAUG5jP; arc=none smtp.client-ip=209.85.210.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rVAUG5jP" Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-8423f241792so164704b3a.1 for ; Wed, 17 Jun 2026 07:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781705759; x=1782310559; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=kLH2EYfcnmjV4+OcjUuMrn5lYsdA4BHEscTR5GyJ3aM=; b=rVAUG5jPxaPYay7mIQvs3VAWWbt41Pxt9DpDQXpcaAP3tmZqdDgweU5pI4T2VIrVCv sjnZqtv+pdVOL/wyP/2EBPg6Lek1whPHBUWFcEkIyTnd3YIa4e7YGlDjJ9Zv8+NYlqFx EFawHE+RvLHpFCmIV6P/CXZ9w0GZ3UCoHynYYazY9lsYC2g/4i9WeeHbykzb5YGjOAdV nRNeG2r+5v14K06SBKCzDqXPEkr4HSECdkFsQy4+ozZDAX+DC64PdrZKxPI5ZEWoOPfi CzlD2rTjwi7lY6hmy5mj1fqu1lMJwazkrdr2vUlvZqAw66V7taM1gEVh46XfUQbi8aDF uB6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781705759; x=1782310559; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=kLH2EYfcnmjV4+OcjUuMrn5lYsdA4BHEscTR5GyJ3aM=; b=IKYx1KeEoaVmbZ9HXjecYw6dJ1VM8+7v9pQwI8vdLiWixLyW84WH0APvSvjtJ+J+29 kb6aqekfMoyNlgbviivLoHs8XuON60sDAIHZq8wAHlJ1sKwDKKYM6g4J7cv844FNY4WY 9eSQE4d7H/Z1kTpcSJ/74BDy5V/KOiLqaKLgj4RWBMlQCDGm3bjfzbYGJrtCy5KwmBTT KjiNTilIdi+e6aq//6OV84MK7/DcSZvsa5saby1oil62Jq48xSvmTM5SskMa8iCxKora 7/grmIEkIeA6JqZP3hRNWipOWf4+U8YSDel3AnUb8vXd+oST4X27sfStyewNjJdR6Er8 8XpQ== X-Forwarded-Encrypted: i=1; AFNElJ+yl0lfdEJLpUwKeKpApFXsMpsrnw/yKzb1badeUV1/wVayyU+tE7imkJ9xxj7M0XBS2ZmAh+s0OsmrmNI=@vger.kernel.org X-Gm-Message-State: AOJu0YzFfHj8ZsXweB/19pRTI4V3LmKd6Bbr6umco+JWUU8AlPwMEe8D 5CzxQjCew0O9UWfC3bZaP8Y583klZYoA9SrpNwMhPCL32XCQn05TusiR X-Gm-Gg: AfdE7ck8sE5woTGKIgkW+1qVkzV7nvPmSwn1l3dtfj+uRUbr08yuL1x2GJEE6rL3bf0 Sw1a6f5UQDbWgUa7t4+MkEny+LvxVhe5WvBiDb0t/PiO2IaR0hwdYQZK4ibdlWnWlhsjciQejpA Atpuq/7yTNMW/31CaPwBrlhSMl6Bmu7Qv3RSSWJ6gO5jD1UC/8xOSxA07N/AdpisQICrc73sCqz 46wH2B2fbWChhOIOPrVJ6Hg0asgYJtFPth3d8mcQIad+Ew9VtRfqihzFWb1SFyhPQcoKxku0iQk U5aHVD8kU1dBSCOUgTSxjNYoIorJXLs30YiWqQ5WwbytosT7d9CQHFvdAmUc98mfmuhjU66q5N9 XDqtjfprBQqlcIBoSrpGgP52fKdSx5M4ne0wTRfJFfNhyxBw9AMZqj/xDHz5fcQEwvy1TH/qEm8 1c5bIuj0beYzuVoJwyUCxMOU7hPHJQrEbCSt50KNYBFzELkz8U2drE3RloS7yz3yNGGAKcm/eSj BE= X-Received: by 2002:a05:6a00:3e1b:b0:842:2280:5392 with SMTP id d2e1a72fcca58-845247c66aamr2077327b3a.7.1781705758882; Wed, 17 Jun 2026 07:15:58 -0700 (PDT) Received: from fedora ([188.253.112.231]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-8434b040718sm16905766b3a.51.2026.06.17.07.15.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Jun 2026 07:15:58 -0700 (PDT) From: Xueyuan Chen To: david@kernel.org Cc: dave.hansen@intel.com, 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, 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, lance.yang@linux.dev, yang@os.amperecomputing.com, jannh@google.com Subject: Re: [RFC PATCH v2 1/3] mm/huge_memory: make persistent huge zero folio read-only Date: Wed, 17 Jun 2026 22:15:47 +0800 Message-ID: <20260617141547.144275-1-xueyuan.chen21@gmail.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <3b20ad2e-bb69-44be-bad3-5efeb169c573@kernel.org> References: <3b20ad2e-bb69-44be-bad3-5efeb169c573@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 On Wed, Jun 17, 2026 at 01:50:08PM +0200, David Hildenbrand (Arm) wrote: Hi, David >Yes, kerneldoc please. Ack. > >We're adjusting the directmap, remapping a r/w page to be r/o. I think we should >be very clear about which transition we expect+support. > >Also, I rather hate the "set_memory" naming scheme ... "set_direct_map" is >clearer. Anyhow ... > >Now we are throwing a "arch_make_pages_*" into the mix. > >Should it really contain the "arch"? >Should it really contain the "make" ? > >Why can't we just reuse set_memory_ro and pass address+nr_pages? (highmem check? >Could that be moved in there?) > >Or do we want a "change_direct_map_ro()" / "remap_direct_map_ro" interface? > > How about naming it int set_direct_map_ro(struct page *page, unsigned nr)? >> 4. Should this new API be folio or page-based in the first place? >> 5. Is mm/huge_memory.c the right place to define a generic mm function, >> even a stub? > >+1 Ack, will move it out in RFC v3. Thanks, Xueyuan