Received-SPF: pass (google.com: domain of linux-kernel+bounces-117480-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Mon, 25 Mar 2024 13:35:59 -0300
From: Jason Gunthorpe <jgg@nvidia.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Andrew Morton <akpm@linux-foundation.org>, Peter Xu <peterx@redhat.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC PATCH 4/8] mm: Provide mm_struct and address to
 huge_ptep_get()
Message-ID: <20240325163559.GE6245@nvidia.com>
References: <cover.1711377230.git.christophe.leroy@csgroup.eu>
 <1abe6cfaba2ad41a9deb705a4d3de8d1a9b6d5ca.1711377230.git.christophe.leroy@csgroup.eu>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1abe6cfaba2ad41a9deb705a4d3de8d1a9b6d5ca.1711377230.git.christophe.leroy@csgroup.eu>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?3BEzecunK9DG/KyC+6nFrRcurAIMud31+gEOk/OuXik3aP3Fuf+h4HGdge5m?=
 =?us-ascii?Q?NC/ISLVBKrVsnFrKQxefSgXjxAf/8znYWeY9fYHs1CkXPbK+OevBd87EyRz4?=
 =?us-ascii?Q?dRclxTTh4+Vx7NGH4TqrEwnkyb+l0EYjaQZShpY9XyAssuO/lwz70EA8pg0j?=
 =?us-ascii?Q?35WBKnqc7TXmwtFussqBg+k7DfI+/wcArXDn5U0GYVKY6kA4PymJru5/pYuj?=
 =?us-ascii?Q?6hjiS3nwq6Ke770fdDagClHLB9+jZw3oNg95BLqJuTDPK8nA/noJOxZ4hiin?=
 =?us-ascii?Q?K5tFicbT0+18xgs7sQEEuoXNfGw0RfmKMic/jlsrRbzAwwK8Ingqx+b3Rlab?=
 =?us-ascii?Q?C5/lLK/htxNLZc3dytJbN3GlJO6zNPOEeA4jbFmD5qnvvCP6XR89EsCCaTBI?=
 =?us-ascii?Q?g+7qT2eCpYCYdB4Cg8WiEWBsUwedEray3g8pA3z7XCsphvK9VKU5QvgmzJcJ?=
 =?us-ascii?Q?ucEs2sYZnUWAMYX329bZa5bR2SkqooGAremH6WvHiNm4p3MC2jJnyHP5icg0?=
 =?us-ascii?Q?Sj2yKELmrarw4hMVeCZaNGMEuG96cBVva78HvHTv4PlN3ksBBphrh6OiDlqx?=
 =?us-ascii?Q?e7dkDSRZi0E+3eWt6ZtJeqxveRQ2/fLhNyFLal9ppo75v6LK9F4+O1xl9wXO?=
 =?us-ascii?Q?JigkiqCk44XDnz9Xo5hM5D6zeHS5jEGxpe8Q3MN4QxQ3OfqB+7Bfek/Q5XlT?=
 =?us-ascii?Q?qi1CxqZtdqSuUyD6WUXQ9Fkn4IXc2a6BF3SjyULVqL5DbRVs5oRKxVKVT16W?=
 =?us-ascii?Q?TjxWr5AHoGgw65HnZx5cVJeKNEwxppuXQ55xEzoKLRaOfyR8519oTOo/1mi6?=
 =?us-ascii?Q?to1P74ZDGe8fkYXq6C83aLLc3tMMRVNssFyEp18xxYG3YCVNtEWthCe/3miN?=
 =?us-ascii?Q?wcEdwRe/us0kLiHlnmiz+vJDfSbH91WDmT6ruVd1U5ocUqnU21+ilNnQ8JLR?=
 =?us-ascii?Q?GzSmEuLyxlg3+RQjHJdIKq4Z7//wpdRuOGL3u5WNhW4baN4wXuW927qH37Fg?=
 =?us-ascii?Q?Kv1k3v69atTDpCDjyOI/mgbZ2b+mZTOh7E/PrT6jF47rhezxKAyZ6xf39lka?=
 =?us-ascii?Q?IRFBtUlE/CQXy6B7ma57n4ErbrE/ElRbSyns4uRR4XV/J5GvSHB/+eQVI0ox?=
 =?us-ascii?Q?XidXpznqO7bXlaa8W1OdHFuz8UYMoYotBEjvi2Tk7ks2ahCe/UNVrGU/dxud?=
 =?us-ascii?Q?PzxlLYmkEFaxqLPPuyrlga9k0cJwXLMP/jdmN4waIWezk+Iq0VkRCyQMcvad?=
 =?us-ascii?Q?ymfYOwv5n6BXpRNVtgZXQTsYC1TCkO0WyJF6aRKjk/QiVr+V1zIsyAvd7ZGR?=
 =?us-ascii?Q?95zo6aWAIKpQ511POB4Ka3pHByGq0ZDkfgLQTxTL+etGA54e4b+i4ZHvS1+4?=
 =?us-ascii?Q?4GBrl9jlCAU3XERq6s7bGvNmbuKzzHXAIGWQNg5WPVhsarEbrzILMu9b4moi?=
 =?us-ascii?Q?APQUZICLJ1/sC76WFULWVdEnxxJUQhPQk6jX4sqzXnpii/98tU/VPcEDNIbD?=
 =?us-ascii?Q?CfQyRSpy9xLjh5+d+/ivvxj4zFD9z3fgm5TVIEiaqTwNSBDVr4ij/LEiWt23?=
 =?us-ascii?Q?+67AI+5G/iWZOA8TjDieY3OLeU0QVXuncDPL9/xA?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2653e59f-23d5-41d9-8278-08dc4ce9a7c7
X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB3849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Mar 2024 16:36:00.6895
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: mIsS7pdRXWdBcvGrjzdtO2NMuzTl5JiqFJ9OFSs1biOoUsAvtu2d+Mo55ArrNUDg
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8996

On Mon, Mar 25, 2024 at 03:55:57PM +0100, Christophe Leroy wrote:

>  arch/arm64/include/asm/hugetlb.h |  2 +-
>  fs/hugetlbfs/inode.c             |  2 +-
>  fs/proc/task_mmu.c               |  8 +++---
>  fs/userfaultfd.c                 |  2 +-
>  include/asm-generic/hugetlb.h    |  2 +-
>  include/linux/swapops.h          |  2 +-
>  mm/damon/vaddr.c                 |  6 ++---
>  mm/gup.c                         |  2 +-
>  mm/hmm.c                         |  2 +-
>  mm/hugetlb.c                     | 46 ++++++++++++++++----------------
>  mm/memory-failure.c              |  2 +-
>  mm/mempolicy.c                   |  2 +-
>  mm/migrate.c                     |  4 +--
>  mm/mincore.c                     |  2 +-
>  mm/userfaultfd.c                 |  2 +-
>  15 files changed, 43 insertions(+), 43 deletions(-)
> 
> diff --git a/arch/qarm64/include/asm/hugetlb.h b/arch/arm64/include/asm/hugetlb.h
> index 2ddc33d93b13..1af39a74e791 100644
> --- a/arch/arm64/include/asm/hugetlb.h
> +++ b/arch/arm64/include/asm/hugetlb.h
> @@ -46,7 +46,7 @@ extern pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
>  extern void huge_pte_clear(struct mm_struct *mm, unsigned long addr,
>  			   pte_t *ptep, unsigned long sz);
>  #define __HAVE_ARCH_HUGE_PTEP_GET
> -extern pte_t huge_ptep_get(pte_t *ptep);
> +extern pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr, pte_t *ptep);

The header changed but not the implementation? This will need to do
riscv and s390 too.

Though, really, I think the right path is to work toward removing
huge_ptep_get() from the arch code..

riscv and arm are doing the same thing - propogating dirty/young bits
from the contig PTEs to the results. The core code can do this, maybe
with a ARCH #define opt in.

s390.. Ouchy - is this because hugetlb wants to pretend that every
level is encoded as a PTE so it takes the PGD and recodes the flags to
the PTE layout??

Jason