Received: by 2002:ab2:7a55:0:b0:1f4:4a7d:290d with SMTP id u21csp313369lqp; Thu, 4 Apr 2024 14:08:08 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCVPdUOzXximsDPZSdZ7XkHvxHr1g4MYxoHEiGbL64QMhelno35VCnHatnfz/lTpnLogjmqj3T3IBkb3X01oWExi8qv5OTzko0XmdCzpJQ== X-Google-Smtp-Source: AGHT+IEqvsykmQPq2mc8Wy5H2srjO3PZhnrYNZKS1H2CB57Onvr0tOxwpfkPUO7UXRisfEMgxi7j X-Received: by 2002:a50:d653:0:b0:56e:2db0:c7b6 with SMTP id c19-20020a50d653000000b0056e2db0c7b6mr111466edj.42.1712264887837; Thu, 04 Apr 2024 14:08:07 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1712264887; cv=pass; d=google.com; s=arc-20160816; b=Ko9Cl0w7q7kiSYnCLfbNmDj55LZNrOz8092qfk8nOQSxPMuTbAMofZkm4bmhc2BKSa RgGCrMdWOB513xWXpBM9B8H39pjki/uhQSL/J9c8sabN4AzMgZcZbcjsjasHMoZVm5dz a1TX61+js2MWQ5403vFqcmifDRl2efGGetLH1EPYAAjswqz8nrSOD5dFPmc0l9YK9xvz 2Y+cRn5mlIvtE4RevvxG3V1i+EOiasX68b1bR1lFMxknFceoPasLjdtjMJUCZLi1Z/EL yEohtzacjN4mbQ/BchfbJO0LFr+zRE8JpiVRcKhXQ8nKiTOPB/5pL4D7xeCyV3bbhe/8 TXGg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:list-unsubscribe:list-subscribe :list-id:precedence:dkim-signature; bh=GEPgxv5jO+a3XFdTbHPF5Q9T9DAeBlFJtTQ1Lr368bE=; fh=oc8/RtXW07ArJ/9WQ9K2IZ7RDX+/tlpoIBM0JbP+gKo=; b=onZ63/Q6OnFfVptA94xshLfn20YqIP7OHetGTJc67knac59KdRX+4bQszCI/pzVbcE Bzte6t4tXHB+09ajRNgtA1UFxz/BJLOHSZTT3gLZYtjjkm901XYeywpDu+3nFonzAvvk kJgR3E440VaXHkuGl0VYBVF9VZBNcNa7h232Dm5yrrjLaR6ZUmp4mHWI/ZGFL2er2saU iSI0hauQfl7jPoms2HqXgFVinpEGx0DApCcvxojwSJ4PUgZ12Ov2nd9KTMhs5QKwpQwB 3apIOxDIh3UWD1oGXpp99Hh0HgBCb+tyoB5qSLty7Th8JPhzXdpRUw+skK6lafnqNDlw 0mhQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=lbp2U1Zc; arc=pass (i=1 spf=pass spfdomain=google.com dkim=pass dkdomain=google.com dmarc=pass fromdomain=google.com); spf=pass (google.com: domain of linux-kernel+bounces-132121-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-132121-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id i13-20020a0564020f0d00b00568b5d11acesi43094eda.82.2024.04.04.14.08.07 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Apr 2024 14:08:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-132121-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=lbp2U1Zc; arc=pass (i=1 spf=pass spfdomain=google.com dkim=pass dkdomain=google.com dmarc=pass fromdomain=google.com); spf=pass (google.com: domain of linux-kernel+bounces-132121-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-132121-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 687F21F2268C for ; Thu, 4 Apr 2024 21:08:07 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5119C13AA4C; Thu, 4 Apr 2024 21:08:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="lbp2U1Zc" Received: from mail-yw1-f172.google.com (mail-yw1-f172.google.com [209.85.128.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 89F8C12D1EF for ; Thu, 4 Apr 2024 21:08:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712264882; cv=none; b=Px28wkvkjpet8pmmHBh1q+HJ3gIsvGOSJm2w94pEpilbEopfAzvgnAXBHp9wIvNltxhF4oIX+ql4i+6clCkKHh2QTC6hpO4JIwYB22SuqY7+P9xQE03f2kLeS+YOOfVpC7GhefPYa5bwkNSPAjV3LOh6BXb/ei4EQ8OzomZ9XO4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712264882; c=relaxed/simple; bh=jiPmv7P0Zt+7AyXesKeCak2Yp5DYXGginccDd9ut1dE=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=f5H2mOYete+C1kVK8AotRfT4Yuq3lsLdwWgZj11Q9YlFQ2XNsxHFRekhonN112snBzcqW9EWtyGH+WGyv29VrMGc/gJC/U1FegCPszvaAli2KHXwS3eqTp/hAysswWUew70LweX5GXv233XYsKptLAsSTojwI8ltprgm2wu0DwE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=lbp2U1Zc; arc=none smtp.client-ip=209.85.128.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-6151d2489b4so17028237b3.0 for ; Thu, 04 Apr 2024 14:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1712264879; x=1712869679; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=GEPgxv5jO+a3XFdTbHPF5Q9T9DAeBlFJtTQ1Lr368bE=; b=lbp2U1ZcPqsSPnTX9rIjuOSfO+NYSkJA1B4uPxFuFENz7Ir9o4W9/W4Z865Cj5Z/7J 2rGXpoBR0lXVSMbkX04RHhXVP+RajHrwtEm79Cojg9B5b2IazbdhkOlI2mSwZMrcH6YA A9qogcgT/cRyRUVSiuLxB0vv9vR2is4+icrbzJOprJOrHj8M3/Vhv8CMAYBlRBl4J8y0 KTMfeIUUTCg4h1Ll9xxlz1lHMR0Q9E0ByfM4p+AdMZT5/6OSt4+69opzCQaUVsJ/qUBG 2mOBt6aSy9aSpWd1QvixhaH9nwWfwd2YlouyFe5FS+7fQ8YW5rqC6p09iMehDUuOatge O9QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712264879; x=1712869679; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GEPgxv5jO+a3XFdTbHPF5Q9T9DAeBlFJtTQ1Lr368bE=; b=gpJ6GCRh+eQoTk9bP5vp243f8REu/ISkWcVKy1SpTwBa6mb7cPV24t8PFv8NcF/K26 7XQhSHsdm5t1wAPU2JiUbIauoyon+Ml5FiPyzrmYU5HU82oB/A/BMWWdekr3dMT8JmTj yOPaFYAfvNScAc3InY6Cmkb8nUF0RcVI0/wq9p5kXPQgmwRt5hLcy2n+6eueDRL4VS5i Prylv7Q3mXpyz+wJ8NfHvTJEb501K5J2Pk7yu392Qoi2pmVEJDosn9OTrnlu3MNQzZm4 +7sZdn1KJDmAzdWtggbhejlavO27ZG3DNxKnnmadjxwshn5EivEcKWCBMRmDJCAwHXNz kfWQ== X-Forwarded-Encrypted: i=1; AJvYcCXSg5zseTADkp+roEugKAWVQDNKoyFb9UNz5XjJHSz4cxFjC2wkfKWtqmnNw1t7gvtDw/QXQvRbemK7DauodowsB2lEDsZagYRJh/aC X-Gm-Message-State: AOJu0Yys2qlFGkhRizhLH+Qb2nXNrNv5e7oWxbiphYxBpkVqcgViMQGC 2jBYtIzJ44UmFzk5vpP2VgBJIdSloZCMsgMgz4uTfaFPhhYoDCcpY4tJ3neaQK8yEo20CqOgFI1 xwRwOyVJAkxxtUju2xal1dZsPtlRrBrcN/Zwp X-Received: by 2002:a25:ea53:0:b0:dca:e4fd:b6d6 with SMTP id o19-20020a25ea53000000b00dcae4fdb6d6mr3005124ybe.61.1712264879294; Thu, 04 Apr 2024 14:07:59 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240404171726.2302435-1-lokeshgidra@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 4 Apr 2024 14:07:45 -0700 Message-ID: Subject: Re: [PATCH] userfaultfd: change src_folio after ensuring it's unpinned in UFFDIO_MOVE To: Peter Xu Cc: Matthew Wilcox , Lokesh Gidra , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com, aarcange@redhat.com, david@redhat.com, zhengqi.arch@bytedance.com, kaleshsingh@google.com, ngeoffray@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 4, 2024 at 2:04=E2=80=AFPM Peter Xu wrote: > > On Thu, Apr 04, 2024 at 01:55:07PM -0700, Suren Baghdasaryan wrote: > > On Thu, Apr 4, 2024 at 1:32=E2=80=AFPM Peter Xu wro= te: > > > > > > On Thu, Apr 04, 2024 at 06:21:50PM +0100, Matthew Wilcox wrote: > > > > On Thu, Apr 04, 2024 at 10:17:26AM -0700, Lokesh Gidra wrote: > > > > > - folio_move_anon_rmap(src_folio, dst_vma); > > > > > - WRITE_ONCE(src_folio->index, linear_page_index(dst_vm= a, dst_addr)); > > > > > - > > > > > src_pmdval =3D pmdp_huge_clear_flush(src_vma, src_add= r, src_pmd); > > > > > /* Folio got pinned from under us. Put it back and fa= il the move. */ > > > > > if (folio_maybe_dma_pinned(src_folio)) { > > > > > @@ -2270,6 +2267,9 @@ int move_pages_huge_pmd(struct mm_struct *m= m, pmd_t *dst_pmd, pmd_t *src_pmd, pm > > > > > goto unlock_ptls; > > > > > } > > > > > > > > > > + folio_move_anon_rmap(src_folio, dst_vma); > > > > > + WRITE_ONCE(src_folio->index, linear_page_index(dst_vm= a, dst_addr)); > > > > > + > > > > > > > > This use of WRITE_ONCE scares me. We hold the folio locked. Why d= o > > > > we need to use WRITE_ONCE? Who's looking at folio->index without > > > > holding the folio lock? > > > > > > Seems true, but maybe suitable for a separate patch to clean it even = so? > > > We also have the other pte level which has the same WRITE_ONCE(), so = if we > > > want to drop we may want to drop both. > > > > Yes, I'll do that separately and will remove WRITE_ONCE() in both place= s. > > Thanks, Suren. Besides, any comment on below? > > It's definely a generic per-vma question too (besides my willingness to > remove that userfault specific code..), so comments welcomed. Yes, I was typing my reply :) This might have happened simply because lock_vma_under_rcu() was originally developed to handle only anonymous page faults and then got expanded to cover file-backed cases as well. Your suggestion seems fine to me but I would feel much more comfortable after Matthew (who added file-backed support) reviewed it. > > > > > > > > > I just got to start reading some the new move codes (Lokesh, apologie= s on > > > not be able to provide feedbacks previously..), but then I found one = thing > > > unclear, on special handling of private file mappings only in userfau= lt > > > context, and I didn't know why: > > > > > > lock_vma(): > > > if (vma) { > > > /* > > > * lock_vma_under_rcu() only checks anon_vma for priv= ate > > > * anonymous mappings. But we need to ensure it is as= signed in > > > * private file-backed vmas as well. > > > */ > > > if (!(vma->vm_flags & VM_SHARED) && unlikely(!vma->an= on_vma)) > > > vma_end_read(vma); > > > else > > > return vma; > > > } > > > > > > AFAIU even for generic users of lock_vma_under_rcu(), anon_vma must b= e > > > stable to be used. Here it's weird to become an userfault specific > > > operation to me. > > > > > > I was surprised how it worked for private file maps on faults, then I= had a > > > check and it seems we postponed such check until vmf_anon_prepare(), = which > > > is the CoW path already, so we do as I expected, but seems unnecessar= y to > > > that point? > > > > > > Would something like below make it much cleaner for us? As I just do= n't > > > yet see why userfault is special here. > > > > > > Thanks, > > > > > > =3D=3D=3D8<=3D=3D=3D > > > diff --git a/mm/memory.c b/mm/memory.c > > > index 984b138f85b4..d5cf1d31c671 100644 > > > --- a/mm/memory.c > > > +++ b/mm/memory.c > > > @@ -3213,10 +3213,8 @@ vm_fault_t vmf_anon_prepare(struct vm_fault *v= mf) > > > > > > if (likely(vma->anon_vma)) > > > return 0; > > > - if (vmf->flags & FAULT_FLAG_VMA_LOCK) { > > > - vma_end_read(vma); > > > - return VM_FAULT_RETRY; > > > - } > > > + /* We shouldn't try a per-vma fault at all if anon_vma isn't = solid */ > > > + WARN_ON_ONCE(vmf->flags & FAULT_FLAG_VMA_LOCK); > > > if (__anon_vma_prepare(vma)) > > > return VM_FAULT_OOM; > > > return 0; > > > @@ -5817,9 +5815,9 @@ struct vm_area_struct *lock_vma_under_rcu(struc= t mm_struct *mm, > > > * find_mergeable_anon_vma uses adjacent vmas which are not l= ocked. > > > * This check must happen after vma_start_read(); otherwise, = a > > > * concurrent mremap() with MREMAP_DONTUNMAP could dissociate= the VMA > > > - * from its anon_vma. > > > + * from its anon_vma. This applies to both anon or private f= ile maps. > > > */ > > > - if (unlikely(vma_is_anonymous(vma) && !vma->anon_vma)) > > > + if (unlikely(!(vma->vm_flags & VM_SHARED) && !vma->anon_vma)) > > > goto inval_end_read; > > > > > > /* Check since vm_start/vm_end might change before we lock th= e VMA */ > > > diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c > > > index f6267afe65d1..61f21da77dcd 100644 > > > --- a/mm/userfaultfd.c > > > +++ b/mm/userfaultfd.c > > > @@ -72,17 +72,8 @@ static struct vm_area_struct *lock_vma(struct mm_s= truct *mm, > > > struct vm_area_struct *vma; > > > > > > vma =3D lock_vma_under_rcu(mm, address); > > > - if (vma) { > > > - /* > > > - * lock_vma_under_rcu() only checks anon_vma for priv= ate > > > - * anonymous mappings. But we need to ensure it is as= signed in > > > - * private file-backed vmas as well. > > > - */ > > > - if (!(vma->vm_flags & VM_SHARED) && unlikely(!vma->an= on_vma)) > > > - vma_end_read(vma); > > > - else > > > - return vma; > > > - } > > > + if (vma) > > > + return vma; > > > > > > mmap_read_lock(mm); > > > vma =3D find_vma_and_prepare_anon(mm, address); > > > -- > > > 2.44.0 > > > > > > > > > -- > > > Peter Xu > > > > > > > -- > Peter Xu >