From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 A1E4E28980F for ; Sun, 12 Apr 2026 15:46:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776008784; cv=none; b=W5byfjdBqiJ/t0Ai3xpzNhim/XkIBr2TBjWWW3pAxg+AdcczEpHVrOYifBmPOCizF24pteGulz5Er27rWCU8YEUjDyNg4wh5YY33Voa9pD/FAO95+hYygWVMDiRVlmnZx284TszCT0lhhtjWEGKAASzULYZrhi9uD4gL3gXvykw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776008784; c=relaxed/simple; bh=EYf/goX7OAlC3Is00z3Y2oPAAJuYGpf93xqgl5zb4ek=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NH1C4iE5Cde47PQr03cjHNVRuh2Le63Gp9HFwoviPi3bdOq57PvRWxJ63a1UoNYtuLszoCuxImI3KhprERxy+/tDQAr4d8CMpj9ZfwvkDOLKl24E6zusjsS9kK+Yx9V/6CFmLyvR9/6PnnVkU92DkHJFhkohAZv5O86i/CJHvKw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Rf37rqrV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Rf37rqrV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CFCB1C19424; Sun, 12 Apr 2026 15:46:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776008784; bh=EYf/goX7OAlC3Is00z3Y2oPAAJuYGpf93xqgl5zb4ek=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Rf37rqrVAQDAdJo3ODh7JW01Nf6pXWbxXI1tcxEiUKY4aM3RN0bMmHi/WxwtkJ1Lx aAJR07MypV0dkJeR0XupRWDFvRCVwoHL+8ne+CLA5N4BLxpkbxexNpShT5YeY1zW1K oFswF7TYXswTug0K1osQEm6JkfUHJJg1bLQ1qBAhS8dBL722dVi0yrXiEYbgy9x3ge kzvyK/JXqLfvPvj4fvjXKa7xqozpP3Rr5tmjIk3gCM3w5I6v1nRbcRsyyfT+1rS9XN xT7zRwWS72Qeob/q4iVOHel74ty6xUX6SlZq+EA/FG60GEHhsYpsnh9sT55ylq7gAp /fn05Bviij8VQ== Date: Sun, 12 Apr 2026 18:46:17 +0300 From: Mike Rapoport To: Peter Xu Cc: David CARLIER , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Andrea Arcangeli Subject: Re: [PATCH v4] mm/userfaultfd: detect VMA replacement after copy retry in mfill_copy_folio_retry() Message-ID: References: <20260331134158.622084-1-devnexen@gmail.com> <20260331200148.cc0c95deaf070579a68af041@linux-foundation.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 Fri, Apr 10, 2026 at 11:26:55AM -0400, Peter Xu wrote: > On Thu, Apr 09, 2026 at 02:31:46PM +0300, Mike Rapoport wrote: > > On Thu, Apr 02, 2026 at 09:42:01AM -0400, Peter Xu wrote: > > > > My point was that this is preexisting bug and that we don't need to rush > > with the complete fix that will extensively compare VMA compatibility... > > Yes, I fully agree it was pre-existing. My guess is we only didn't reach a > consensus yet on how to completely fix it, and whether we need an > intermediate fix for "a VMA suddenly changed to hugetlb" only. Such intermediate fix will keep bug backwards compatibility :) > > > > This is still a footgun, but I don't see it as a big deal. > > > > > > IIUC this is a real bug reported. Actually, if my understanding is > > > correct, we should be able to easily write a reproducer by registering the > > > src addr of UFFDIO_COPY to userfaultfd too, then the ioctl(UFFDIO_COPY) > > > thread will get blocked faulting in the src_addr. During that, we can > > > change the VMA layout in another thread to test whatever setup we want. > > > > > > > Let's revisit it after -rc1 and please make sure to cc "MEMORY MAPPING" > > > > folks for insights about how to better track VMA changes or their absence. > > > > > > No strong feeling here if we want to slightly postpone this fix. It looks > > > like not easy to happen as it looks to be a bug present for a while, indeed. > > > > > > It's just that if my understanding is correct, with above reproducer we can > > > crash the kernel easily without a proper fix. > > > > ... but we do need a more urgent fix for the case when a VMA suddenly > > becomes hugetlb, because that could not happen before the refactoring. > > Personally this is least of a concern to me. Hugetlbfs is so specially > managed in userapps, so it is even less likely to trigger the same bug with > VM_SOFTDIRTY changes or other ways. I'm not sure I follow you here. How changes of VM_SOFTDIRTY can crash the kernel in UFFDIO_COPY? > Again, I'm open to any suggestion on replacing the vma snapshot logic as > long as all possible issues got reported will be properly fixed, especially > in the latest mainline. I don't worry much on backporting yet; if this bug > existed for 10 years and nobody yet reported, to me we can always evaluate > the effort to backport or skip. However, a proper fix in mainline is IMHO > more important. Totally agree, a fix in mainline is much more important than backporting. > Thanks, > -- > Peter Xu > -- Sincerely yours, Mike.