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 3B867C88CB2 for ; Mon, 12 Jun 2023 15:41:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A89898E0006; Mon, 12 Jun 2023 11:41:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A3A368E0002; Mon, 12 Jun 2023 11:41:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9013B8E0006; Mon, 12 Jun 2023 11:41:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 7E2348E0002 for ; Mon, 12 Jun 2023 11:41:51 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 54A481C7A30 for ; Mon, 12 Jun 2023 15:41:51 +0000 (UTC) X-FDA: 80894511222.10.F5EF550 Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) by imf23.hostedemail.com (Postfix) with ESMTP id 64B6414000C for ; Mon, 12 Jun 2023 15:41:49 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=A41ks5sF; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of surenb@google.com designates 209.85.219.169 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=1686584509; 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=kbcWWy6lgJlv49u77NIuToLcJ7w9+T3qZB5UWslqyxQ=; b=h0nc4U8140GDHa1VBSYlNQiV/z6YDV+XwUItuV9XDl99GXrZRun7OwGFziiuJJxMHk2dyy 7rqBCFhWyd/eXM+qxeTyUgi/tKg4ZZK2rLjaPhzFKU9wk9IccTDh79Z5/FQ2vmYfeblEVp TDK1badGfzARtVVuYeB6gCKU+vKE09I= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=A41ks5sF; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of surenb@google.com designates 209.85.219.169 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686584509; a=rsa-sha256; cv=none; b=0O5EZ1VJId2CEgmVanJeBXQu72bUwFDwpEfOTcnt2RrPfWQWlnNagF5rOLGUqUJe6KtYVz wnBQpIXE7DH/odVHnBYGR8Ubpj4dAHaZfU5FJ3qpQ6sBVTDxf6xnokusmIkudgwPovqpjD 2Lro1qwrKRDzmNvPOZy5xHo61qRcFrk= Received: by mail-yb1-f169.google.com with SMTP id 3f1490d57ef6-bcad7f7dabcso811946276.0 for ; Mon, 12 Jun 2023 08:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1686584508; x=1689176508; 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=kbcWWy6lgJlv49u77NIuToLcJ7w9+T3qZB5UWslqyxQ=; b=A41ks5sFHka57K4fqfE86JUZi8sVGCoTPYI5ynNaLuhHWaVD5wnyI5E/THeG9ezv9h hFUN9NeXdSmdLTfV6cU6RhW6ixeXdJmtNq2y0OhafeE0g900sSc3BM37utl2iCvyu3pS xxfgQmQbYso5DjWghSSS8E/l89+tAaOV68U9KiGP2g9j1jE4hB6T8R6++UPP4RumZMV8 LAmAF8KoJr8GavbZrW2RE1zZc3QKRPJhjcCzs5R0EgwiMcU56m0L3HM4XYn+eViUJpyI 8vqYxeegj//ny6HzAJhC8KTZYUOxcFLk2OUJoaoVW3wydskZ3x20ve8D1Xwk+AB12dwu q0mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686584508; x=1689176508; 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=kbcWWy6lgJlv49u77NIuToLcJ7w9+T3qZB5UWslqyxQ=; b=hy1L9Kl8qbZ/3kk6VheC+rxOaTAE9fdeDOdvdPEr3kWP38KSNjTdZI/1mbgYLTjodi DrTy3KdKW7zj+gOsIeSCl2l+tptLhebOCxfvJQ9U/BmqKpbBoj4/3wAUofaWFlGwlIH6 vQvFJwUXInBKMczwz/cTbXie0/oRQu2Xd1hSWJ5r/O8sb5ntTcm1+ruIBN6nix7+pjuJ il61DObHlxgPH5edYcZIt0oxHSnTRODFm3Uj2URDQAvIF7ZP29j2Cn/vRcfTeHEN6+Zg WQeRwqJf0GlwgNCjElNO/dcoZL2yOPzbCFBgo8OoqrWUv2N4J4eie200dGjodXy6wHfv 6b7w== X-Gm-Message-State: AC+VfDysRJg5lb7wGsbzq2sDQ4qCNV1nbTcYAszUBiXv5Jr7UEMt40lc C3/5t1uKkp8FdGn0MXRDNjNEH1OxY0BKluIw7tkI5A== X-Google-Smtp-Source: ACHHUZ6i33Zt6lBAsGFhBQjcAHgEqwffZrn+lh/Sa7XfqbavLy9BGOHe+OV0wQUJlUl+nF7rG6XcZNDeJbNZHnhEQ4U= X-Received: by 2002:a25:c744:0:b0:bc4:3e4e:12 with SMTP id w65-20020a25c744000000b00bc43e4e0012mr4781374ybe.36.1686584508078; Mon, 12 Jun 2023 08:41:48 -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: Mon, 12 Jun 2023 08:41:37 -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-Server: rspam09 X-Rspamd-Queue-Id: 64B6414000C X-Stat-Signature: 7gu6yoypt1jeueempke1bur896c4emfu X-Rspam-User: X-HE-Tag: 1686584508-447090 X-HE-Meta: U2FsdGVkX1/D0NEq4CCRqM9C+aTlWvACXpFb7qvuJzxRV70DE7lsCnRlX4IYBp7EO7543tVcqQqzFgYEZAyIGt7kB8Ha1gaF5nPvrnVIeqdelQkaBXFnFTbrP2loNyHZyjr832aWRpxpmlhGr/ALDmdnWGTIrwR9+fL0g6RCD3Z1kh42gUp/bBHbSm0cABoPrVqanw6gGKoTxwQdQSpLyg+pQik/4mLWcHL+sujkT4X+6hd9dcMaU16ZVDjXSkGycqwf20tphnfsirAVTcklem9SbGZZwXQI+ndhUqsEc3wTOnre8yfHLRlBO9Cn5VIl5E10JmhjkSY/MMyOAcyidt6AlSk/yj7sC1L9n6cOMb9cEUFX9E/VDEkNthrbmntetsl4rt6gTU9tLb8SE0KVVrgS/nK0MwBFDhrjP1xN5rxsR6/iK/XR21WME+NPFI49ZpXPOmqZnTc9Fosgb4GRh1ViaL5r/ut/kvndyIcFqTQX7XCkJENkzvIo/UxfP7YZPkUOeD2KajIiLWOcNUHqknNu2ZrOM6+CUIP4xZrQlRuLfoCp3Hhy0jyGSxWwV+XiKD397Sv44hk8OrPHGnRpv2Ds+MOu4EZ7iSHu17RUTXT9Pi6wpkTv73IL/GqnsT+aJPd+to6iKbz+bdHgNccZotCldw2nUV9UqG5kUY+H2m7chT5R1Tqj8UFjl3fxy9wiTrcObnr1UTMMCSrZEesefl3G4dhh3GDg9XpA3uZmLWEQ6ByaFMwLnOvIkMnpE6Qe3uXc43cYyG0gQiwsL0W1NoaZsYlY3LRD1UwkmaqelU6jDxfrrc1IBeHNCsXAqnd1TdWffKO8ys8hXtnqkVo09kzrqM3YQu/A6/XSeGEkRXO2wuHJzZpgu/CqK+ICEnxZQ+hvvVfryzxsohVUjMg9Omg8rbH2XrAfiqpHGxqTnLp0Su1qhFk3sxTG5OGJ/b7BrOwkkhqik5uKZ82vWGy O2pr5hZn UCAAV1wo3YyRLKuNW1l+GgidRy2mzAVtzVSXkhY9+8Oa5jRr2/41tYvJ/s31jHYOBmENYHTcsz3gdLxb2apMwzqZ1bcsr4xe2TG/n/LcsQL25swTx6K+3kuiW89FHL2BigB6c73ErEeAdlvrBaaRvX87Tqu69MU+hAfqzK89XJKY5HvD323MmnzQCrAILbu1SlQPWg1l4VwC8S+LL4eSgeIn+5tPdZ8H5fHsHqpUwwxf3hX8M8Uz+Hp9PuA== 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 Mon, Jun 12, 2023 at 6:28=E2=80=AFAM Peter Xu wrote: > > On Fri, Jun 09, 2023 at 03:30:10PM -0700, Suren Baghdasaryan wrote: > > On Fri, Jun 9, 2023 at 1:42=E2=80=AFPM Peter Xu wro= te: > > > > > > 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 dr= opped > > > > before waiting. Introduce VM_FAULT_VMA_UNLOCKED to indicate that VM= A > > > > 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? C= an we > > > 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? > > Yes. > > I'd suggest we move this patch out of the series as it's not really part = of > it on enabling swap + uffd. It can be a separate patch and hopefully it'= ll > always change both vma+mmap lock cases, and with proper reasonings. Ok, I can move it out with mmap_lock support only and then add per-vma lock support in my patchset (because this path is still part of do_swap_page and my patchset enables swap support for per-vma locks). > > Thanks, > > -- > Peter Xu >