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 A105DC001B0 for ; Wed, 9 Aug 2023 18:32:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3AA146B0074; Wed, 9 Aug 2023 14:32:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 35B558E0001; Wed, 9 Aug 2023 14:32:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1FB376B0078; Wed, 9 Aug 2023 14:32:10 -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 1297B6B0074 for ; Wed, 9 Aug 2023 14:32:10 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E1F9F120917 for ; Wed, 9 Aug 2023 18:32:09 +0000 (UTC) X-FDA: 81105410778.30.CB263C4 Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by imf25.hostedemail.com (Postfix) with ESMTP id 1127BA0015 for ; Wed, 9 Aug 2023 18:32:07 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=rywljwLI; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of surenb@google.com designates 209.85.219.181 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=1691605928; 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=RHnmTAuuBkyhoSRjvMGvUMrCpJOQs8BtVZXDTIE3D1s=; b=r84D7G71AFm59DtZwEMmzQnz+n1Tv/hf6avlZK/j5HVKZAbYQnqYaZxgCZUA1D1p9af/dv +nuES9wQYw28e8ghX+HlkkbjLpiko3o4TTQZlDlycDcWeErCAb63plBuaU/axVkEGZ0kvH WI3CTZMBJrtHjKP5yvOytfhG+zSIDOE= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=rywljwLI; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of surenb@google.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691605928; a=rsa-sha256; cv=none; b=gJs+72XWuWVmsoJJxaFideJUb0HuihymEHW+J/O7/S+805M0r9oVJVJwtL5nG0BKrqTEdJ oPEeX1xcTPKNaZ7Fmv0Du+AxLsEL73B5U6dD8KylYzzbyo2erPl+pzaz3y0/8aw3T6+FUC 6KKgleHokjcNfGJMmxSdKoNWaz3EgSc= Received: by mail-yb1-f181.google.com with SMTP id 3f1490d57ef6-d5869d9651aso80880276.2 for ; Wed, 09 Aug 2023 11:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1691605927; x=1692210727; 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=RHnmTAuuBkyhoSRjvMGvUMrCpJOQs8BtVZXDTIE3D1s=; b=rywljwLIMkcUe/YouOhrAjqUwmYZFHGlRvJkNcRn5ctb15/YefUGojXuTwdE1uTPfy z7+DRg3M0BP6u9lbezVX9xsRVVMfvwtxWBIyXU6yq/vJ6PqMNX2H+ooCyWhrrBhAJTjj doVQpEDnLLMdWmcDIW+Bmg7sGsL5tsXTb1SuL9HNqqP3+b4ZvQA2tUsQPOYF0FKAb7VW 2b3QswTGoJm3Bt17FOhWNpGmRLp4i2i70OVatE8klenARqBCv7Vah7om/ivHOYcBLHEo IZWGu4gxXg3hE04YAUSMnd9WqZscfLlOwR34jn/RSlMuqj4bEFpB14Kwi6AV1Y79r9YA M27Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691605927; x=1692210727; 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=RHnmTAuuBkyhoSRjvMGvUMrCpJOQs8BtVZXDTIE3D1s=; b=LDaZFH3bb9B00leMiJ1GZLVfamaAzCIknAOlBc2ZGxk7S+4Zku9zJ+mgqbM7Qx6XYh 0aG63i6Tvw0xJH4sCUh9+2nZ8AkXH6Ex42C9po+K+IBeqXVpsNm8j5GkUbZeR0mTh1lL x4BsFIe/PlbYttzU1Oy8z9T94xjiV4Ge6FhJvs0noMnJQxV+M8gasXPPnPDWtls1fKwE OeS4ZkkqtlsaWodwvpxqHHwehMqT4wqH51L84MB2XM3+789uaT1ALklSS3Ui8Qibp3nS TQTIqtwAJu7L2P44AuJkczzGmW5EOYO8uho6pfY4AkuDprE3AByHLBZeJByKfQ4TcfuC v8Kw== X-Gm-Message-State: AOJu0Yx2eXLE7XXYO7rqtUxc6KIz52OhdnvpfWfnzweKQGt6R/n1qB+D CWLWjhFpJ8oXtpmBzxfb6WcAaODhBQsiKyvqV2QjNA== X-Google-Smtp-Source: AGHT+IHK3Dcqy/WID1j0pyzQGlfiiQHINDsBbv4x+B/a8SreFNWZoniInr0UtM8vfLTJTv4ZPWpC0P1nvbhvVKlVIK8= X-Received: by 2002:a25:d304:0:b0:d44:3ad2:42e5 with SMTP id e4-20020a25d304000000b00d443ad242e5mr275771ybf.4.1691605926873; Wed, 09 Aug 2023 11:32:06 -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: Wed, 9 Aug 2023 11:31:54 -0700 Message-ID: Subject: Re: [PATCH v7 0/6] Per-VMA lock support for swap and userfaults To: David Hildenbrand 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, 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-Rspam-User: X-Stat-Signature: iag9bbdb95mtnj1tfis5tgnihbw4ztx6 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 1127BA0015 X-HE-Tag: 1691605927-980374 X-HE-Meta: U2FsdGVkX1+slSSGAw9ud2gCoXkLYt8h9c0LFyhTJOqvOqRAQ9OyO3/DoDI7bW2tj8ge9NqHC0Cpj151Kh8IAo+AH9cWUptWUABLjLQSXDqD1OQBCXOiHUIr7up/DQP2OyUmvfdROYhJvnN7eD4ZbyTElrgEPq4dIBejRjvtRkrTxEeBjzrvY0hfNHmU0h8T4NahfL4IcNeZTwRcDpGMiLRaA4XAg/qM8X/PuxR+S8NfC5IuUgfQX0x1xHm9cs29rA0Gx+shAwHnPprNNisF60TB91DIVYsLNCP8uPpjiIdvDyfRfzaaMVSfLLcysvOR/gOmAc5RPxKQlxLFv3lUyWsdis5jNj69StbXN7te5cLp2I+AyrAT1ZHlZmNXib+gOD35U3R5e6zQRj9Rg7LnUEZZbxM5aZn22s1E3U76+oBhzRjKFmS8wgxtZ1uZyJ++/cAPW9V15WSuUkpJQuUL5q5RDICsdCIqu+ZHKE5PxLez7uPxu6khUA258/czRwut6kDdct9BSXDeZcZBf15mg8GCdwMkx5NlVbkY88/S+SKC4Uoj5fGLQo7n+LfMXaYhUHP/BEBxqnmp8hy2YKulM+a66HqMVZ5hx5VvVYTljrc8+oPRpsjR0AWm70+bpbDEQYKgoZIgHFkOgX1C3zW+f9qWOsS6yO3nt64JKMRFg6M/DUYKXjn27SJq2H4NdbMl9MTpE/RCZqxXTo+xtee1MzYLt1/rfDbcz0i1KB1HuLs2uyj6aFQIsoRycxteHKLFURPHfBLa+1jy0wbcUS0BS356ysGCnPn2x3od3mXszB7KfBnVmcYR1kOOnllTOJ9pLK4MPPVOZyEHW+0qOtnwvltN/g9viLlhI38qZEGieZXYgRiF8yWT/XKYvQQHxTlAkkWt85tfCE+wvb/llT+Qj6huEE27ghA2SLslzp4X5EnkK1WPonQOBDZfAT2TzlLDzmL+VAYsX2NfVy1sthj ijkT/iGE 2V3hoTERoKs9p2MJ/xlWjWifzOuAS9yKxaWdXgxcDPpyhX8v3sR8nIOkb+SHEQjMM/HqZXnPzrFVfTJJuFId4iE2HUPTEsYnUV2iatAcBMCZke7FAdBxiAg1BOlYSFrcIzWY3RP0G+f9e3cva1YwYsu1kBj86oQI4zh+ZOhjC7qUWjuTO77InrfpSLi2eknSbBN53AmOa3sWvJ3iBhjzIyZcEAYVe9Qpte7ehOZ4IVYunheOdw+C9rheiygR6r39wAUdlf0faCLxC5bgqdqydPP0zHw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000218, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Aug 9, 2023 at 11:08=E2=80=AFAM Suren Baghdasaryan wrote: > > On Wed, Aug 9, 2023 at 11:04=E2=80=AFAM David Hildenbrand wrote: > > > > >>>> Which ends up being > > >>>> > > >>>> VM_BUG_ON_MM(!rwsem_is_locked(&mm->mmap_lock), mm); > > >>>> > > >>>> I did not check if this is also the case on mainline, and if this = series is responsible. > > >>> > > >>> Thanks for reporting! I'm checking it now. > > >> > > >> Hmm. From the code it's not obvious how lock_mm_and_find_vma() ends = up > > >> calling find_vma() without mmap_lock after successfully completing > > >> get_mmap_lock_carefully(). lock_mm_and_find_vma+0x3f/0x270 points to > > >> the first invocation of find_vma(), so this is not even the lock > > >> upgrade path... I'll try to reproduce this issue and dig up more but > > >> from the information I have so far this issue does not seem to be > > >> related to this series. > > > > I just checked on mainline and it does not fail there. Thanks. Just to eliminate the possibility, I'll try reverting my patchset in mm-unstable and will try the test again. Will do that in the evening once I'm home. > > > > > > > > This is really weird. I added mmap_assert_locked(mm) calls into > > > get_mmap_lock_carefully() right after we acquire mmap_lock read lock > > > and one of them triggers right after successful > > > mmap_read_lock_killable(). Here is my modified version of > > > get_mmap_lock_carefully(): > > > > > > static inline bool get_mmap_lock_carefully(struct mm_struct *mm, > > > struct pt_regs *regs) { > > > /* Even if this succeeds, make it clear we might have slept */ > > > if (likely(mmap_read_trylock(mm))) { > > > might_sleep(); > > > mmap_assert_locked(mm); > > > return true; > > > } > > > if (regs && !user_mode(regs)) { > > > unsigned long ip =3D instruction_pointer(regs); > > > if (!search_exception_tables(ip)) > > > return false; > > > } > > > if (!mmap_read_lock_killable(mm)) { > > > mmap_assert_locked(mm); <---- generates= a BUG > > > return true; > > > } > > > return false; > > > } > > > > Ehm, that's indeed weird. > > > > > > > > AFAIKT conditions for mmap_read_trylock() and > > > mmap_read_lock_killable() are checked correctly. Am I missing > > > something? > > > > Weirdly enough, it only triggers during that specific uffd test, right? > > Yes, uffd-unit-tests. I even ran it separately to ensure it's not some > fallback from a previous test and I'm able to reproduce this > consistently. > > > > > -- > > Cheers, > > > > David / dhildenb > >