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 19EF535DA78; Thu, 15 Oct 2026 19:45:53 +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=1792093555; cv=none; b=WiMHdi9fZSInMDi+xt0n3uGbuvB79Gu3ADWtObJoDrbPuGDHEH2MpCcAHgOjtzCl88kPNcodjmYp8l9xcMb4D80j0uvDGMwBOxcWfPUUHzYIvFQ1N2nWGk3ryiJNiKuWr7VyYrqu/3CdlNDkDVdnHgGkTDPYLomY39Q/s6e02Ok= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792093555; c=relaxed/simple; bh=aVl4fWIyCLg2R4ibK0RmkIrVXCYhIvuzQtwD9SP/mYA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fOkcpSn+xqh5ZYdwFv6LVOoFQQCW712PP78TDvQWMd5QS/h/0jAgoU6BU3QD0xAEkt81HbTSH7gnuxHJ96HuMHPxtiwj/OO+R2qkFbDwzmTAT5je+8SRQRDGi1HYWjUwVZaXAxqiHydptBIUKb5per6UkfZ3nHv2aJRNnBM2myo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Bcqd+HH2; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Bcqd+HH2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C10FC1F000C4; Thu, 15 Oct 2026 19:45:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792093553; bh=kTFEZ49kr33oEAdO5drlS9BF04qwOVSn+b6FDU6toc8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=Bcqd+HH2iwmj6Pwil0HmsygLrhCeYDX7C6OFeH/xUu7GGXjOwTO62tiPu/T2BjKw0 7zPETfQ3FjJHaJwk5s5MWu1XcAo82trouQ8l9I9ysLxWyEMHYb7id1ROAoCL4ChnBH 7NR9iyk5XjbQNPG4SRgGuEcRkY428k4lbCfWTmb4Xbgvs+nzR3D4B9nr6mBkLQpaXt EN1UIA5AuSL4WeeuREVvhml+oJLHggN50OtTAcwF3nxYJnGx+L/RSZCIN0pVqQSXfP l65/hfj7vA5XaZMeDO92UtYe7lXgWgnDaBKzS5xWQ/LXabdaW3TUp+hp1cSse8L0Ai Xs2k320TrAhOA== Date: Thu, 15 Oct 2026 20:45:46 +0100 From: "Lorenzo Stoakes (ARM)" To: "David Hildenbrand (Arm)" Cc: Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Jann Horn , Pedro Falcato , Muchun Song , Oscar Salvador , Miaohe Lin , Naoya Horiguchi , Adam Litke , Mel Gorman , Rik van Riel , Peter Xu , "Kiryl Shutsemau (Meta)" , "Mike Rapoport (Microsoft)" , Josef Bacik , linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Chris Mason Subject: Re: [PATCH 09/10] mm/hugetlb: don't leave a uffd-wp marker when zapping an RWP entry Message-ID: References: <20261015-urgent_fixes-v1-0-42796911043b@kernel.org> <20261015-urgent_fixes-v1-9-42796911043b@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=us-ascii Content-Disposition: inline In-Reply-To: <20261015-urgent_fixes-v1-9-42796911043b@kernel.org> On Thu, Oct 15, 2026 at 06:07:15PM +0200, David Hildenbrand (Arm) wrote: > From: Josef Bacik > > An entry that is protected with UFFDIO_RWPROTECT is PAGE_NONE with the > uffd bit set, the bit that userfaultfd write protection uses too. When > __unmap_hugepage_range() zaps an entry with that bit it leaves a > PTE_MARKER_UFFD_WP behind, whatever the VMA is registered for. > > In a VMA registered with UFFDIO_REGISTER_MODE_RWP that marker means > nothing. The next fault has hugetlb_no_page() turn it into a present, > read-only entry with the uffd bit. That is not an RWP entry, since it is > not PAGE_NONE, and the VMA has no VM_UFFD_WP (the two modes can not be > registered together). An earlier fix solved some side effects, now just > stop the zap from wrongly installing a marker. > > Leave a marker only if the VMA is registered for write protection, both > for present and for non-present entries. The zap of ordinary page > tables has the same test, in cond_install_uffd_wp_ptes(), and > hugetlb_change_protection() says that "uffd_rwp does not install markers". > > After a zap the range of an RWP VMA is simply empty, as it is for > anonymous memory and shmem. Nothing changes for VMAs with VM_UFFD_WP. In > a VMA that is not registered at all a leftover uffd bit or marker is now > dropped by the zap and no longer kept alive. > > Original fix generated by an LLM and sent in private by Josef. > > Fixes: 2d427bb01639 ("mm/userfaultfd: add RWP fault delivery and expose UFFDIO_REGISTER_MODE_RWP") > Cc: stable@vger.kernel.org > Reported-by: Chris Mason > Signed-off-by: Josef Bacik > [ david: a bit of description overhaul+simplification ] > Signed-off-by: David Hildenbrand (Arm) Seems sensible to me so: Acked-by: Lorenzo Stoakes (ARM) > --- > mm/hugetlb.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index 1548a6156206b..fb51f7d02cebf 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -5267,7 +5267,7 @@ void __unmap_hugepage_range(struct mmu_gather *tlb, struct vm_area_struct *vma, > * drop the uffd-wp bit in this zap, then replace the > * pte with a marker. > */ > - if (pte_swp_uffd_any(pte) && > + if (userfaultfd_wp(vma) && pte_swp_uffd_any(pte) && > !(zap_flags & ZAP_FLAG_DROP_MARKER)) > set_huge_pte_at(mm, address, ptep, > make_pte_marker(PTE_MARKER_UFFD_WP), > @@ -5303,7 +5303,7 @@ void __unmap_hugepage_range(struct mmu_gather *tlb, struct vm_area_struct *vma, > if (huge_pte_dirty(pte)) > folio_mark_dirty(folio); > /* Leave a uffd-wp pte marker if needed */ > - if (huge_pte_uffd(pte) && > + if (userfaultfd_wp(vma) && huge_pte_uffd(pte) && > !(zap_flags & ZAP_FLAG_DROP_MARKER)) > set_huge_pte_at(mm, address, ptep, > make_pte_marker(PTE_MARKER_UFFD_WP), > > -- > 2.43.0 > -- Cheers, Lorenzo