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.129.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 848C831D381 for ; Thu, 2 Apr 2026 13:42:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775137335; cv=none; b=OXIsejrN5aagGySNSzsQOA5TnV3f0e/leY4kxzInnvuj9p/bT6qbMKL3siQFa2yCDf9Yuk7+LbsEVih0wRT+cyxc4EuGHEqRqNGwIws6AbMe7DzNlqJMVUB+HrRU3jt2cRlpyLLSOS7dpM9X3OVutS8NS3Q4jIWZO6X9dCL4EBg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775137335; c=relaxed/simple; bh=35Dbk985Ik1rp38Wow9bRy62i2Kmilk833lAyAEsB6A=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Z9PIKfjbzoyAJ4szDSeRjSnLCH5m2PxxXs3YzzHgQZqb2dAcUgZwMmCelDcKmBDRO9w1qHaIZSn7QwJelMV7m58OjF/5ERbL5xamfutg6sykSn+GH60205p6W+3wSBxvH290s0NumC2oHoYv/RYjcZxewtAMwYhEc3t28seGFp8= 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=L+jZ8PMp; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=nZg8WsyZ; arc=none smtp.client-ip=170.10.129.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="L+jZ8PMp"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="nZg8WsyZ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1775137333; 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=yWfsa/6+96oHTl9AiAyQHghAoNdpYCmhSqZ3pWlb3YA=; b=L+jZ8PMp1jGDqnM6wJVazpxgk7xFRL7m4D0XzyntF9bV6bPftV+oBpIWFfmD2SQBNtgA+6 N3VgZrroVTzd0G7Lw5WO33pGQ0qiV8dj+eba3LZNOzlA8F0f+uQD/cHc/r3qiyrhjBfAUv oiVu+0EYTurfdIAccqVBeKzsSu+q1Gg= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-259-T0vu0AEaPPa7UOUrOFzDZA-1; Thu, 02 Apr 2026 09:42:07 -0400 X-MC-Unique: T0vu0AEaPPa7UOUrOFzDZA-1 X-Mimecast-MFC-AGG-ID: T0vu0AEaPPa7UOUrOFzDZA_1775137324 Received: by mail-qv1-f69.google.com with SMTP id 6a1803df08f44-89ffce20deaso44300956d6.0 for ; Thu, 02 Apr 2026 06:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1775137324; x=1775742124; 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=yWfsa/6+96oHTl9AiAyQHghAoNdpYCmhSqZ3pWlb3YA=; b=nZg8WsyZx1BBO6/kdFooXlF4Zy1mkLM8nWoDrp2rsG9TzlD0SSlF1EoymHbgiKsJ7z ZfkohhmQ+LFT89fHRcfqjbh3b3EckHB6qChm/2NIz/e3m9UEWnjEA3NY9HQSVXIhQSxP /6m/4tN6zQAETFcKizhUtO389t6bBlo8aJ42/JLd04FKTkoERZQONhLnLgoSpp0V3ccW 7sUVvJk/bvDEA0ZchH3jfvyqZFMRpu0Crb9FNtrEbaRCYWrrKZZDu7+VI/0WRekEe/EM EGF/tHPf8CQ7jh4XV8Ftg+wKpwLbsmehZuMrETgKJQ0O25IpV1k3knGgpbetOwxfRx5L 206w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775137324; x=1775742124; 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=yWfsa/6+96oHTl9AiAyQHghAoNdpYCmhSqZ3pWlb3YA=; b=TD7XvswyrHr06M7wallwj7VbTCCpWWlu10NGqoCop14OuNu7VXzKjd0JtqHYXUClx/ +++F4EnEM9vMzdUddtLNYqz0wGvlQz5eB2qKfa9A2NZP/R3PYCUbjx3d7+pOmLOVI3bS WXxPcAmCkVUg/aj0OjXCjuA65IcKThrGFfUJUwz2z/keB5oPOXTjBjK/WvNl1I6loSn4 dI+1X6R5lZzV48Qhqh2T6r1Env39GrPOJWjrrVHDeDTE8h4PZsCdCr/Pej+sQcFV3LhW Cuuh5jOUUNuM0boXl1zgK2r8LyZ+Bb3euVu2wV7DczKHMBNPQHlAIIXQ4His2WDIDG8m 818w== X-Forwarded-Encrypted: i=1; AJvYcCXMN6gQkDz2VW0o4JFwHrleZcWAv1egGHoaF65MMr1SKNU8pBC899fuRovP+ZtIzU8Y3R6801aA390Ud/I=@vger.kernel.org X-Gm-Message-State: AOJu0YyFe2Iq6/SoqzjvUSSY77z/V3tx73F17h2c/jqwHZs85bcCAomi bqUl7edSXgv6HI6IFAocNroWyfCwyyYv/ncBix3xYjQe8UbAiScVwIPsmIa4z3TwU7lkc19LXat dAk7RTPi/mJp67V29gw7OdT5YFwOQwgDNHceJE6SGXP0BgEQE5IDUu6gINVVLRCha5A== X-Gm-Gg: AeBDievK0Va+M3ywGdcmkGfJuUW3j7fpw3ga5Hk2ztQHvKacuhwnRHZVFqE2U+WxcrQ wTEaLPugWwNus515Q7AeLPjotG275hAlqH4gjSDVt/oUnzjwz9Ai190L8+7cpee/KMwYES/jQF+ JvbT5v8Bxoy7jXgLV9fFSK4QVZZ2cvZkeN0tgdDn+t8LTNs6fw53Gj+JMa4E5bkg0lHzY1Ib0tj 8zLyy2uiJcELvLkZ1fnE0wDOvaf3KLA2SRnSyy5G/0WtNWVRLPZCtA5UQEST3CziJOIVJLMYBFw CrMwm4sTm/XIQtjh4HXV/upRSXzFUoeLVZ6FNkftNr5x22ooE3j2viqJk78bFYQVvaEqiocKLVS tvuiIirk4vpVJDn11BmuaqwPblbhUXa2raKokP0m1O8NBLw== X-Received: by 2002:a05:6214:300e:b0:8a1:8ddd:e12d with SMTP id 6a1803df08f44-8a43aa44c2dmr109661866d6.59.1775137323616; Thu, 02 Apr 2026 06:42:03 -0700 (PDT) X-Received: by 2002:a05:6214:300e:b0:8a1:8ddd:e12d with SMTP id 6a1803df08f44-8a43aa44c2dmr109661226d6.59.1775137323022; Thu, 02 Apr 2026 06:42:03 -0700 (PDT) Received: from x1.local ([142.189.10.167]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8a596915986sm25665836d6.24.2026.04.02.06.42.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Apr 2026 06:42:02 -0700 (PDT) Date: Thu, 2 Apr 2026 09:42:01 -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 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: Hi, Mike, Let me also leave my comments inline just for you to consider. On Thu, Apr 02, 2026 at 06:58:33AM +0300, Mike Rapoport wrote: > Hi David, > > It feels that you use an LLM for correspondence. Please tune it down to > produce more laconic and to the point responses. > > On Wed, Apr 01, 2026 at 09:06:36AM +0100, David CARLIER wrote: > > On Tue, Apr 01, 2026 at 08:49:00AM +0300, Mike Rapoport wrote: > > > What does "folio allocated from the original VMA's backing store" exactly > > > mean? Why is this a problem? > > > > Fair point, the commit message was vague here. What I meant is: > > > > mfill_atomic_pte_copy() captures ops = vma_uffd_ops(state->vma) and > > passes it to __mfill_atomic_pte(). There, ops->alloc_folio() allocates > > a folio for the original VMA's inode (e.g. a shmem folio for that > > specific shmem inode). > > I wouldn't say ->alloc_folio() allocates a folio _for_ the inode, it > allocates it with inode's memory policy. Worst can happen without any > changes is that the allocated folio will end up in a wrong node. For shmem it's only about mempolicy indeed, but since we're trying to export it as an API in the series, IMHO it would be nice to be generic. So we shouldn't assume it's only about mempolicy, we should rely on detecting any context change and bail out with -EAGAIN, relying all rest checks to the next UFFDIO_COPY ioctl done on top of the new mapping topology. > > 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. > > > Then mfill_copy_folio_retry() drops all locks for > > the copy_from_user retry. After mfill_get_vma() re-acquires them, > > state->vma may now point to a replacement VMA, but ops is still the > > stale pointer from before the drop. > > And this is a bug in my uffd refactoring, and it needs to be fixed ASAP > with a simple comparison of old ops and new ops. > > > > Second, I have reservations about vma_snapshot implementation. What > > > invariant does it exactly enforce? > > > > The invariant I was going for: "the folio we allocated is still > > compatible with the VMA we're about to install it into." Since > > alloc_folio() allocates from the VMA's backing file (inode), checking > > that vm_file is still the same after re-acquiring locks ensures the > > folio matches the inode. > > Again, it's not that folio matches the inode, but folio is allocated using > the correct mempolicy. > > > The vm_flags comparison was a secondary guard against permission/type > > changes during the window. > > Permissions should be fine, they are checked in userfaultfd_register. > Some other flags that don't matter to uffd operation may change during the > window, though and then a comparison of vm_flags will give a false > positive. IMHO false positive is fine in this case when -EAGAIN will be used (which I still think we should), if it only causes a retry. Thanks, -- Peter Xu