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 28319EB64DA for ; Wed, 5 Jul 2023 21:09:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 813C28D0002; Wed, 5 Jul 2023 17:09:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C3168D0001; Wed, 5 Jul 2023 17:09:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 68B888D0002; Wed, 5 Jul 2023 17:09:48 -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 561F78D0001 for ; Wed, 5 Jul 2023 17:09:48 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 2A30040127 for ; Wed, 5 Jul 2023 21:09:48 +0000 (UTC) X-FDA: 80978800056.22.F45C29C Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) by imf23.hostedemail.com (Postfix) with ESMTP id 4D39E140014 for ; Wed, 5 Jul 2023 21:09:46 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=UBG5+DvK; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of surenb@google.com designates 209.85.219.172 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688591386; a=rsa-sha256; cv=none; b=wR2kh/l/XqVNdxr8wmpOTk/AoTlLBZyyeqvfe8lQv3CW4Xn0JYiNRSeKtWkPq3Qs6GMngm lIDVTUpxCQ/Q2BVSXMbmWFuKU8OnbxcRkkFKsGSl4W6RtAurZIwrbNOtT3a8Kjs3GoQtOM zHBoHg2aTg0WRFAY8pAVxu+xpeXEoKM= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=UBG5+DvK; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of surenb@google.com designates 209.85.219.172 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=1688591386; 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=NaGMTa0DbN3c8dwMUOQDzcTZPQ/M8amf44bbRz7BEX8=; b=j/+0YkFAKvMU+hf6Kyo6e4AZUysoFsOhRVyYJE+efW4TPKvyQyY0uzK/RV7VU1lPKhkm/z ownZi5uRj/fr/kCnezeae5PeDoOzgmjn1xxpXE+DTxMNoR/0g1KqUsZSRESeYdwZ1XyLPm y6YJ/U6myxRzJ9cFWLhTOkVCL1eIXJE= Received: by mail-yb1-f172.google.com with SMTP id 3f1490d57ef6-c5079a9f1c8so4619909276.0 for ; Wed, 05 Jul 2023 14:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1688591385; x=1691183385; 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=NaGMTa0DbN3c8dwMUOQDzcTZPQ/M8amf44bbRz7BEX8=; b=UBG5+DvKOvH7qCjkiEDp6J4u/q3uj4JRG5ekSG6AlIb7zKH+lcIHdZemv8svEgfwsq QL2DFDTL5EYIS1YkvcISRvfWkCeJfhy45+8NBPenPJm7CWNNg3PhBCXFlpcSAn/jOXP4 n9Cgp59YaiI8MgDIA6HnTpxQW/ggXhpyp1ohN9+CzWeWadofYwPRIMRlkm1x2Xm1VYG8 ghtB9xIab0YgX3DLDz25CKz+nKAH4G6SPV9yDzieTA9YRIkd8nfRLz9mjNvjq60c7lkq rWVGWwiFrQGjFGgjSun32TBndFiuhJWJ1G3rCfc83ykWM1tMVDLHOP7INWALmvvJ6sso Anog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688591385; x=1691183385; 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=NaGMTa0DbN3c8dwMUOQDzcTZPQ/M8amf44bbRz7BEX8=; b=SY4gZwRu3kyIikFUtU9B8RbQlQsU4ryqSPoTrP3tuerCmf7u//6E/oFYnCKq+VVf77 8lKWXxFXaArN2EorpEmLrOUn9dIL/oDUE1lJ58OOKBMqjW3WzK7nixNB+CF6t/ZKQvOV 0izH1T3hrWGyqE4IruMYMNLseQMMo7qEY49ULgjhB7GYcrluxSdEgX7oKUs/QJojz55z 0YmKun491V7NeNxy+tBHDFDcUu2ZuhFNcNVxVJjBI93XHer/9ZV6GJBXy5IoLVbNC4Xp TqfeLZM9JnDBN1KLtLnGyn7uC4g6pfrFMBBnbVfL0wTj6T9uYh5O+M3RBDkXYefE4tJh SNFg== X-Gm-Message-State: ABy/qLZXvvhG02G9nn2AHBPg2x+e9QXBCsPrRJY2xYfb+r0n6LJ+Nj2v RGSDx2E5xCI8SBymR/g1ujuj5U/LYkuewJGxeM17yg== X-Google-Smtp-Source: APBJJlEMfph7t7wJWllYEpACDgeAzyYwh2jqlBg6bNRDARLEVdUNgL/soI72nwZ79kZeqNq7mcFxbIQLP+5i5Egiq3M= X-Received: by 2002:a25:4ed6:0:b0:c63:5334:9d10 with SMTP id c205-20020a254ed6000000b00c6353349d10mr64531ybb.3.1688591385152; Wed, 05 Jul 2023 14:09:45 -0700 (PDT) MIME-Version: 1.0 References: <20230705171213.2843068-1-surenb@google.com> <20230705171213.2843068-3-surenb@google.com> <3cdaa7d4-1293-3806-05ce-6b7fc4382458@redhat.com> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 5 Jul 2023 14:09:33 -0700 Message-ID: Subject: Re: [PATCH v3 2/2] mm: disable CONFIG_PER_VMA_LOCK until its fixed To: David Hildenbrand Cc: Peter Xu , akpm@linux-foundation.org, jirislaby@kernel.org, jacobly.alt@gmail.com, holger@applied-asynchrony.com, hdegoede@redhat.com, michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mgorman@techsingularity.net, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, peterz@infradead.org, ldufour@linux.ibm.com, paulmck@kernel.org, mingo@redhat.com, will@kernel.org, luto@kernel.org, songliubraving@fb.com, dhowells@redhat.com, hughd@google.com, bigeasy@linutronix.de, kent.overstreet@linux.dev, punit.agrawal@bytedance.com, lstoakes@gmail.com, peterjung1337@gmail.com, rientjes@google.com, chriscli@google.com, axelrasmussen@google.com, joelaf@google.com, minchan@google.com, rppt@kernel.org, jannh@google.com, shakeelb@google.com, tatashin@google.com, edumazet@google.com, gthelen@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 4D39E140014 X-Stat-Signature: enyuja6bjqwdd7kazh9iwu8uo5mpzdsu X-HE-Tag: 1688591386-511035 X-HE-Meta: U2FsdGVkX19V2foS0t7lgKncIMinAwziZ8mgyfomFu3Q4duTl5sm9w1Dyz4jMfu84Xq+TpubR7AaM7f4w7V2/eIxn6Jqt+xWPJXDjZCztTTGOTNjhziwJDjbY80ctuMJTZVt7bK0DVBRyPwKQX7V7YS7pu1XPQ3NRkqb3H6QMtxgiDjHPrn9jDkdUj2nWCtookt1Zj0WqsqXWoGXiH8QQ/j0x4auH6ym3H+mL3Pj0h6ubWvlgtYwb7BpdO6e+jVz7OOktfJIlA230RJv9tIlEx/LTZIzl5A7zK8SN+/xlgl6ZUd0ETVGZUfY8Hfg12LvdXVTFiSmgGX+Ak7wlqt8Utuaa864I4/Ri//cAPlHL/LBt5B9hRckSn5JCHYvbJASkVSn4ZojxiiuclWw6T/snLJVK+CgbsG9zohDRkRX7hTCgyL2sCVSSpW0tLMQSaCV+u7S+GVbMOQZ/tnK94G4RBNaOFxIR9uKg3NJFPK4djFFPAM+UNIIOiUJgPNWrXZYHr7C//s0YJ8QBvDjz+UuE1CGT7eKLyhKFXmXHZqKYSp6Ahl8Jtpzi5WIV7SPHacNy4frJ2gEOX8Iptxo/p9WwABc1jO8yapQQ43NqazUbkB+/D0UymQ5ekbnt9qZy7S2dgOABhL+QfXdFY/M+gZ7VSaBMNSIUUlQLdXYoIDoMSzbn3KWv5nKn1aZLhCyuUojvzOvHfiwvv9DoO1q0vHOqpdyPrWfPdl1/Q5OrAUArgBx8dzR+1/WUzDCIc+VAdrlf95uFcd+cY/kYWp5uDM21hnsNFU8TgzvQCilVqp/Ew0dPh3STwgbtPr4CFsdqE3DLlOspkwfh3x4xcXLYyjrFtQiSjxRhYWZRRY2pHlgDT4KKzD8HjZvh04nezG9WhkRX3ztsEsho5frrCQ2Si2J2m8cNlBd0z01BONZoUDbKgyx8kgkEHqbeN0+wiOtSBO9p4AvQi5Dg4+62WSeB/v 4RZhjfbO nEKRhKNDVJwAfpb9mnIMNZd6IZEsWthoxa3KvJQen+m8UDfn6SDXXvuq7OsZ1gJPBMwD/VDcjhZVB4DhxvklbMSmxnUWAlPFQ2+6WwUDXCjUKM6/cITvO5aUGPmJClecBwnPX7eojGcG5aMLZVlVj5YYpcx/ke08rLS+szUK04kR4DQctB6VPWfu8Wg50GQ2qJdC+IefYa8bsrPjSeD+Lkkas1VipeGKt9UBoF3/SPfVwTDiejggYhVIK9c9092rnoTvdOZCh16E3qLij0QkR+b9zaU8+okYsqSjymnC21SsDuBPeMV6EmrmnC6yxKh9AZjzB/gS3TxgMfNbQRQePAcAEv59Xmh8EAKczLCnlrlK3nUbu3XBgDjPb3CtkmSXEOPfbMAEBEWXJAJ6B81X9Vra/LbHuipJYcbs6wMXPToMT3e+p+0CMKNbI0H2eC5V4KOjUhRGZqcJA7vm/TByv8SsBftmDmeP2EJ8s 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, Jul 5, 2023 at 1:37=E2=80=AFPM David Hildenbrand = wrote: > > On 05.07.23 22:25, Peter Xu wrote: > > On Wed, Jul 05, 2023 at 10:22:27AM -0700, Suren Baghdasaryan wrote: > >> On Wed, Jul 5, 2023 at 10:16=E2=80=AFAM David Hildenbrand wrote: > >>> > >>> On 05.07.23 19:12, Suren Baghdasaryan wrote: > >>>> A memory corruption was reported in [1] with bisection pointing to t= he > >>>> patch [2] enabling per-VMA locks for x86. > >>>> Disable per-VMA locks config to prevent this issue while the problem= is > >>>> being investigated. This is expected to be a temporary measure. > >>>> > >>>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=3D217624 > >>>> [2] https://lore.kernel.org/all/20230227173632.3292573-30-surenb@goo= gle.com > >>>> > >>>> Reported-by: Jiri Slaby > >>>> Closes: https://lore.kernel.org/all/dbdef34c-3a07-5951-e1ae-e9c6e3cd= f51b@kernel.org/ > >>>> Reported-by: Jacob Young > >>>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=3D217624 > >>>> Fixes: 0bff0aaea03e ("x86/mm: try VMA lock-based page fault handling= first") > >>>> Cc: stable@vger.kernel.org > >>>> Signed-off-by: Suren Baghdasaryan > >>>> --- > >>>> mm/Kconfig | 3 ++- > >>>> 1 file changed, 2 insertions(+), 1 deletion(-) > >>>> > >>>> diff --git a/mm/Kconfig b/mm/Kconfig > >>>> index 09130434e30d..0abc6c71dd89 100644 > >>>> --- a/mm/Kconfig > >>>> +++ b/mm/Kconfig > >>>> @@ -1224,8 +1224,9 @@ config ARCH_SUPPORTS_PER_VMA_LOCK > >>>> def_bool n > >>>> > >>>> config PER_VMA_LOCK > >>>> - def_bool y > >>>> + bool "Enable per-vma locking during page fault handling." > >>>> depends on ARCH_SUPPORTS_PER_VMA_LOCK && MMU && SMP > >>>> + depends on BROKEN > >>>> help > >>>> Allow per-vma locking during page fault handling. > >>>> > >>> Do we have any testing results (that don't reveal other issues :) ) f= or > >>> patch #1? Not sure if we really want to mark it broken if patch #1 fi= xes > >>> the issue. > >> > >> I tested the fix using the only reproducer provided in the reports > >> plus kernel compilation and my fork stress test. All looked good and > >> stable but I don't know if other reports had the same issue or > >> something different. > > > > The commit log seems slightly confusing. It mostly says the bug was st= ill > > not solved, but I assume patch 1 is the current "fix", it's just not cl= ear > > whether there's any other potential issues? > > > > According to the stable tree rules: > > > > - It must fix a problem that causes a build error (but not for things > > marked CONFIG_BROKEN), an oops, a hang, data corruption, a real > > security issue, or some "oh, that's not good" issue. In short, som= ething > > critical. > > > > I think it means vma lock will never be fixed in 6.4, and it can't (bec= ause > > after this patch it'll be BROKEN, and this patch copies stable, and we > > can't fix BROKEN things in stables). > > > > Totally no problem I see, just to make sure this is what you wanted.. > > > > There'll still try to be a final fix, am I right? As IIRC allowing pag= e > > faults during fork() is one of the major goals of vma lock. > > At least not that I am aware of (and people who care about that should > really work on scalable fork() alternatives, like that io_uring fork() > thingy). > > My understanding is that CONFIG_PER_VMA_LOCK wants to speed up page > concurrent page faults *after* fork() [or rather, after new process > creation], IOW, when we have a lot of mmap() activity going on while > some threads of the new process are already active and don't actually > touch what's getting newly mmaped. Getting as much concurrency as we can is the goal. If we can allow some page faults during fork, I would take that too. But for now let's deploy the simplest and safest approach. > > -- > Cheers, > > David / dhildenb >