From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) (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 3F4B32FF144 for ; Wed, 24 Jun 2026 14:50:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782312616; cv=none; b=t+5zdFX8EEUJ3LcLPgaz0Yq5G+kULv9MU9swMwO3ME1otcr7KaKo82CUWMCkfaVArPVIc6HsgQ+ukZjZ32VjiwLlDDI8qGVnF+IxO5ah0wWsktr45ikF21r5kRTuR32UFqIzm+pfvr00Q1KzUMVISClDdRC57U7NzqqtgdYED2w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782312616; c=relaxed/simple; bh=6A4dE5y2IIO9YTg0Vh6OmVKPIVr0zRdOAUwCPRExkLQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=EBc1ErCl5aj+t13z1+0ihuqBuKtIX5gKnJnOxPTEJR9UZXMICMpkVaKBwpn5cbf9BJGQS7MT67zVvMWJ2REXmec/kHtr8rgFGqvyIYAcooTAoHWyWGpLQMykxVpqFrLEj9rycTvGBizFmsfePiN+yo3VhDCi/zvavQfcTiy49mw= 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=pFSv3foD; arc=none smtp.client-ip=209.85.210.177 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="pFSv3foD" Received: by mail-pf1-f177.google.com with SMTP id d2e1a72fcca58-8452aa4d4f8so208824b3a.3 for ; Wed, 24 Jun 2026 07:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782312614; x=1782917414; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=2gqBIwPaeWmL5XMuFIlmntneXFCjftj2s6pIOw2Q4So=; b=pFSv3foDvFf3JSpzHBFTJGJ/FTWSQtXotF+1MAXs5iRqZKSmNEasbAESbRWaMX5R3P PEn2rP5iWlyuhumt62Izp96Kh7blQKWkQ3ihuSn4KSuQHCtSiiIUVwO5e0pUgYTn+mGG bs3yu3Mg6H6NlZo8ErE8xDktWHzbbeVUInAUpfRXuciYDeTOWRv1vY36jUIxlpUbWQiA vJU45SzpmO+WaLVj+5B9enujzBEuXW0gnfQQa2UN/bsOP/kzC4N1nIK9qBwY1n7gP4F4 A9zB8hsW7dyyy0w7OEqEOCtmeTuQW5hIydX5qlZUq2K8GXMmENlgtjlaJ2BuzM2VsqWt 9VEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782312614; x=1782917414; h=content-transfer-encoding:content-type: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 :content-type; bh=2gqBIwPaeWmL5XMuFIlmntneXFCjftj2s6pIOw2Q4So=; b=RDD1g35VBy6R0PlHK6XQ38/4fVjhdnay+hJlHO0pUcrcVD/JD887pgI72aZYAgFs/r /XPH3AokOWDRCEHMIr3mt9we5wiBLXqTQsFe8aSaQ81OxXEAorGuOVnbZLqP2yArmJUq GsQS7Z7GjLa2jnY185gnoxroqlYKqRzbx/zjL79wTUdcn9tI4ufkTIR3xVzK9WVBuTqM h63+5I32sdOH/t3tih5U1egHXJxa48xPrlwzzDMwSWkaFRjV0e4GNyUnvIShPDHQO9fF M5qgxnCUyOE3IFRIZ3GBt9u83ZYqV9WbxzZ/o4tGsD1q1z2KJT15B77NShzwKoD29zuD mNTw== X-Forwarded-Encrypted: i=1; AFNElJ/R37fKR/Pk2D0Wej+I4JfWMcNJpVFXHC2fjHWuQ7YG+Af0ySxruwtIA0Q9tHxz+yW9q0XeKUak6Yx2NSk=@vger.kernel.org X-Gm-Message-State: AOJu0YwzhNXTpm531BqZ7v2a52ehxoQTh8Z5/HQTecrlhUI09x4Uyp5m WUQVzFoOM9968J6fqAO+v2lMun/liVBief/jj8041b33nWvb8UZuavVA X-Gm-Gg: AfdE7cm1MHjVm2d+WIMvIJ/tsCYhugQ5J0EthYaTuaCUN2vWrqYR+scsRe99C9+EVlw jKh1RP386yiBbrooP/GkHgUaFfXTK+aFwndrwyajhDFP49VcyPqD/75aO8Kmc2UviBdSgg7N99u p9vgEJS1XyHCqM1tFF2QvovBXTUFXHZScsJAiokjLqiHrvUjzm9YwQBtL5cYKZp6FJRXuXLSyul B9Y9pysfc/SvQU9ukVrZrAZdVSk4j+6T8HtDMSW6mHanbLpjCzM/ap3ATZYHWt9Ruo4P3DUu+A1 LlUf61u8vUs/z3aqPV9axzQtsCTs8IUaGOENwywxxmdmkAOVCXim6mTPY99EisepeFr43zs+fmq lgQPsBxPye5lSsuKGmYaVvXbWWJSULPPUOUR1+B5M7uYB6ki//sFoxk++uFyiEhEDN7pgXXFdq5 fu8amdy/94HKiYp9x5HO0ZSgGstEVF4PyRnLJ5Yrt+nZLgvvbW+oU45tOd01vWci5g7/yngy1Cu kMKpNAh X-Received: by 2002:a05:6a21:329b:b0:3a3:1814:20a2 with SMTP id adf61e73a8af0-3bc0be10a82mr10975133637.5.1782312614215; Wed, 24 Jun 2026 07:50:14 -0700 (PDT) Received: from debian.lan ([158.247.195.225]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-845a4002bf0sm2374238b3a.25.2026.06.24.07.49.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2026 07:50:13 -0700 (PDT) From: Xueyuan Chen To: david@kernel.org Cc: xueyuan.chen21@gmail.com, dave.hansen@intel.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, 24 Jun 2026 22:49:41 +0800 Message-ID: <20260624144941.703172-1-xueyuan.chen21@gmail.com> X-Mailer: git-send-email 2.47.3 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 On Fri, Jun 19, 2026 at 01:09:09PM +0200, David Hildenbrand (Arm) wrote: Hi, David [...] >Having a new direct-map specific function with clear semantics might indeed >avoid even messing with that. > >So, yeah, given that we have > > set_direct_map_invalid_noflush > set_direct_map_default_noflush > set_direct_map_valid_noflush > >Let's add a > > set_direct_map_ro() > >Or (my preference) > > change_direct_map_ro() > >But given the existing naming scheme ... maybe just set_direct_map_ro() and >we'll clean this up another day. > > >Now, should there also be a "_noflush" in there, or who is supposed to flush the >TLB (or don't we flush at all, because it's used early during boot so far)? > >In any case, for this function we should add excessive documentation and define >clear semantics. > After talking with Lance, we're leaning toward a direct-map helper: set_direct_map_ro_noflush(const void *addr, unsigned long nr_pages) Contract should be pretty explicit: direct/linear map only, no alias handling, no TLB flush. If a caller needs stale entries gone, it has to flush itself. Huge zero folio only uses this early during boot so far, so noflush should be OK. Will document that. Thanks, Xueyuan