From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18])
	(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 138D425B09B
	for <linux-kernel@vger.kernel.org>; Sun,  5 Jul 2026 08:33:38 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1783240420; cv=none; b=SGwG2tm+y1zQ94Pep77WjihhXcsYtbq5duvVdbzwuonHjD38y92nPnRawmhSH9W1AXJr59/gMWWcwkFuwGllQ/VBnDzaR06KGHAypfQNL3D/SWzlWZNhh0mVyybnii0ejizfZUfnOUsJ5eKpQfTCB4HkkoE+npGUzScPvUA8tno=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1783240420; c=relaxed/simple;
	bh=mjd3i0z4Hp9RajgxrqABau+6G+QXnNH8SejQMfDit/c=;
	h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References:
	 Mime-Version:Content-Type; b=ICLvKp2N/gxkLSNVkmY2jnok4XuEKwUw7UTwNUK6fwqwjRSREgum8Rr9xgWeRlgdOCYH5Vczk8nWl9sXvai94S8d2/N1x1Kk7hLSH0WO9y5rw0K9cDyEWrzpGvyq63OAuzaoZ+nqfo1ml+j+F2T4NyHEYYy3qwfpOU/OBJy24Ic=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=eNPPFp5q; arc=none smtp.client-ip=100.103.45.18
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="eNPPFp5q"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 742221F000E9;
	Sun,  5 Jul 2026 08:33:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=linux-foundation.org; s=korg; t=1783240418;
	bh=baTotMMHSOM5O4gBj8/uxAAtb6QXbZ9I7HQpeImF9RI=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References;
	b=eNPPFp5qbKoJvjUdtGg8w3IZMg0vNZv6+vkTJLLSWou52vAtg3PDH+YXoVUKkouG2
	 Tp5I1zPHI6skDu0RSAecz1Q5bIQEjW4D5u6sgFWBLlB3ZBkSkoh5xEUlGn3n1eSJGK
	 peEKGToSl+aX/tl3OJYA18f9PnOfG4kNUughduRc=
Date: Sun, 5 Jul 2026 01:33:37 -0700
From: Andrew Morton <akpm@linux-foundation.org>
To: Dev Jain <dev.jain@arm.com>
Cc: muchun.song@linux.dev, osalvador@suse.de, ljs@kernel.org,
 david@kernel.org, liam@infradead.org, riel@surriel.com, vbabka@kernel.org,
 harry@kernel.org, jannh@google.com, lance.yang@linux.dev, kas@kernel.org,
 linux-mm@kvack.org, linux-kernel@vger.kernel.org, apopple@nvidia.com,
 rcampbell@nvidia.com, ziy@nvidia.com, matthew.brost@intel.com,
 joshua.hahnjy@gmail.com, rakie.kim@sk.com, byungchul@sk.com,
 gourry@gourry.net, ying.huang@linux.alibaba.com, ak@linux.intel.com,
 nao.horiguchi@gmail.com, mel@csn.ul.ie, j-nomura@ce.jp.nec.com,
 pfalcato@suse.de, tglx@kernel.org, dave.hansen@intel.com,
 jpoimboe@kernel.org, catalin.marinas@arm.com, will@kernel.org,
 linux-arm-kernel@lists.infradead.org, ryan.roberts@arm.com,
 anshuman.khandual@arm.com
Subject: Re: [PATCH v3 6/6] mm/mprotect: use huge_ptep_get() for hugetlb
Message-Id: <20260705013337.2bbc075b508b5db36b954051@linux-foundation.org>
In-Reply-To: <20260703114202.365553-7-dev.jain@arm.com>
References: <20260703114202.365553-1-dev.jain@arm.com>
	<20260703114202.365553-7-dev.jain@arm.com>
X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu)
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Fri,  3 Jul 2026 11:41:59 +0000 Dev Jain <dev.jain@arm.com> wrote:

> prot_none_hugetlb_entry() is the hugetlb callback for the early
> mprotect(PROT_NONE) PFN permission walk on x86.
> 
> The callback passes the decoded PFN to pfn_modify_allowed(). For a
> hugetlb callback, the pte pointer refers to a hugetlb entry. On
> architectures where hugetlb entries need huge_ptep_get(), reading that
> entry with ptep_get() can make the permission check use the wrong PFN.
> 
> Use huge_ptep_get() before decoding the hugetlb PFN.
> 
> Currently there is no path which can trigger a bug: huge_ptep_get() is a
> simple ptep_get() for x86, and the prot_none walk occurs only for x86.
> 
> So no need to backport - use the correct helper anyways.
> 
> ...
>
> --- a/mm/mprotect.c
> +++ b/mm/mprotect.c
> @@ -699,14 +699,20 @@ static int prot_none_pte_entry(pte_t *pte, unsigned long addr,
>  		0 : -EACCES;
>  }
>  
> +#ifdef CONFIG_HUGETLB_PAGE
>  static int prot_none_hugetlb_entry(pte_t *pte, unsigned long hmask,
>  				   unsigned long addr, unsigned long next,
>  				   struct mm_walk *walk)
>  {
> -	return pfn_modify_allowed(pte_pfn(ptep_get(pte)),
> -				  *(pgprot_t *)(walk->private)) ?
> -		0 : -EACCES;
> +	const pte_t entry = huge_ptep_get(walk->mm, addr, pte);
> +
> +	if (pfn_modify_allowed(pte_pfn(entry), *(pgprot_t *)(walk->private)))
> +		return 0;
> +	return -EACCESS;

"EACCES".

>  }
> +#else
> +#define prot_none_hugetlb_entry	NULL
> +#endif

Presumably your .config resulted in this change not being tested...