From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 06818C7EE43 for ; Fri, 9 Jun 2023 22:30:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 71C078E0003; Fri, 9 Jun 2023 18:30:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6CC038E0002; Fri, 9 Jun 2023 18:30:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 593788E0003; Fri, 9 Jun 2023 18:30:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 4A79C8E0002 for ; Fri, 9 Jun 2023 18:30:25 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id F09A98038B for ; Fri, 9 Jun 2023 22:30:24 +0000 (UTC) X-FDA: 80884654368.03.0018571 Received: from mail-yw1-f180.google.com (mail-yw1-f180.google.com [209.85.128.180]) by imf27.hostedemail.com (Postfix) with ESMTP id 25F2A40004 for ; Fri, 9 Jun 2023 22:30:22 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=mXAcURqk; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of surenb@google.com designates 209.85.128.180 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686349823; h=from:from:sender: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:dkim-signature; bh=+zT6sV+fvzmgBBI81QXgaF+Btrnt6GH7aWTnX6MCUB4=; b=gYAuSs3hqAkzH1rh9A2VdAQYfezf6Dh6aHBPEwYsfLSh7H3Cs9QV6rIsppFxHW5XZusn2z FoMIEKaVIJVqsKNijkOja3IFQQ0ukUOn/x4RlMayyyg0I8MQ6PTsI/pPu256syBYOBF/1V INBFJCFbiPd6V2S0vJCt7iKh5b5BZg0= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=mXAcURqk; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of surenb@google.com designates 209.85.128.180 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686349823; a=rsa-sha256; cv=none; b=oZkqvne1WtRm0PWFoTVwUdMeFwyQ80YQGdYPKPbh+uM7HWvL/CBNiSVMuz3OfMtQXv2Lr9 Mh11IZCwfM99th9exVGV8A8VTtydRHQ8jWSOfEKTjxFpfz2NGtkzGjtZtdVEmJTr0P6JC3 hB0skKIOfPYw8ETnUPRtAxKSIyucDi0= Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-565ba2c7554so21065457b3.3 for ; Fri, 09 Jun 2023 15:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1686349822; x=1688941822; 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=+zT6sV+fvzmgBBI81QXgaF+Btrnt6GH7aWTnX6MCUB4=; b=mXAcURqk+1SjmifAbWS+rzdBg3sJG/XNRZ8y8ysR8INkOv4gWnF+xs+y+SYfhtf6N/ RUzqMQwHktqLGXnFqUtsvhF5L9vLpFUwvm2N9epG17Y0Vp2wpI7ZrzX8JDonWRmiow43 mX+mucGCdEZRZwBSCuNbliPjS+zKIFFWb9/ic7yJM7pykYyKn+2kH4loCcZKtPEoA1iE lVZoLXJDhsiAM0IcrGBlFgWLUzxo4jWTIDQDnDuTB/9r0dEv+ey0PgmSn+GZP+iXEtW9 SOuHwnTb87WF5tfCuyWfCUydVDBd/5vbNI4gxJKZAzwgeQAoWA573b3Zpk+zJz2L5oom Ryow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686349822; x=1688941822; 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=+zT6sV+fvzmgBBI81QXgaF+Btrnt6GH7aWTnX6MCUB4=; b=PiviimP54OL6+9P3B5aYF4eyFePDD94Ivjcv2H+4rT62GXGq6BRsXecEmjVI9BO2T6 LM7m+L4cN6KkYReRpTpYtOQcMQjAQv64tkdiq1ojkkRL9S5d2UUxJtp0kWECjzknKl1S 2kEBfuC7V+QYKf/oJBidanSX9p9aW1/xTmWNItGVNiF9h7Vr/ZKUqFNAenqzJd/msNwH csR7C4o/J8vUm90s011yDbyJxXvP3HfUtwwEVkr2Y5B9oAbWhPxcY+HdRXH8IV5HZgyl 18Vx/vnqfbM9UJoF60V/eHN1/aQ60qsaa/jfU4HLk8dcI3S9YeNTxySHyToPVLa1WwuK 3m5Q== X-Gm-Message-State: AC+VfDwoz0Xq17azgBSbL4o0f3JluOCtSoB81MaGyn8RdQB1zqpWOnrq qHISiY1WL5HviZ0RaVnIPPEgjJ57k54ESCsHldZJfQ== X-Google-Smtp-Source: ACHHUZ5TZvpX4UfdCUpjEiPqY6QZGnmNogZwNLVZjipLgMlKuWApKPOOPeExrL9FO8ZqBOPgG6jGQ762Win+1tZG15A= X-Received: by 2002:a0d:d8cb:0:b0:559:e1b2:70c6 with SMTP id a194-20020a0dd8cb000000b00559e1b270c6mr2210211ywe.34.1686349821843; Fri, 09 Jun 2023 15:30:21 -0700 (PDT) MIME-Version: 1.0 References: <20230609005158.2421285-1-surenb@google.com> <20230609005158.2421285-5-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Fri, 9 Jun 2023 15:30:10 -0700 Message-ID: Subject: Re: [PATCH v2 4/6] mm: drop VMA lock before waiting for migration To: Peter Xu Cc: akpm@linux-foundation.org, willy@infradead.org, hannes@cmpxchg.org, mhocko@suse.com, josef@toxicpanda.com, jack@suse.cz, ldufour@linux.ibm.com, laurent.dufour@fr.ibm.com, michel@lespinasse.org, liam.howlett@oracle.com, jglisse@google.com, vbabka@suse.cz, minchan@google.com, dave@stgolabs.net, punit.agrawal@bytedance.com, lstoakes@gmail.com, hdanton@sina.com, apopple@nvidia.com, ying.huang@intel.com, david@redhat.com, yuzhao@google.com, dhowells@redhat.com, hughd@google.com, viro@zeniv.linux.org.uk, brauner@kernel.org, pasha.tatashin@soleen.com, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 25F2A40004 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: y9ndwmj1kqwwoqprg8o9gg13xodinoo1 X-HE-Tag: 1686349822-807451 X-HE-Meta: U2FsdGVkX18WzVnzlYFJpMgAvwJLiS1pVKLRs6c9anaYyNQuK+VaStZXtjF6uazfaU66wF4mFQ6SisFmWK9GTOvrphcJX/B6Kp5fF7nMiyJiAhmjN/JMDtxt1fR5R7LSPPzrfAuCWpi/s3221ZkXpLO7Y+sX0aXGhOMVozR3KgsTusm3mLuxCyp/xHSW5rSk9fVILqldHlhouuXnr6r+hFgDdbgSjOdmX9y2KrpWaYP3AzQMsKyi31BUbOpC9xw0H8uyzUuJkXFWieWMaOt+7pG3MIcOl0FvHnSvQEs3168q9g1K+g1fGa7dCMKGH5qF8V8lVUU6jXrmkw8g8cRK4wK9dSEIbMkbnFHzQgH+R7ozyDJki0y1o9TtJBoXMgZYyFJkKjKxfRezMkShEe7SsyBGyykvKZ3Cx731Wiskm6eKVhLr0j8Mq+kBuJmxVRdTHiiL4BKRQXbChjNrpkeouoyrXDr0P0ukXCvwLmeRswqk4YR2exRcJzIckdvGeSWJrdyA9Smdr73cicCFu8U3D5s1cegjJnJSQ/pZukF5IDVMjdmQP9C9w5NOxhRgJNUiHmP9HxlSbOYOYlhh7KNJWfWZoUq38pVUBewmvwrpOKJ2st/TMB3Wagdo30vyrsw8ud/TdXDEoYjayvEnFJlxZZFgavMWuKDMkL7osdXyK3Lc99Ak+uifPlNbY99KOY8cbS5HzYaSq0UoGrRhIP63Xs+QeO2ACSNPWhLwuEASi85/lrf1qk1O2nPLODWSKilA4aaXbw3DXZB6KAfGRAY/AptK4J+e9NNIkCG9OOklQv+YEkPI8I5FAOe/5XVegNStG2Z1FNZWlwULCqpCx9QKsrmxWbv6XToy09ubfZF4YPF2DiuRqHKbVr9QOz3dlbIQZuJs2vCrJHG8vkQBaTEdfK8N1h6AlYO5zSWIs3Abpywz/8/e3i+aGwuIy4xZTH2cmdQ28b69iT3j1827arG OSHNb4J5 82Hx1nsoitloHK32wlte/6WMv05dmjRuRMZZLruZax/6vfOuVq/H/JPMKyf7yk25+2NmRxNSkszSvnb5jCBofIDdA5Xzbzc7LmTUPQJsXzbMzsOwuuqC6/i98pA7CPmrK1BeTdo0fjpZ8rH/Fb4kgjyQoXwbKdZ7BUWP38nZeSBboLbOvI2vcLkVhAogbRB4ToKGi7mHqj4Zn2d+4M14I3r/62nJAjgszS6jMYHZpaW2NLpzjSYt4dkPpIHGy6ZMYP1x7Dt8hM3pgsbTzbQ/OD8qfO3MD2BUagBlp9sABPmwy+KI= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Jun 9, 2023 at 1:42=E2=80=AFPM Peter Xu wrote: > > On Thu, Jun 08, 2023 at 05:51:56PM -0700, Suren Baghdasaryan wrote: > > migration_entry_wait does not need VMA lock, therefore it can be droppe= d > > before waiting. Introduce VM_FAULT_VMA_UNLOCKED to indicate that VMA > > lock was dropped while in handle_mm_fault(). > > Note that once VMA lock is dropped, the VMA reference can't be used as > > there are no guarantees it was not freed. > > Then vma lock behaves differently from mmap read lock, am I right? Can w= e > still make them match on behaviors, or there's reason not to do so? I think we could match their behavior by also dropping mmap_lock here when fault is handled under mmap_lock (!(fault->flags & FAULT_FLAG_VMA_LOCK)). I missed the fact that VM_FAULT_COMPLETED can be used to skip dropping mmap_lock in do_page_fault(), so indeed, I might be able to use VM_FAULT_COMPLETED to skip vma_end_read(vma) for per-vma locks as well instead of introducing FAULT_FLAG_VMA_LOCK. I think that was your idea of reusing existing flags? > > One reason is if they match they can reuse existing flags and there'll be > less confusing, e.g. this: > > (fault->flags & FAULT_FLAG_VMA_LOCK) && > (vm_fault_ret && (VM_FAULT_RETRY || VM_FAULT_COMPLETE)) > > can replace the new flag, iiuc. > > Thanks, > > -- > Peter Xu > > -- > To unsubscribe from this group and stop receiving emails from it, send an= email to kernel-team+unsubscribe@android.com. >