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 D7073175A6E for ; Wed, 1 Apr 2026 19:22:12 +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=1775071334; cv=none; b=S6rNVc1cU0QC+w7sCKDqPxyNDbR0Sy52RjlUadZt/8kFSBWBgxSx3Lb+ObmPsC9YbDzEG3ZjRfhV+qGopJQuQo7/L5whng1cxDudJ5QhASmIGUkXLoZkQ4gYlYWRC9HcVjG6PCKuFdF6o4Tfqy8RQIpZFJu6ShVi69UUMTsHnF0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775071334; c=relaxed/simple; bh=Ai8Vw6PTktmdgUrQliEG7vSHTqoA3GTn83xrvRN8CQI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=q0j4oqxyUvfDbdyp9AVf+ZF4Rwb9EosxnDziOGaLBTXRS0oQXfOJC7pm9TsRAf3YRKOkIN686XEPjKJDfA1mkfptBjD4aSpe/LeGr4ZAn74AWlEVGYIuekGBwo/oMgQFru7fmvHz/d0dWVkgiAICN7GIE+MwDEMCucp4+N37eqk= 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=XUt3fkC3; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=a4E5YDIQ; 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="XUt3fkC3"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="a4E5YDIQ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1775071331; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NJDFokxm2ee0d3XM98QfLETjiOPLsllTVCxCL55zJzE=; b=XUt3fkC3VMTrHl4A0rgwcvdW/Llw1M9trJIknmawkTbTOmHJ9tM4QaWKZg2UxipzuwwJcY mB2+x/rNWy/3/3cg9kx9NxfdDKN2+PhbAAmYN25Odfyp9EU4hqXzSDzqoi77AsmLEjVT5r tXBVzsb+qM7xyOt7ABVMEoeITg/nLuM= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-580-Z4hpG8VyPWuZ0kwC8lIfDw-1; Wed, 01 Apr 2026 15:22:10 -0400 X-MC-Unique: Z4hpG8VyPWuZ0kwC8lIfDw-1 X-Mimecast-MFC-AGG-ID: Z4hpG8VyPWuZ0kwC8lIfDw_1775071330 Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-8cfc648b036so53348785a.3 for ; Wed, 01 Apr 2026 12:22:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1775071330; x=1775676130; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=NJDFokxm2ee0d3XM98QfLETjiOPLsllTVCxCL55zJzE=; b=a4E5YDIQZ71PTtnJC87wciD4klnjxZ5ASJa+1w3SSbJ1RORbHbmXar6DEEuhjAoOd/ 0hslNwDdK3zrwRzQPIP1vHQogoacSeLICJ0VllqUMESeYsbUAFC6PQMZUTiUmGp2dIuR 71JJZj5iM5nJEDI5eJ60BwwRjhZ7cb4y59tTr5Xq6hZwDvmD2sVrlr0MFZK0ED6E5ngX ZHPJ6i78pkQ7nv+cLedEywU1OvE3Mu6I1FEJIvbOHLDUJegE9gH285Qj8C086upbKhq0 NoX5HYGHMzd1fgz24VLMciBnhAzj0uEXeGZ8DSEw1nm9SNnxk3QS3tFtDRNm+5zWBO8r GRJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775071330; x=1775676130; h=in-reply-to:content-transfer-encoding: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=NJDFokxm2ee0d3XM98QfLETjiOPLsllTVCxCL55zJzE=; b=ZXvr3lbD7B071rIjQElUDvyAfyLK1Nj3+B6ljZhsK3U8vnfaO5bJReQqHEzoiAzhEv /hQbQIecXw71+tHniTtl2VAZ0W0mc4KeFrDlUnvbI3/IzmD7GLP5aSfCBdaJ4r43fIDt MTpwwdQkH6c57qkiEMO4S83/el5vephcR0GJ/+1TB12NyBrMkzrMSrDR8FAXBi2WJMS/ Fs77RFfPisjd9F801YSj+gcRMzBMP/iSNeBSgJ3N58LcpGDvOFdpc4fey5+RRCwm6vn6 D7XHFx8h0nj7ymcQtlRUudekHn0w3EyoHhkC1QTjh0Mnq8cXMf1pKv2E91GMTrAwiuRz O3PQ== X-Forwarded-Encrypted: i=1; AJvYcCX7deC0XEMb0QRBSY/x+mfasFQ7WeYsY4qR12ASLj5hjWVCDGJpiT+lTlBsOWt8cszl4xuSdnDlIbE455I=@vger.kernel.org X-Gm-Message-State: AOJu0YyovuzgTgh0iXtXIKrt/i4ztpBRnefZKBg5ZuW8ZXZX/aCcQZyN hT/wS1FBey8n6gayLM4cD5XXEcu/7caZmpmhTtnOB37OYZMp5aG90PPHVlpayiNCBufaCnFvJrR g1sCxCHdORusXE54K3tKQauggWqY8zvlL1L4dMgI5+epfsu9BqmZE/huFItGa8xb4Cw== X-Gm-Gg: ATEYQzzt62Rj5Kc0DajzrXzCKsM6mzYCeI9NjkNQy29YsdroWdGdu7fsZLDwMM6Vhfn Cf+s7v4rUeVzUOaNoTic7uyyYcy+ZvLLKZ8KVKebuyNkwdnLLrG6mYmO1IgYBfjW8HTal5JWNZL p5gl78QEI86tmDBu61TcesDNQYWo5m2r2Akp2lIGyJH+wL0mKZ80O+g4nUMjTG24t8v6PfB+mFb nGgAqQhjhDtT8bmBhUZD4ISkOChbmkHtCyD4K15iM1aE5RSEhvIXc1YHfx/5U2qRBV6A9tMe4YN MkzdyJrW+dMEonnU3stZkeZ72P1OoFKostvWWrCKrHDk07QJcQp3YRYsxnxdXyGCGBNtSBqzgMV ANhGoa7/gJEMozjxG+1R4ubA9NjjiMQab5CM6kFEFEW2r5Q== X-Received: by 2002:a05:620a:2698:b0:8cf:dd63:fae7 with SMTP id af79cd13be357-8d1b5b94ed5mr694372285a.34.1775071325105; Wed, 01 Apr 2026 12:22:05 -0700 (PDT) X-Received: by 2002:a05:620a:2698:b0:8cf:dd63:fae7 with SMTP id af79cd13be357-8d1b5b94ed5mr694366185a.34.1775071324562; Wed, 01 Apr 2026 12:22:04 -0700 (PDT) Received: from x1.local ([142.189.10.167]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8a59323a2d1sm6565296d6.9.2026.04.01.12.22.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Apr 2026 12:22:04 -0700 (PDT) Date: Wed, 1 Apr 2026 15:22:03 -0400 From: Peter Xu To: David CARLIER Cc: Mike Rapoport , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka 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 Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Apr 01, 2026 at 07:34:47PM +0100, David CARLIER wrote: > Hi Peter, > > On Tue, Apr 01, 2026 at 04:23:00PM +0300, Peter Xu wrote: > > IMHO the flags is needed, consider a shared shmem vma remapped to a private > > shmem vma. That needs to be covered in the fix. > > Right, I hadn't considered that case. Shared->private changes how > the > folio gets handled even with the same backing file. I'll keep the > flags > check. > > > Actually instead of reducing checks, maybe we also need to check > the offset > > of the mapping too, that is: vma->vm_pgoff can't change otherwise it may > > also affect how the back store would behave on this UFFDIO_COPY > request. > > > > For that, see the example of shmem_get_pgoff_policy() where it > seems we can > > apply different policies to different ranges of the back store. > > Good point. If vm_pgoff changes, linear_page_index() derives a > different page cache offset for the same virtual address, and > shmem_get_pgoff_policy() could apply a different NUMA policy to that > range. So the folio could end up at the wrong offset or with the wrong > placement. > > I'll add vm_pgoff to the snapshot. So the full set of checks after > re-acquiring locks would be: vm_file, vm_flags, and vm_pgoff — ensuring > the folio was allocated for the right backing file, at the right > offset, > with the right VMA type. When caching the offset, we should likely use linear_page_index() with the address provided rather than caching vma->vm_pgoff directly, then it'll avoid same vm_pgoff while VMA mapping shifted like this: VMA1: vm_pgoff=0x10000, vm_start=0x10000 VMA2: vm_pgoff=0x10000, vm_start=0xf000 So VMA1 unmapped, then the app mappped VMA2 at different VA but still cover the address we're requesting for UFFDIO_COPY, even if the VMA will still have the same vm_pgoff, the VA to access the same offset might change. Using linear_page_index() will be accurate, IIUC. 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. Thanks, -- Peter Xu