From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 1CBD23D8908 for ; Fri, 10 Apr 2026 15:10:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775833847; cv=none; b=AxvzYHhRYjoC7Vt5p3WVU7wITfyOi1IeCCy+NAtbFlhsNGJ02wJnU6SEiKneOARiVT98NeuzXB0zGkeQOLfdqLO9gFd46IoOSnChvt3XOiSPrXKHWyB2DpUUJT0lXEypaOtX5qI3COtOd8vxQRBTR6S0NU8obyQwoeA5TZfv0SQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775833847; c=relaxed/simple; bh=/wZG1v+CZNK1oPO7RvcwkTV8NRxAE8axVw+A7U1NqvQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=P2HYp3GxyGdCeuxcwrLB0PYkEtJQ+PgXGj8zRgq8B29mk/jzrgHPw5pnzJI9Q7Zj4yEIlISoPLWCGmJpRVFA/gMtH+wyHmYzFIe51nVO72q8LT/PFOJTofJqvHB74K20fgP59kz3iN+7Efk4WG7uDF/dNv9hSzXOyBdx8BJiA3k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=U+DdFFfw; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=Vk9zoKSS; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="U+DdFFfw"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="Vk9zoKSS" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1775833845; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8stZD1NXshBl5ISaPS+qdCkgKdq+t5Tds8HTfykQxsM=; b=U+DdFFfwBu4Up0P/VtMnAxQQu914nFV++wkR02kqkPV7Go4gL6aFZTTFLlCV8Ze9sS880j z1U/zGyInHu5u4kcGQf3P2GIL/tm7kMEU1xraWNhxMLrEPb9HlXp1WGnqt2425+XBjk8F7 oAKWLE6sT+qodYTOy/m6H8G2S84p2ro= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-596-nvXY_pdCMfaNAVzLgPkY-w-1; Fri, 10 Apr 2026 11:10:44 -0400 X-MC-Unique: nvXY_pdCMfaNAVzLgPkY-w-1 X-Mimecast-MFC-AGG-ID: nvXY_pdCMfaNAVzLgPkY-w_1775833843 Received: by mail-qt1-f200.google.com with SMTP id d75a77b69052e-50d68dbb77bso3494781cf.2 for ; Fri, 10 Apr 2026 08:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1775833843; x=1776438643; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=8stZD1NXshBl5ISaPS+qdCkgKdq+t5Tds8HTfykQxsM=; b=Vk9zoKSSM84eYvfIhcT69bt0uBOtJaR8X8sRiDU3UzeBieIQeUAJHynOCK4BSWGAZY LXMHFO6JoFEqxvhszBFJm00QG2rzRpiYr7CSO3GgXRIkwhyIQ3Hj0UMaA0krDVqp3vQy YYbfH1OLPKUarTwac8+w8JjlQU9lDCdOkA5EyuUNALt9FSbuyD+qz4Ey5vCu5svvqtqQ hOuT2BOADV6/rXvP843qvF+qVji80/jmWwBrA45jwM22p4gLkVNoiOk/NqH2Q+2m8KHc JhhPZtrBu78ZSUYSldMYHdxQ3vCVxxk1hUXKNLeQWZrF4aA/6IHFiGNGVGf7lEiRN5NK SNLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775833843; x=1776438643; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8stZD1NXshBl5ISaPS+qdCkgKdq+t5Tds8HTfykQxsM=; b=r6fuFtIjrIAqm9ScKtVcKXFvu8/cUuMFj5YBCwIroWe/vT3Fw1JT66uqx/5jRzEUSw Hym8YyP5mvHqv8RBpnOQGFXrFB6A8Ryh2vQk1gnZlTJ1v34v81gJOINDZxeGcuNzewxO MyVjtm/Ql/2RPnT0jfP3wrM0JAhrzZJqyEz0VDTnuJWWZ0Y2BHRWQNT1UNrAvv3k6v8l S38LfpYlMsYVJDp/QfSZZ9439f8QCjl6zMg2CA89k5GDzevmi7Djmm1fglSHXgxdi1eb PE+xXRd6PfgL+rtv3rWFfBtJOp4z4DDOK8CS3QtcHl8/fqVTUUBZMv4ghbkGgAdNypc/ 3ghQ== X-Forwarded-Encrypted: i=1; AJvYcCVRQhqLOJRGCayfWCErWJJjyuV9vaxEVcwRowHC3mB9cuMDnA/iYOc44fwbyS5SDG4mwiss6iJmva9c8KM=@vger.kernel.org X-Gm-Message-State: AOJu0Yzfa8EIXn0XxwFGypd30qPkl+SegU6K0hyNyP0O75cvraejbWG5 OHFRJXYFR95lPVtv3A4Imj2eSWMBglTQr1n/iZYowKATGzL+AHF5OSMLCUZtX1ObEmRCfR/EDBp 9d9aaRxcBdl8MJ5975KJGNSqVqrmZHalFF8jtHu6GJEXA8MAeZqbTJ8OoASM520wkeBfbiStpAg == X-Gm-Gg: AeBDievOMVdPhODoHUZdMNiJRgPh542trLNiz/m4TuvuElpzHCKGtRyyjPJD1rxTA06 t+mBCzqS3ofkXHLV4qRDIJjQjrR0KSwACSFnSzfaPXrIcBhXSSQ9GkNzsi1rHNWaNM/WsheUkq2 GHDH6Skn8U7jXtjZXPJotSbKbPdz6HEVisZtVXj8KRlfCe7P+8For5k77iQ/YfxrIPoe4Gr/GOI AZXwa1dW/+azRA6V9GUeaT43Vq2VyQ3oQ4Rh0wWf98za0X8z+5jQt0X1dN66EqEb0fw9srFokSp MGpQFDdIICiQ/5cBMdGQxk/wtvNVkfIVC2UAZpUZ1/fyXY1B+AKy90DLsi92JSmTQyPNR7Voze5 wrf0zSqQelw1v9sVEDyiQsgOgHiL84quAO4wSv1EPNyZCPmg= X-Received: by 2002:a05:622a:13c9:b0:50d:6f16:390a with SMTP id d75a77b69052e-50dd5bcdc2emr49687791cf.34.1775833842680; Fri, 10 Apr 2026 08:10:42 -0700 (PDT) X-Received: by 2002:a05:622a:13c9:b0:50d:6f16:390a with SMTP id d75a77b69052e-50dd5bcdc2emr49687191cf.34.1775833842092; Fri, 10 Apr 2026 08:10:42 -0700 (PDT) Received: from x1.local ([142.189.10.167]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-50dd550036fsm22357601cf.21.2026.04.10.08.10.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Apr 2026 08:10:41 -0700 (PDT) Date: Fri, 10 Apr 2026 11:10:40 -0400 From: Peter Xu To: Mike Rapoport 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=utf-8 Content-Disposition: inline In-Reply-To: On Thu, Apr 09, 2026 at 02:20:15PM +0300, Mike Rapoport wrote: > On Thu, Apr 02, 2026 at 09:29:56AM -0400, Peter Xu wrote: > > Hi, Mike, > > > > On Thu, Apr 02, 2026 at 07:02:40AM +0300, Mike Rapoport wrote: > > > On Wed, Apr 01, 2026 at 03:22:03PM -0400, Peter Xu wrote: > > > > > > > > The other thing is I just noticed the err code was changed to -EINVAL for > > > > snapshot changed cases, sorry I didn't follow previously as closely on the > > > > discussion. I think it should be -EAGAIN. It's because the userapp can't > > > > resolve -EINVAL failures and app will crash. In a VMA change use case, we > > > > should return -EAGAIN to imply the app to retry, rather than crashing. > > > > > > No. The return value should express that the VMA is invalid. -EINVAL could > > > work, but looking now at the manual -ENOENT would be even better: > > > > > > ENOENT (since Linux 4.11) > > > The faulting process has changed its virtual memory layout > > > simultaneously with an outstanding UFFDIO_COPY operation. > > > > The VMA changed, but it doesn't mean the UFFDIO_COPY becomes illegal, am I > > right? > > I don't think that "munmap + mmap + userfault_register" > during an outstanding UFFDIO_COPY to the same range is, hmm, the smartest > thing to do, and I think aborting the outstanding UFFDIO_COPY in such case > is better than allowing it to continue. It doesn't need to be unmap+map+register. As mentioned below, I believe writting 4 to clear_refs will already change VMA flags. There're also many other ways to change, IIUC, like mprotect() on top of uffd MISSING registered ranges. Meanwhile, I also don't think it's about whether it's a smart move.. I agree most apps shouldn't do complex operations on VMAs when having userfaultfd involved. Said that, IMHO the whole point of kernel uAPI is to make sure it works with every (even malicious) userapps, and it shouldn't crash kernel. So even if the reproducer will require complex VMA setups, we should still close the gap. > > > For example, I wonder if it's possible someone runs soft-dirty concurrently > > with userfaultfd, we shouldn't fail the userapp if there's a concurrent > > thread collecting dirty information, which IIUC can cause VMA flag changes, > > and should be benign, and I think there can be other things causing the > > interruption too. > > Right, we shouldn't fail if some of the VMA flags changed, but we are > talking about of complete change of the mapping, with potentially > completely different backing store. I don't know how to define "complete change of the mapping". Here, IMHO what we should do is to be strict on vma checks, either using the vma snapshot or anything that can achieve the same goal, then returning -EAGAIN is the safest because it won't crash a good citizen userapp. The re-evaluation will only be done later. Thanks, -- Peter Xu