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 10C7D2BE7A7 for ; Thu, 28 May 2026 14:42:02 +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=1779979323; cv=none; b=sA8ubvzWVEYrEyxk29x1hZPFKypOO9TOpk2quf1ScV+lMkqo8+wn5tPw3PteasQDKHf9qDc4E7vnBUN6C7GcgLr0Kridqb0yYhZ+IhzOUyAX80iF5U85IOlGTTmdWP+xpZB6i5ghbgatPfFCmCs8T/eOAdGw8iVe98OsO8OVMcY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779979323; c=relaxed/simple; bh=2Y/6zuaJ5bKdFGWrIqvL1xgUB0/vTpSnJswAoFFAmK8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=AurT/tefU9LRcJD23M1l4eLMXj05DCZrHdNmIlsWmO86PKWiiSCAuhyIeMr5Ijenmtd7h1FZIY+NrT2ZKVU9iB3B2zD+1eakmb63hXkqE5VXut8d2IN+foxNhgMGNRKeYd5yi0djpONMPfgVRoLkR5jmAw/QIDyc4UuIa5yqr5M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kZT86gGL; 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="kZT86gGL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BB6B61F000E9; Thu, 28 May 2026 14:41:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779979322; bh=NidMkUmESVDNlcSyssCD7iZp1v/eAgCquicEmOON/mM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=kZT86gGLszALBo+IVJWP75sjtXaeROUt9a9FO4bIW3ZUmT751p4s78vUy72+nH3uY as5+HZZnfsBTp4+kpTUaPyuQwKLXPM09JM57thOilmhX6A8dq0DZFD/f5HS6FZ+7nu gh/2f8SB2LA0OrM4BUL9kulFb/zsPPVIs7VsF4BOa/P9qgvIXGVYlj5xlKUi+KMzaP 6rilsaQQ4gBp9OcchqbJ3nRmDYJ2Ppd34GoC1E8DSxiMQvGi41Od6STQb05NiXtzhS mPx4e0zZQsl/cRscgGJYrAd8V4HEZi8KRbWx/9RmYFfAa5kmcE5zLheCWTc+KQufs5 +/R87HLTa+KUA== Date: Thu, 28 May 2026 17:41:55 +0300 From: Mike Rapoport To: Lorenzo Stoakes 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 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. > > 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. -- Sincerely yours, Mike.