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 9B1A2C7EE2F for ; Sat, 10 Jun 2023 01:29:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CA7BD6B0072; Fri, 9 Jun 2023 21:29:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C55A86B0074; Fri, 9 Jun 2023 21:29:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B1D0B8E0002; Fri, 9 Jun 2023 21:29:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id A244C6B0072 for ; Fri, 9 Jun 2023 21:29:57 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6CBE4AF3BB for ; Sat, 10 Jun 2023 01:29:57 +0000 (UTC) X-FDA: 80885106834.21.97C09DB Received: from mail-yw1-f174.google.com (mail-yw1-f174.google.com [209.85.128.174]) by imf25.hostedemail.com (Postfix) with ESMTP id ABBBAA0003 for ; Sat, 10 Jun 2023 01:29:55 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=tOtScZVw; spf=pass (imf25.hostedemail.com: domain of surenb@google.com designates 209.85.128.174 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686360595; 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=8FKJ3xPJEDetSK5auCGGcapjjk91ewFvgiFRw0hqYb0=; b=hTTVdXY6ehoor/Sbi//LUF2f8dLtGf8bxJWiiDbiIOj60gnUlELo081QMuWhyhMEDA83gg VvhyKqnDtZ75zeSczh+ZwkZqXpUMcT2XLbPllHQ8mmYXKdVKFHYqntwU4vCe42UpEI14jL wsW08g9GBLNUnfE1zuPQiqH+iZn+E+E= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686360595; a=rsa-sha256; cv=none; b=u7WROfEpYpId/q5dHgcnz8qptb4N5FyiZflZQcOAAphxy1CN2xyh0U8uqJwh6FX0b7EqZa 6T/rRUXsnj4cXyoEL3jWG2aers1q2f7A2Ybi4gLLCkPKqtiyOgxkWdDkKBBJIV479CpkGu SmU7WBcR8BPu1FYuwEU0ZJWUFKBMh6w= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=tOtScZVw; spf=pass (imf25.hostedemail.com: domain of surenb@google.com designates 209.85.128.174 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-56ce6bbe274so1389647b3.1 for ; Fri, 09 Jun 2023 18:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1686360595; x=1688952595; 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=8FKJ3xPJEDetSK5auCGGcapjjk91ewFvgiFRw0hqYb0=; b=tOtScZVwZNwDUDalvhpk5D8h1duHJC9b998fE1WumdZZRJbExd+da8AJdP3IZ5Wae/ 5nb6O/f3+WMjQJEFgWrI+wFdIr3WJVKy361rNGexVno4GyofOLxRv1ED9LyOv0G6wFeB +L352ZuS1kMGc/90BnLCPWkAVDvU27yfXKYtSLR6CaI8aVSeFy0dW9+txuuI0F2lbPLL NC4qerfdGfI11b3wj41HVyB+zsVPrh3x3ibIqdsrqPV68CtMPa1de9kcnwc95D/rDVm6 9n6gjQcHxvlnY2Q+i64cRlcbQikt5Absa2MZ2QUQHi/nTePPVQFHvumqFwkSXlDNzeO6 NKBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686360595; x=1688952595; 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=8FKJ3xPJEDetSK5auCGGcapjjk91ewFvgiFRw0hqYb0=; b=GRuX6/TEuwqNqiWKvC+vXOKJnWmfjQYNNWYxvBn5Nm6jhdYaaVVHcVg0ycZZ6U72wo 6d1/epHDM1bLn+Hv/q66ndb+CpEaIxmF2JXR79B8+0jtmkL1U7DXG6eswpjZFsGLgaoz V3OkkUIUI4BEyZJug5HNPLnHeFwQ0P1Ae2L9DJecysfRKd6Nj6hufONvKnbu8OVEH32f uy2h8Zkld4uWWL1+UQOv9qhHOGG/uoZp9nnWv/bq/NF7ocxQ1+B88wVaXF5UHZ6+J+89 ysgfJmLLJKQE78D+1Wh0jbPrYXdp19MdItGix9SB9Kf6yHxjtcyuSAiQYJ51GD6Pfa5y G9YQ== X-Gm-Message-State: AC+VfDzulwATO4mEnqvRnd9S60EhDn/RpKy0Qdg2aVmC0oBIcTrA0+gQ zr3YWMoNJfa73dByVQbDeX99rzzhP2GQ+afTg6Y9kw== X-Google-Smtp-Source: ACHHUZ5olS/VKLyw26AHgQlVBf0OLVFr6x8YW8avTg9PVS60xY2nu8cfesfDPnrAVmkdYUX3hVIVpz5CG9a0BKsTOWA= X-Received: by 2002:a0d:df97:0:b0:561:baee:ee8 with SMTP id i145-20020a0ddf97000000b00561baee0ee8mr2916493ywe.32.1686360594592; Fri, 09 Jun 2023 18:29:54 -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 18:29:43 -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: ABBBAA0003 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 9dq1kift1xhm9p9wfx1649tynspxy8tj X-HE-Tag: 1686360595-687271 X-HE-Meta: U2FsdGVkX1+7TX8aEVaeFp0TWapOc5hh2jacVsvz0A0UlMVkBR8Fc4K+EyqnMjYhzwszdCngHCaWQF24WAiiM32QyluLgPzkUokOnGwh/JfIJ5QvzFaQysXA7DJqPvcjIH5UVdafaQbNCIuCF1PV3d42EjDP5O7mCtPaN8aVLfOQWJuSk2jhOSPGXmvZ2yWpJZU1uvvIUhuF/+YhX/hxSCl+uQ+DMfCJAmHk7dwrEC2bqGhLx7d3KEx6+blMU0SjwKjn0/TIKVjcm212K7eR/Lk99AadSTHQA5+Ev0DH9XIeEu0zaS429go2TCzGjpAE8DNO4en+WIbL8boDHPRQf1d5niaDipJQ7LN8W4ArG+A8xdYKA6lfVQGfMPmIm1B6GpvL1i9A9Kdh/1yJnOeyriljssGZ0XGM28Sj/lBmDykraUhRL/EQdsDF5QJMiZR5p46iRklxvRm8fiNxJOwpCxsrBbR3LbVF2QrhEjpnvUYtuc1awlAxbd39DTrplOHdqz9cv2t+J4lBwOnZZBQpAXluyyQUq61Rc6AByPDP5l57O0wTI7LCAbjgB9WnkgqoouHwlX23bWERnBa2FZEnl4UqQmukwX3QnhtUI/dKGyP5uXJoYgaS7wUPNHcreV29lTmNSb4Ry0rpvktDQp0nbbTfThK94u5yf0bfzawgTB4HGAEfkqqRmSvmPpSr8tf0brDkwTKHxNam2y5Z4ncKSq0a/2hvQPAY3kDD6GDh6gcXReQqu6nBc0enednlBnIdzI/7iuyla9Zjw3lqPt7QvzD18vLaNKdU8T9EEXV87/302QTwWkqcaBIOG0XpsoW+M3WuS4QTsDKoHgtB+B1e689xUiIu0knWo988CPpOpm+riHlg+GhVlI0DfWQ4nCf8ng7/ZajAtdj0r6EH3AjMDq3VRxZ6dPTFpbGgJdpnPdZIJ3v7Wh5e+0PEM0wtXobn5Hf84YUAJcBTEYi2zp7 krTB2gKz vRBs5g7l9XC2XIY7NbnnNIQFIZLx1bkTm+pVPMrCsg7SMnWWKlPYB31VoXEX6SWZgrVVu+FifxyzHod++TXcEhPJISNTVt0X06i6s9vSRBcZYBaPouE2Dm2q7Q7y4+ylLnCo+8/NbwtKc3P8QLqHzzO/RK0UJ+G0YNvs/De08XjUYjChB3JjLWLCGUVx9HfWntaDtqVUQ6UOWETq6styCkjNBi0QVBQH565qcV9eA0GHTWA21gdRR7hmfHYy8ESz5bhuFzyQe7FQsIsdC/rOStBiVv7go4KZNGDNzRLllZYis4UGp8Jo0KTsbmKwhKz9L/iu8 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 3:30=E2=80=AFPM Suren Baghdasaryan wrote: > > 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 drop= ped > > > 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 a= s > > > there are no guarantees it was not freed. > > > > Then vma lock behaves differently from mmap read lock, am I right? Can= 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? Sorry, I meant VM_FAULT_VMA_UNLOCKED, not FAULT_FLAG_VMA_LOCK in the above reply. I took a closer look into using VM_FAULT_COMPLETED instead of VM_FAULT_VMA_UNLOCKED but when we fall back from per-vma lock to mmap_lock we need to retry with an indication that the per-vma lock was dropped. Returning (VM_FAULT_RETRY | VM_FAULT_COMPLETE) to indicate such state seems strange to me ("retry" and "complete" seem like contradicting concepts to be used in a single result). I could use VM_FAULT_COMPLETE when releasing mmap_lock since we don't use it in combination with VM_FAULT_RETRY and (VM_FAULT_RETRY | VM_FAULT_VMA_UNLOCKED) when dropping per-vma lock and falling back to mmap_lock. It still requires the new VM_FAULT_VMA_UNLOCKED flag but I think logically that makes more sense. WDYT? > > > > > 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. > >