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 1904AC001DB for ; Thu, 10 Aug 2023 05:29:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 10DE46B0071; Thu, 10 Aug 2023 01:29:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0BE8E6B0074; Thu, 10 Aug 2023 01:29:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EC7A88E0001; Thu, 10 Aug 2023 01:29:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id DC07A6B0071 for ; Thu, 10 Aug 2023 01:29:49 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9A11B80269 for ; Thu, 10 Aug 2023 05:29:49 +0000 (UTC) X-FDA: 81107068098.08.AF2F42C Received: from mail-yw1-f169.google.com (mail-yw1-f169.google.com [209.85.128.169]) by imf18.hostedemail.com (Postfix) with ESMTP id D88171C0017 for ; Thu, 10 Aug 2023 05:29:47 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b="mzZ96Ky/"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of surenb@google.com designates 209.85.128.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=1691645387; 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=4uoKPPUVJQJvxmsNX8HdKmHcwGoP8j8tE48dXRoXR/o=; b=6jR9SIDYSYbdYutWUbpGOmyR9ikQ3doKKfUmd2JcpBSaeaZSNNbDCqP9VeWS6hQrX2nRRZ YKoH7y0AETTpxnJWKpDivNs4CDyx9MIs642iVJP0lHM8vuad5FMFrJ+2fu2Kr1THgJchFe 8SDxQ2H4muYJm8JgJJ/zEgKm4a4cGSM= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b="mzZ96Ky/"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of surenb@google.com designates 209.85.128.169 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691645387; a=rsa-sha256; cv=none; b=Jxb7fVdPO/M7N6N4YpbuxuYti4aLzmHg3uond7sf1lUq3Cc+1k2zBhe+KaU25XZCif+CrQ YftQLf5bx+F8nc+6pUTydidGldEJYdH/9L74JZzuYswmz+pukO8JCSV5Ls5BN49d4eNHGi IgMN/IgKln02tYUJzQlxT17E2/Ei644= Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-5844bb9923eso7272447b3.0 for ; Wed, 09 Aug 2023 22:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1691645387; x=1692250187; 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=4uoKPPUVJQJvxmsNX8HdKmHcwGoP8j8tE48dXRoXR/o=; b=mzZ96Ky/PAAf413iiveXZmgW90wIqSR/MJMOaUb3WJrDqIlkNWalvVdCinPsqCcpGd 0N1W6RdHTOisjFF8yVEaAPEwSOgkyh9aVG7dS6/wPDY8VQ8k55dEOXkSBbxth1cdshKu KuVJ0xLBtzLhbi7oy8MQMA3diIYQtyKxWimeja88GgIhwf5/WDE353lXkehBDgzF7tPR 0ET5tP0Fyxa6xJY8lp/20m98rMqh9YGqkgAVlnu1t4YxE0KLdchG6oCYJXCU2qcFrvWB LCI+109wtD8KzZ8uyZi8/qgjzatRXooagunLE+qL8AO9leSJ60WXDgnBjD780d3Rg+CN M4VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691645387; x=1692250187; 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=4uoKPPUVJQJvxmsNX8HdKmHcwGoP8j8tE48dXRoXR/o=; b=MAQtOfUyJ0R9/TJKL5cqdU7q/WB4t4wmGfOvzpbazfU0GN6fABtCucs4NDfN9ePWt4 NfVG/dJsUbqqEEIk9wvO+hwVRTntVD4hlMIqObCEv+gwDXb6rtZy7elZKkaadQWFP30w LREzpQu93PudokEQMROKiT2D+NN9Fwz7emB54MHYRrcBv2DRHlLemjt8v8doJXwTDMWe 3yEDpBzIeXXEqCIVBA5ORsJmgOmjvkJgZvIN/oY68+U/5nkJ1oAZezlOzR838Lhc4Wki N3tEU76hCfjit6bZfwzRP6mtAJqVYfq54vaji/1TkDzABguea875TT3LWMWCNHQU1ltm DTXw== X-Gm-Message-State: AOJu0Yzg+8xOdiqiNm0Y2Z3krZJw/WaYzBJJKc7QT02SJTuVFuWPafxe W76B8/qRCFxi1c2EWaHcVzF3x2sdrq1O+9eJy1k1qQ== X-Google-Smtp-Source: AGHT+IGzAcGbdmxpwXQwtenXA6IAHlZx6Spg93JJ19ndyf0aos6wu+/eP5nmq4DyCWY4KDBzCxs8VUzXGduln/PfdhE= X-Received: by 2002:a0d:dd08:0:b0:573:30c8:6e1d with SMTP id g8-20020a0ddd08000000b0057330c86e1dmr1491956ywe.44.1691645386722; Wed, 09 Aug 2023 22:29:46 -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 22:29:34 -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: p64ndd9f5ti8pe1hc8kzpy13pjoeraso X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: D88171C0017 X-HE-Tag: 1691645387-313444 X-HE-Meta: U2FsdGVkX1/Pw2ZetxrdorVoPq5Tyc5Z7pxTc1A93BRqGAwRFaFfx4ZOfmZmKi86oO6e1eM+wKfeM7BZ30zGpwTgYz+QqU8CxJKZacczdVHcD8xIsgSA7jBfKuRXzSJTwgSu+9g7n/IIuapQJnpz7JnS1kyNYdXrsWCEOI7SXU1xpWlTTs3rU8Wv1OVLrD41lrklw9gZ8KKgwBRpGTG5NS6Ggzq3Vti3TKH9cOLxjEkxvFFWkYgE4VyENLBmQ7NIUNL5AWEkHi09HBEgA/BczekT6lbN6ZKFASvm/EIPqVIqEeL7v0YsVkCbSHsq4SG26pRZixRbNt7NM9AccKxbxblUBXkcBr5C1Y8o0Ld43gAgNHgcX7f9DnlGDOQCBgL9bcGhGMTziXTRl44VI6M5JdvGse+Du5I7eBYKdbTxKfslfZDVwetF8uYJtFryCDdltkdNoXmXo4H78+v6NF06m3+cqSMpqy9qx8gFIttQULzYnL/dQ4u+xWiGBIZEG8iDXHtus2qwlPBwk2pnYymf7HEKvIMhh4DkgxlH2n3Nfs8DP9mxYoYmAxjH92jHsaxCf35RagmYq9QQCCa1LRIhOnYlth1nIumEs/+YgVrvEqgEet3/HAJNs+zJNNUn54W66DuYhw8GM6NWNIr+a/tQ9cFkN/Pkv6kd6VIMqPXgpU90Mq8YdN+tzhwNQHyg64UKXtJvCoqqyJvaPFzhRS/iX5e5fOS3TKuZjbqeO6nvDyY58DteFflWBEhKP4/FESp627WFSEk8clVaQT0EiQCHa/jawyj0XeTkn42VsQ45iJ2ipCOjgQQlL7SznwMCVvVo+sQnBm3+/ll9gV9ykgIis2N8hhBcb5K4XenI6yADHDS1qH0MwC5DRrK9ijqGvNwWI0l83gf7rtd/kisnlhm8ylKK6rCYiMK35vW+v1BBt6rLbODlWk4GkYPFXVFbaSgQNWif5BGYJCRP2NUItYt HsjVOYC3 fwYgAww4JIQekMkABDQk0Vlq2obQB70XK7xlj1V8F5VF0+ibaMDf5/WmGYIHKR5pOJxzFcLtDYhdx6YyyBwVcAl+9favSbezJuR8j16ryxn6mJ3HGdv+Z8cceC0/s4X4gjIETUfzRpU3qQvMMuG65ZaLwfQ+aqqqC/6354Bpt5qEX+Yhx5xube70naMCnDc8ndJiPgXyUWmM4AMqGvYATYIGCQgdj12SvwSUvKNO/k+KX/HmDPlxQSHa8xAByiun8B+l9mhNiPe+7B6orMkNCdYtTDw== 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 Wed, Aug 9, 2023 at 11:31=E2=80=AFAM Suren Baghdasaryan wrote: > > 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 thi= s 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() end= s 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 b= ut > > > >> 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 loc= k > > > > 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); <---- generat= es 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, righ= t? > > > > 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. Yeah, it is somehow related to per-vma locking. Unfortunately I can't reproduce the issue on my VM, so I have to use my host and bisection is slow. I think I'll get to the bottom of this tomorrow. > > > > > > > > -- > > > Cheers, > > > > > > David / dhildenb > > >