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 943B8C41513 for ; Thu, 10 Aug 2023 23:30:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1BE6A6B0071; Thu, 10 Aug 2023 19:30:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 148056B0072; Thu, 10 Aug 2023 19:30:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F031F6B0074; Thu, 10 Aug 2023 19:30:08 -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 DB7636B0071 for ; Thu, 10 Aug 2023 19:30:08 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A8F92A0118 for ; Thu, 10 Aug 2023 23:30:08 +0000 (UTC) X-FDA: 81109790496.08.140E096 Received: from mail-oi1-f170.google.com (mail-oi1-f170.google.com [209.85.167.170]) by imf08.hostedemail.com (Postfix) with ESMTP id EDE9B160019 for ; Thu, 10 Aug 2023 23:30:06 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=tKoJJzjF; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of surenb@google.com designates 209.85.167.170 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=1691710207; 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=Us0jQem01wTsq5oLI86XdBT1Bl2UNsOl181yWXsRIRw=; b=mJPK1udw77yBU+yfUbc5RG+YQyPxmLxU+5QARZUrzw8J+4JlAkFoTThemKxdLz0PvvQF0Q 9GE7fARmItXkO6YtZkXnXbKnFCpmWrrwBJ53+DDk02VADCqCAkekyN3Gx5G4q5Mj/mp8Cf ZxhVFN9r99U8Uf7efts/nzPGR6QNOnA= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=tKoJJzjF; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of surenb@google.com designates 209.85.167.170 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691710207; a=rsa-sha256; cv=none; b=Xlmxn1iCcaarnjgUpgbWoYS6b4ir1M39nTAXxgzsHMbf5HPL6p8wQHAmOBtwqlarHFwwLI /nKMy/0fiWklprlhg6ESx/GZ70RX7qm6yXgd+EpyagNUJJqDwAjnZQkavOPQtxOFOQBkZ/ D0JL9RXWlK9vmZgyjQXQH4C877wCVo8= Received: by mail-oi1-f170.google.com with SMTP id 5614622812f47-3a5ad44dc5aso1218183b6e.3 for ; Thu, 10 Aug 2023 16:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1691710206; x=1692315006; 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=Us0jQem01wTsq5oLI86XdBT1Bl2UNsOl181yWXsRIRw=; b=tKoJJzjFBECo6MzzydQY0LO8m6SpU5yiUNRwsNtA7/FU6MRsKPUdJat2cdGhDnfWn4 Hc04Xu657oR6lvFH1D2hWfEJVoiGXEUSGgqv1H8oC0TOFDgvdPVXqwzRNXYxTFmXcjlT GHaa8qRx5dtgUbNl9622QBG6+AWvoyp2H0JYYMiE4rhgyREFt3n86nwY3MzuPydKe8K/ xmXbWdIXDp5xUDjEDyrEc0KjjiOASYK9meCkuluo82JlsGJwhLz5DnK/yuw3DcbLnxK1 tiVeyI6m8rQiSDl7MOjutH51FKczkolZGZaC25suA0WP+AhAlk+i/XGiGcMYGzY0HpSz LvRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691710206; x=1692315006; 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=Us0jQem01wTsq5oLI86XdBT1Bl2UNsOl181yWXsRIRw=; b=V4qPhl3jtw95QY9mOCZFF3zajpnmyMfExtJIlTyQTqiaAAv0sxfNp2AW1uwnq7/htT e8+024SQQ5vaCqPwuqY8s18awk0kmmpQ+MOo7Kh9iXWPYv56cu5/mdWDslpd020VsyWa U2RdgJuuPt9tS3Pgf31lXiktrJOgcIhq216W0n4KlUpk6U0nWvD1N90XVQAJlkitIUCZ mS/MzacoXtxKYbbRZYKNmFhhcpjejOu4cSf3QZHhHrMvfG4+VJjcltxy7F2+afa2QhZ8 ZZ0hgJl/3DvA2nXAs2HW52rGBTo0h5o90H4+wEqnXTT5v8BmCPBv+M3T0iXQ8qDvw/nk ehCQ== X-Gm-Message-State: AOJu0Yz+9mYzwAcdAKoh6kQjxSd0b4HM0QdsVt92OpRN8k2ptNKE7n9y Tx+/7sYJYr4ITx/WPCAYRSXZFyLDsrBjawMhlg4VSg== X-Google-Smtp-Source: AGHT+IFeEMio2gJ4kBngRB4zbUtBoGQ2XJEN6qvjP50PbhujYl59Kaa5oh82GdgItIor5tQiS/o5bQzeaI16ZFTmPPs= X-Received: by 2002:a05:6358:428f:b0:135:62de:ff7d with SMTP id s15-20020a056358428f00b0013562deff7dmr492898rwc.8.1691710205803; Thu, 10 Aug 2023 16:30:05 -0700 (PDT) MIME-Version: 1.0 References: <20230630211957.1341547-1-surenb@google.com> <0ab6524a-6917-efe2-de69-f07fb5cdd9d2@redhat.com> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 10 Aug 2023 16:29:52 -0700 Message-ID: Subject: Re: [PATCH v7 0/6] Per-VMA lock support for swap and userfaults To: Matthew Wilcox Cc: David Hildenbrand , akpm@linux-foundation.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, peterx@redhat.com, ying.huang@intel.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: EDE9B160019 X-Stat-Signature: u1yn7o8yzj3epws8dzzbmmg6bippqb9s X-Rspam-User: X-HE-Tag: 1691710206-372314 X-HE-Meta: U2FsdGVkX18W7PiPBH57fpmvakZfJ2T2IrWDd3KzdHoGO83qOeI+OxnMJ3+mkVsvFI34rKLkLQk/LlpbLRScyrHXSmwa4Wnh2kUzHjdWce0ddR9Jsb0EoeYVsf92OQTmewy0741xKKGzwlNHpL/5AZygyS8nS8kiL+u+63Xzv7QlNFL8wswFmem1mnDzGhjMIHvcww8yyfCu2/sIqNUGMk6CE/88LD9vIEDpc9v7kg1LkaA+e6Uv+2IKz0tGpNEUhdYKuQu2S/SFLc5COYzLzx1xjyBeo2aWE9gTDvNf1F+Iiy3a5Hn1yQiDzGe0sTvVX5ksp0kzHJMX1RqdPHVEpTEqknXL7S/8y2LhTcknzDoGUHkl5uFFLSzsZVKlK/+5CSkRpTrGjk+u5QlSm8Ey1PPagtFPItTIn9eys2sjwyN6/FfgDhvZo2kJoRoHOGoydzOxL6uEjJP7OK3CNRBCJijQ5uRMEpZY75wh5b5HaU8YPqM+v4kpCmq6ITWGo9o7Ip0zmXFtClg8H4QVDH3duhg/BrAFvatmqzdtNRL9g3uEa3X05473DG3/R9Aj979iADsW9mEAJ0Z6OBrp5LdRe/3wtuH8Uod7P0BWweOyHr2gS4dlo9sM+j59Y1Yy9DW8U8I17YhA7pELWhd9FSA6LSY6pPf8qqVC1mRP9gwHsDmpTTQwKLoshWIYffh9kTQMPYyPBUp8StNKLjIaept7pVGiDpKB1Qbq1DHgxI9bdLis2+F/JxcdOwdxHn3z2JD11dMx5nPCz/yDlc7KC/9yJ4mmn1f7dHukO9C8olKJBGg1rfQj2V9jy4RFG8D8qwf7k+Kp2OW6MIpM8vyBYk4Uyuk531WgQVXSjCq6zf+cphuYG6DRGjknFLOSMscEKfCdSkSuSgJcSh98WHyE1bNXYRR4qdwHDbSjLdxtq9/j4kyGzNLQgxPrM5Ilasv1CiIzr5IEkAYCEtgSwlPZd5C sLQL6fuk lkNCLh4Ibx44U1f4xwMcloYyFvLVwYNUSbEhFs0ae79LDvlhgLRDPYj7ZYCbbv0Ed9SjcMc717MCEM1i78YY9aUpBHtRdHXBS6kT4YVPPXmZubVRfO7CwKtzNRGDLKFlIpi8wVqY4U9CX+zIrrkFsTMT79ImhE3aV+/i/oJcfyIauyH9W87lCu1vHP6IPVt8s3DcCJXguJ0+j7gy6Oi58IOZxsFsN2M0jCYQBuu96N4dJTmEeJzgUEnzZFuGUQpsWHUEwmRIkn4rHmVWAGx9NItQoEvaD51O7837d 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 Thu, Aug 10, 2023 at 3:16=E2=80=AFPM Matthew Wilcox wrote: > > On Thu, Aug 10, 2023 at 06:24:15AM +0000, Suren Baghdasaryan wrote: > > Ok, I think I found the issue. wp_page_shared() -> > > fault_dirty_shared_page() can drop mmap_lock (see the comment saying > > "Drop the mmap_lock before waiting on IO, if we can...", therefore we > > have to ensure we are not doing this under per-VMA lock. > > ... or we could change maybe_unlock_mmap_for_io() the same way > that we changed folio_lock_or_retry(): > > +++ b/mm/internal.h > @@ -706,7 +706,7 @@ static inline struct file *maybe_unlock_mmap_for_io(s= truct vm_fault *vmf, > if (fault_flag_allow_retry_first(flags) && > !(flags & FAULT_FLAG_RETRY_NOWAIT)) { > fpin =3D get_file(vmf->vma->vm_file); > - mmap_read_unlock(vmf->vma->vm_mm); > + release_fault_lock(vmf); > } > return fpin; > } > > What do you think? This is very tempting... Let me try that and see if anything explodes, but yes, this would be ideal. > > > I think what happens is that this path is racing with another page > > fault which took mmap_lock for read. fault_dirty_shared_page() > > releases this lock which was taken by another page faulting thread and > > that thread generates an assertion when it finds out the lock it just > > took got released from under it. > > I'm confused that our debugging didn't catch this earlier. lockdep > should always catch this. Maybe this condition is rare enough?