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 191DD2DC32A for ; Mon, 8 Jun 2026 13:03:16 +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=1780923798; cv=none; b=ZofPQwSSIxshpd623tWaAEW5ZLRbDEayyi4+YX5Ibhf50Y/5RWN4b2McfluCeNlvQEwOQ30Y/pZC8upYXhZpCu8TnsWTqSJKIs92cWgEONIkJ8GKKbK0RaH1G4nBgQNTEGFotBhvVu7EF87eHcWwgFN4tiG8Fl8qw3jdNztQFxU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780923798; c=relaxed/simple; bh=FvI76GfX+ZEu/4zs7J1waxOnw5N9SdAUr/XCiz3PxiM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CzUy0W8/DCmSmJS1HkBeLpnph0o/Kffi10Y65d8tJS06pLVe2p4eg/iIEdsJocRVVh5C+vBeizOUx6FemjlZ3tgpy5T/HcYLntoffJJr+EZ2eThFpBnvCcsWpofawE99D3UTS2h5A0RXvEPGiz9pSX+5z38O5XWWnUyQdOMGJuo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WnCrlLI4; 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="WnCrlLI4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 543481F00893; Mon, 8 Jun 2026 13:03:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780923796; bh=u8t0JmXdFbFbeA5ltIt8qNK+2eno+amYqyTTozeq0js=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=WnCrlLI4cEoMqxpHS7crTMZ3G8aXdSp+Y2MrhSAn29GjoXlwtyB1iVzwJBlcShKgQ pS+Y/y7PAA5vbOAIYl/Ohabzt6Jd8sPvo92QX+E4ZZNL0NqwSw/EsU4co8tpclya3d XDHgb3y5I0lROYr5Rl4fSbLacF4QPl9IXOxMMegPyxwXYQ6X+d/actDFi6mMVbUJJo nLgGoxZRjfRD0UKJYiiIu6BbPMg0ubpsUO5e3nusonpfgll/NaNxrd8t7xOWgtj0Y0 X+xKatEulWW/roSNbMe7xFy9ukkH6ve242zAXed11Qud7X4d1KT63aruFmsVYKgkER ukQnsV6eKeW/w== Date: Mon, 8 Jun 2026 14:03:11 +0100 From: Lorenzo Stoakes To: Mike Rapoport Cc: Andrew Morton , David Carlier , David Hildenbrand , Heechan Kang , "Liam R. Howlett" , Michael Bommarito , Peter Xu , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/3] userfaultfd: verify VMA state across UFFDIO_COPY retry Message-ID: References: <20260527184751.4147364-1-rppt@kernel.org> <20260527184751.4147364-2-rppt@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: On Thu, May 28, 2026 at 05:41:55PM +0300, Mike Rapoport wrote: > On Thu, May 28, 2026 at 02:31:00PM +0100, Lorenzo Stoakes wrote: > > On Wed, May 27, 2026 at 09:47:49PM +0300, Mike Rapoport wrote: > > > From: "Mike Rapoport (Microsoft)" > > > > > > mfill_copy_folio_retry() drops the VMA lock for copy_from_user() and > > > reacquires it afterwards. The destination VMA can be replaced during that > > > window. > > > > > > The existing check compares vma_uffd_ops() before and after the retry, but > > > if a shmem VMA with MAP_SHARED is replaced with a shmem VMA with > > > MAP_PRIVATE (or vice versa) the replacement goes undetected. > > > > > > The change from MAP_PRIVATE to MAP_SHARED will treat the folio allocated > > > with shmem_alloc_folio() as anonymous and this will cause BUG() when > > > mfill_atomic_install_pte() will try to folio_add_new_anon_rmap(). > > > > > > The change from MAP_SHARED to MAP_PRIVATE allows injection of folios into > > > the page cache of the original VMA. > > > > > > There is no need to change for hugetlb because it never uses > > > mfill_copy_folio_retry(). > > > > > > Introduce helpers for more comprehensive comparison of VMA state: > > > - mfill_retry_state_save() to save the relevant VMA state into a struct > > > mfill_retry_state (original uffd_ops, relevant VMA flags, vm_file and > > > pgoff) before dropping the lock > > > - mfill_retry_state_changed() to compare the saved state with the state > > > of the VMA acquired after retaking the locks > > > - mfill_retry_state_put() to release vm_file pinning. > > > > > > Use DEFINE_FREE() cleanup to wrap mfill_retry_state_put() to avoid > > > complicating error handling paths in mfill_copy_folio_retry(). > > > > > > Fixes: 292411fda25b ("mm/userfaultfd: detect VMA type change after copy retry in mfill_copy_folio_retry()") > > > Fixes: 6ab703034f14 ("userfaultfd: mfill_atomic(): remove retry logic") > > > > Did we want a Cc: Stable? > > Andrew adds it when applying. Hmm, I didn't think this always happened by default? :) > > > > Suggested-by: Peter Xu > > > Co-developed-by: David Carlier > > > Signed-off-by: David Carlier > > > Co-developed-by: Michael Bommarito > > > Signed-off-by: Michael Bommarito > > > Signed-off-by: Mike Rapoport (Microsoft) > > > > OK the logic here looks good, thanks for the changes. I have one comment below > > re: a redundant check, with that addressed feel free to add: > > > > Reviewed-by: Lorenzo Stoakes > > > > > --- > > > mm/userfaultfd.c | 85 +++++++++++++++++++++++++++++++++++++++++------- > > > 1 file changed, 73 insertions(+), 12 deletions(-) > > > > > +static bool mfill_retry_state_changed(struct mfill_retry_state *state, > > > + struct vm_area_struct *vma) > > > +{ > > > + vma_flags_t flags = vma_flags_and_mask(&vma->flags, > > > + MFILL_RETRY_STATE_VMA_FLAGS); > > > + > > > + /* Have any UFFD flags (missing, WP, minor) changed? */ > > > + if (!vma_flags_same_pair(&state->flags, &flags)) > > > + return true; > > > + > > > + /* VMA type or effective uffd_ops changed while the lock was dropped */ > > > + if (state->ops != vma_uffd_ops(vma)) > > > + return true; > > > + > > > + /* VMA was anonymous before; changed only if it no longer is */ > > > + if (!state->file) > > > + return !vma_is_anonymous(vma); > > > + > > > + /* VMA was file backed, but file, inode or offset has changed */ > > > + if (!vma->vm_file || vma->vm_file->f_inode != state->file->f_inode || > > > + state->file != vma->vm_file || vma->vm_pgoff != state->pgoff) > > > + return true; > > > > Doesn't state->file != vma->vm_file render the inode check redundant? > > Nope, struct file is TYPESAFE_BY_RCU, it can be recycled with the same > file * pointing to different objects. Oh lord :) OK ack on that then! > > -- > Sincerely yours, > Mike. Cheers, Lorenzo