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 AA66CC001B0 for ; Wed, 5 Jul 2023 20:33:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 38C058D0002; Wed, 5 Jul 2023 16:33:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 33C858D0001; Wed, 5 Jul 2023 16:33:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 203C18D0002; Wed, 5 Jul 2023 16:33:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 0FD4C8D0001 for ; Wed, 5 Jul 2023 16:33:41 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 98D42B01A0 for ; Wed, 5 Jul 2023 20:33:40 +0000 (UTC) X-FDA: 80978709000.30.C14E07D Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) by imf23.hostedemail.com (Postfix) with ESMTP id C0D92140007 for ; Wed, 5 Jul 2023 20:33:38 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b="E/oyqVJw"; spf=pass (imf23.hostedemail.com: domain of surenb@google.com designates 209.85.219.170 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=1688589218; 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=T1q7IeGvTepjJgfM/Bv0KzPttJZyBwk32UoGcJKZEp8=; b=jkz5sroYsc91/P+Ne3d2xkHdPs5o/Hrs4Y9Go1Ex7rbkNLkagOAyEfHNAT+JlWtLrt9f4N hAcngX5dq+IojKPhP1X+A7ax3wCQ7iYthQlOoW9KpnS8hA6QzD4uoJakX6d4RV7/mccnwc rucMYRcqtzL+r6vBDeHq75S846GpoMA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688589218; a=rsa-sha256; cv=none; b=JlE0o5D1aTqUMC+S6EK+n9Kae5S/IcrrRDIsvZd1dIKrDljQ/t4ckstI9hZsRlYNiuDK5K l5vkHW7k3232DS3+4JX7mGwhzuEQUEDP4KXhTAtlkB3wn7fI5PCoNjF6N3T5ecCQ9ui/2n qCcr+qTyLVMkSVvY3j4OtO7irNfQtSk= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b="E/oyqVJw"; spf=pass (imf23.hostedemail.com: domain of surenb@google.com designates 209.85.219.170 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yb1-f170.google.com with SMTP id 3f1490d57ef6-c5cf26e9669so2384802276.0 for ; Wed, 05 Jul 2023 13:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1688589218; x=1691181218; 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=T1q7IeGvTepjJgfM/Bv0KzPttJZyBwk32UoGcJKZEp8=; b=E/oyqVJwy2MtpXYa7LrtYGSoRRZLuREVvN8UHHavBb7S3BzfCTIcQKWYpTe0q0DCE5 jX++6+Jf7oYAfYMMxftW3i8trzP6LfWQyvQgud93bdJMZwZnkAY+WSqJ1dHzIQWje5XT O3kCqd7YVKtdYpwSrj5X5BzbqEIehHYoll8Jec5au/2nTDcem86kp/WBcIrzH226ltdH OF01kdAzwDPER5Dr6qXxADIEBvcU7TO/riyFa0Ho9ZJ6pSRl+F1uSy6NyjNX8RkMPURZ PY6FAKS6Ys4B4kzQzKFSbFefKr6SP41jEiOc/3TyBmT7XCNyd7imP4KclVGhcvZPcwl4 8YGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688589218; x=1691181218; 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=T1q7IeGvTepjJgfM/Bv0KzPttJZyBwk32UoGcJKZEp8=; b=Du2LVTFgsxxyHcbsQWwBLxdN83WPa5IwyHhc2ZN2ZbIOZ7VFn0480nmD6laFTeoRKa 0glem7AjVoeIIWRXBesJVRaF3AjzKWIGFo7R+QjbU2GIlnKJKxvkpD4bwg4evwYHbyya gQ6aGx6WNd67D1JeLcGOI9AoJYRD+3s+saxgC1p/YXIa+5dC2R2pQBm2Cw6xNfEeiyw/ y8kTWtshkE8V/lJsHNNwMGerviNKQDriz+u4Fdt9Ljsg0CrORU3nGLxNLkpBMvW3yO9D AzX6gdyKcCNxL3VhvSpI2F5ygIbH+D09PgDpy/+OdOeuqXLAr1uuOQyjAxrQh8Ln+F9e eoEA== X-Gm-Message-State: ABy/qLZUQp1zJZRG9a2Hp4vTXDzOCf/aN3gZrJTAtmEcweO02Z5Bsp5c kAv0QTtp0xufWe226Ld+gajZpkUGQAevR2hCtsRvvw== X-Google-Smtp-Source: APBJJlE6sN0xw+eRSL45rhK9sGYnnWa9JpLUCJ1CIXXlH4fJqUPUds1Zo2PYpjstXASQSiP9Wgb2C7djZ194TlVSod4= X-Received: by 2002:a5b:8c6:0:b0:c17:60ec:67a3 with SMTP id w6-20020a5b08c6000000b00c1760ec67a3mr16181196ybq.43.1688589217601; Wed, 05 Jul 2023 13:33:37 -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 13:33:26 -0700 Message-ID: Subject: Re: [PATCH v3 2/2] mm: disable CONFIG_PER_VMA_LOCK until its fixed To: Peter Xu Cc: David Hildenbrand , 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-Rspamd-Queue-Id: C0D92140007 X-Rspam-User: X-Stat-Signature: nbmgqzcmu97tua75prwk3szcyjmmrtrc X-Rspamd-Server: rspam03 X-HE-Tag: 1688589218-514110 X-HE-Meta: U2FsdGVkX19r3ZqyYKxMv9yfHP/bY6fKHkOTCztcRbK0F3tnVnpg+ItI8dt/e2FUhUlLH75JLpg5Tmweb0IMeN32KEd2uZVrGKemSBWXlO52F+o/D6OtRZ8joboEmGqqkTPKqU4xfxg8b0k+gJ8PXDTuOOFUt+dKipb8Ry+sz/SvveOhZjNjEGzIUN+TFWgkxbX1oCaC+p+w6F9IlJPVtWnK1wVwEPOwr2Wi1pkBw4VL63xcaa/Xe0kIEhl5fYaFlzSF0TYS3S2zaTmzT4Rr26OUSC+dD7CKT2IeqUVZxMyr1Gt8jnwY1jV2u8Slsc22qQznsMxzKXaanHLWsI9++yfr7WnnFzmQWNVggb8Rj6X43BAhnCgxVxDQdoKeQ0xg/nV5e3ooptgoDtbWHPOqbL8+dDicSlDkBN87pfZNVJhTk91K7+MTFS04UeOMgNm/8ALpTZ7m6q4SYIUlfyQ0KgaXqng+MAWm9z9gozZxRM/7vwVATOJbJyTa97TfUNytnPeZhZ0urc1NRy3PO+iCYZ2In9NtiI5kGj9NsVvLMQu6EyW8hAW+tB7bse/ePFjffWyX2G49bI6oOJ6p3yf1GJwjxNJIx66QKiOkF/2LinKo6FaJcDeeCjpSrUqbK3Qzz6Dzb+BmWPTXQJeIFUdAjKxkpuGnqaRVqj2IeEEry35OF6elUFzgptRo5P8buishfwaP+TzyoR+S37IferSEBt6iSsAXRxYFkAsq6zJ6/c6EnsmWkHpk9UqrRYnbkgMGEU5YfvUygKoZCaxDLYpgXs2nwqMpAa5/2RfqEygJby7a4Fe4HxdIFAj+MF7UX0GeMcR7aSN4adJpSM1yAeADsZI4FceuvY5y+U4ul2Pt56VDJdM8Wc1fis8DGW9Tr59cAjHHqrKSgh5WINUNeNp5qNxCCsahlO6NDtfiqsmrbBBpr3mTnlpMPFMUDwKBgnef70fjfUjeyhVhp5Fs3R0 3EC/UISb NRh0dhQntfUqkAx47Yj9csceoZK78I1n8XmOGwKVDF+D9mRhEswo52ARENv3rbDTKKxtAHGw9HJ4TpKu1k29ci0wF1spwsPnf+aBsItH74BYVvqcQoAUVKGZ/USCwj4Gn70yoxkUly0q9sbil/oemFe9OgC6/pawB1hETQyR6r4iwRShYbd0KHA/0UpceDmtuSwoXGu0l0j24xnJjgZPFi2TRwGD+Kdj7mM7c8ikDuTgOcieuI8qUogYP1Nx5Jvh16dyqNuBpTWputQAg6/tIjMz96SFyHjVNOiolnV7egAvA+GVm+6EbVD6dPrEI/MqVsN0rH0XnflgYEjSUODu6KYCmSvYizOPs1ieeeqC0CMrlkSClzxv9klWDPyt4AhUAop1kEa4ff21heaXroFuvuG84vtFGdjGSSIeFIoLV1UNmbW26tcrM3uy0h1Cb1UQF0njku50rcubUWaksWOEL5ok4Zb7Jk7O6Zm0W 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:25=E2=80=AFPM 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 = the > > > > patch [2] enabling per-VMA locks for x86. > > > > Disable per-VMA locks config to prevent this issue while the proble= m 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@go= ogle.com > > > > > > > > Reported-by: Jiri Slaby > > > > Closes: https://lore.kernel.org/all/dbdef34c-3a07-5951-e1ae-e9c6e3c= df51b@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 handlin= g 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 stil= l > not solved, but I assume patch 1 is the current "fix", it's just not clea= r > 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, someth= ing > critical. > > I think it means vma lock will never be fixed in 6.4, and it can't (becau= se > after this patch it'll be BROKEN, and this patch copies stable, and we > can't fix BROKEN things in stables). I was hoping we could re-enable VMA locks in 6.4 once we get more confirmations that the problem is gone. Is that not possible once the BROKEN dependency is merged? > > 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 page > faults during fork() is one of the major goals of vma lock. I think we can further optimize the locking rules here (see discussion in https://lore.kernel.org/all/20230703182150.2193578-1-surenb@google.com/) but for now we want the most effective and simple way to fix the memory corruption problem. Thanks, Suren. > > Thanks, > > -- > Peter Xu >