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 500C133B6EA for ; Fri, 3 Jul 2026 06:24:23 +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=1783059864; cv=none; b=V3Fnr417/TGGvrL/91qGwu+7mQTZYq90O/3qwrXm/9rqu9Q1NRuy5rY2JiByZYHlW0+HSZQp3EhXUT+4suao3AbIon8o3H3A0b/POTcXWF8HqnzMwY8Zfv+D+iMLqBIWkBOb6VpmerKGnuhgQ9yrIBu4XnhnEwp5JAheeGZAr6g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783059864; c=relaxed/simple; bh=BIiSZrHdhX2ESMGpSf5lZP/hnpr+HaCJQnEaE2Ql4bg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bY6ZHm4sx4NixpZXWZfNZ7vOBerMd0I4DSCMcHoad4qe7c77xens+z7uwZrJFfS/M3LbiJnyswpGv1rqekaxxZDJINac0zUP1d+spke/m0xkk/w2DU8xBUDt9EmALPspiGMGkdoRJV7TMbDBZrpYtzN1WAxXjphgPtYWFqkWoJA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SJGw1s2I; 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="SJGw1s2I" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BF0031F000E9; Fri, 3 Jul 2026 06:24:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783059863; bh=VSCI+9VMFGhzZ4DHrpiIFSYVmzhFlldpQab5ARttNrE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=SJGw1s2I3fN0rhA453Szz+Q90oqWuePSgwQLW0OiR0tHPsGk2ShFtqQLeGlQe0ylE UEmr+1XISkkD2hI+MuqB/fvupdy+jzj4H/Usx18ttHKGI6nwBUbijJ/gL8ocLk34ni W48nEvXVVv6YEYS+y10oe2abN6tD3ze2D0Stu4mWrsboocGIr9kAo8WuTurJ9YVh+h rdSczdSkFnFEXqT7ukJn4YrSUsd4QNRxMzPrYY8i2wQ6o4QrW98Z2SOI/n4nFd7w/A PXFWSqOmZ8Vrz81/Pz96SeDwZ99lqvbXWOZICtd88TvEWHEhbb7c2TKfWt8eF5CQiW e4S3CSmPvRuCA== Date: Fri, 3 Jul 2026 09:24:17 +0300 From: Mike Rapoport To: Jianhui Zhou Cc: akpm@linux-foundation.org, linux-mm@kvack.org, peterx@redhat.com, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com, syzbot+18d274a59b87cf80e86d@syzkaller.appspotmail.com Subject: Re: [PATCH] mm/userfaultfd: clear uffd-wp PTE state when re-registering without WP Message-ID: References: <20260601082609.170076-1-jianhuizzzzz@gmail.com> 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: <20260601082609.170076-1-jianhuizzzzz@gmail.com> On Mon, Jun 01, 2026 at 04:26:09PM +0800, Jianhui Zhou wrote: > UFFDIO_REGISTER can be issued on a range that is already registered in > the same userfaultfd context, replacing the VMA's userfaultfd tracking > mode. For example, a range can be registered with > UFFDIO_REGISTER_MODE_WP and later re-registered with > UFFDIO_REGISTER_MODE_MISSING. > > When the second registration removes VM_UFFD_WP, the VMA flags are > updated but existing uffd-wp state in page-table entries is left behind. > That stale state can survive in swap PTEs. On swapin, do_swap_page() > restores _PAGE_UFFD_WP from the swap PTE and can then install a writable > PTE, triggering page_table_check: > > pte_uffd_wp(pte) && pte_write(pte) Please explain where the check is triggered and what are the effects. > Handle removal of WP mode through UFFDIO_REGISTER the same way as > UFFDIO_UNREGISTER: resolve the per-PTE uffd-wp state before dropping > VM_UFFD_WP from the VMA. > > Also make the same-context fast path require an exact UFFD mode match. > The old subset check treats MISSING|WP -> MISSING as a no-op, even though > WP mode is being removed. > > Fixes: f45ec5ff16a7 ("userfaultfd: wp: support swap and page migration") > Reported-by: syzbot+18d274a59b87cf80e86d@syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=18d274a59b87cf80e86d > Signed-off-by: Jianhui Zhou > --- > mm/userfaultfd.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c > index 180bad42fc79..dc0b3eba768b 100644 > --- a/mm/userfaultfd.c > +++ b/mm/userfaultfd.c > @@ -2153,13 +2153,21 @@ int userfaultfd_register_range(struct userfaultfd_ctx *ctx, > * userfaultfd and with the right tracking mode too. > */ > if (vma->vm_userfaultfd_ctx.ctx == ctx && > - vma_test_all_mask(vma, vma_flags)) > + (vma->vm_flags & __VM_UFFD_FLAGS) == vm_flags) Please use new VMA flag APIs. > goto skip; > > if (vma->vm_start > start) > start = vma->vm_start; > vma_end = min(end, vma->vm_end); > > + /* > + * Re-registering into the same userfaultfd can remove WP mode. > + * Clear any per-PTE uffd-wp state before dropping VM_UFFD_WP, > + * matching the UFFDIO_UNREGISTER cleanup semantics. > + */ > + if (userfaultfd_wp(vma) && !(vm_flags & VM_UFFD_WP)) > + uffd_wp_range(vma, start, vma_end - start, false); > + > new_vma_flags = vma->flags; > vma_flags_clear_mask(&new_vma_flags, __VMA_UFFD_FLAGS); > vma_flags_set_mask(&new_vma_flags, vma_flags); > > base-commit: e43ffb69e0438cddd72aaa30898b4dc446f664f8 > -- > 2.43.0 > -- Sincerely yours, Mike.