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 002EAC30654 for ; Mon, 3 Jul 2023 20:30:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7C8D0280039; Mon, 3 Jul 2023 16:30:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 77764280030; Mon, 3 Jul 2023 16:30:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 617B2280039; Mon, 3 Jul 2023 16:30:09 -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 52350280030 for ; Mon, 3 Jul 2023 16:30:09 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 09A80160235 for ; Mon, 3 Jul 2023 20:30:09 +0000 (UTC) X-FDA: 80971442538.22.BAD14E4 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf09.hostedemail.com (Postfix) with ESMTP id 0B01514000C for ; Mon, 3 Jul 2023 20:30:05 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=aVBP10Ca; spf=pass (imf09.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688416206; a=rsa-sha256; cv=none; b=Q+xsIZop05RbflVxOKxMIDvFzIJfdEVsuwR6J/YA9C6D+5ik3eaFGsVp2zYq93G9LhBQga ITZ2w/0Ae6WNaj4bOWcgXvrbSOCEAxifC7Q0J0I21jRFH465garq6RQhlMzMmo1he50aU6 oiih3B9eYJW5qhZTfFe8KhzOwQhNNeA= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=aVBP10Ca; spf=pass (imf09.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688416206; 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=afoUmYIY8l93sGJNbVa3FYvae8i+/AEKuc2v5qd2tPQ=; b=el0QdoRhDG1ywLnEB59FaZ1vBPLs/oZRrBq5aWQqDsZFs8Clxk4XKoSyr1ODhyFFDE6KfN hUX9Uc1bMdD2YoHsys5zx+EhvvBIKx3ePMZ7cgb/ZUGRLFHy8UcSFCa5PdOLwXAL9lxlRn RzN+1YP/Ue00vv+bPOVDN28U6kHiQ1M= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1688416205; h=from:from: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; bh=afoUmYIY8l93sGJNbVa3FYvae8i+/AEKuc2v5qd2tPQ=; b=aVBP10CarUeJEk2qTbC1sCA+CH/7btdmGbAUinHMdPDysvxE0ptJjqrwkmbwwxt4rmAA4+ qoR02oXDmxsR/bqvcx4XSEB8/8HJbPZyE3DjPOjH0Qx4BihagifMJRVtbh8IdKzAJEuAH8 JpqbzWx/5PU01unUH4y2qrV25bMBXg8= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-350-rSYB3PAdMuqi9URcPpoPHQ-1; Mon, 03 Jul 2023 16:30:04 -0400 X-MC-Unique: rSYB3PAdMuqi9URcPpoPHQ-1 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-3fbdd5d09b8so4701165e9.1 for ; Mon, 03 Jul 2023 13:30:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688416203; x=1691008203; h=content-transfer-encoding:in-reply-to:subject:organization:from :content-language:references:cc:to:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=afoUmYIY8l93sGJNbVa3FYvae8i+/AEKuc2v5qd2tPQ=; b=XOQF6P4gOcrqCU8Uqu6fcN5e/gu8EcriNxgOAbTHsHo0JmqD+bSpfELVUHfifk2mN4 berlXtygCzbu4mfkNIto0Q5ntVblu3Hr9MmgygW7cnyTcA5pLt14KJOni1ZH83Eu4pa2 UB3J/35h621eJBXAn5DxFykgXDRnglY0GF4am0KbdAEPP63EIz10WcbIpNP3lgXLI4GG TqtKrjcMX1R6uGNypEeib5Iq1HTr+y1PiXmL7V4C0ksGmZWKAffK/sNIXN2Ycu1aCpQ3 yEQAUcuQ81LqmaND/YiqIDiRCN0sPfuGt83/M2tROTxemJYa34FIzH0Laxm/CQHUXQso xlHA== X-Gm-Message-State: AC+VfDw0sbOZY6AM9ZOcmhaNrXywv5wGECmzNGl3BliCykGjFFzek6P6 xQrjRQbZCH9xxSMVTQvV4GRYoohPzltvDoj2uyWqjGnKQde6H6FliY6P74RWQJwYBdeLgSXB+jg vCC/jLp1p18k= X-Received: by 2002:a05:600c:2305:b0:3f8:c70e:7ed1 with SMTP id 5-20020a05600c230500b003f8c70e7ed1mr10567440wmo.20.1688416203422; Mon, 03 Jul 2023 13:30:03 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4jgRF4gv+o9IFzkzksMw8GQCKc0JQrEvmfXdzwKdsSQPozu3L0u4nt5ei/i2L9vanH9fPp3w== X-Received: by 2002:a05:600c:2305:b0:3f8:c70e:7ed1 with SMTP id 5-20020a05600c230500b003f8c70e7ed1mr10567412wmo.20.1688416203075; Mon, 03 Jul 2023 13:30:03 -0700 (PDT) Received: from ?IPV6:2003:d8:2f30:5a00:b30d:e6bc:74c3:d6f2? (p200300d82f305a00b30de6bc74c3d6f2.dip0.t-ipconnect.de. [2003:d8:2f30:5a00:b30d:e6bc:74c3:d6f2]) by smtp.gmail.com with ESMTPSA id d11-20020a1c730b000000b003fb416d732csm20413331wmb.6.2023.07.03.13.30.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Jul 2023 13:30:02 -0700 (PDT) Message-ID: <7e3f35cc-59b9-bf12-b8b1-4ed78223844a@redhat.com> Date: Mon, 3 Jul 2023 22:30:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 To: Suren Baghdasaryan , akpm@linux-foundation.org Cc: jirislaby@kernel.org, jacobly.alt@gmail.com, holger@applied-asynchrony.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, peterx@redhat.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 References: <20230703182150.2193578-1-surenb@google.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH 1/1] mm: disable CONFIG_PER_VMA_LOCK by default until its fixed In-Reply-To: <20230703182150.2193578-1-surenb@google.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 0B01514000C X-Stat-Signature: 7qr69ph316bgb8ipnpo1mn54f4xd6iay X-Rspam-User: X-HE-Tag: 1688416205-385204 X-HE-Meta: U2FsdGVkX19ZmFBJW/KvHQFEBxIsv67PEWgMmv0G7+AXnFpx/8yx5VGRBpWSqDFzAMgHCuJubZaXVIHR4ZU450IwZnVBteFB5F5eckoi9Njv4C1GFS85zbYyJvGorS3Hbqh7YccBlKX+TSneuNLr9Ir0HAbYDkVu+3kw10xtjnMOYgjddTiHrG7mwr2xYqhObUEXX0OuV+1yhQ2uBupCb3zm2E/lM6Z5BVDyBJqq2cGp6AsSKAkJchNiPimaD5OSf88sdKLRieYX9ZNDmn6D2uj/l/PwwDugxouO3e9wwd63Ctqc7wTe+fa7BVN8dVhN15S/P22HygFGkgslElpqMG9UNt9CofZkDsuwEPPiu0EM4TL6goDLNSVSuXIsqJ/qh1rtvwEeeHohYEgIPSy2jTuPPsAi1/xY40gap2lMpaKrRYYsQCXcIcAJf5s23gQNwupLVJGiYgMQwlK2p8dzYlJskTRN6APeZEf/boqqfGTCmaTfWavfLobGl2chUVQGjuZbQVZIkkO1R9T507dxvF8bLIf+4k9WoquhREjQfeHnzHvClYRzYBU5DUh3SXoZmeDXhp98w+IaRP/BYcMOXz9wvhf/xKmbAC5fYBJFtTljMUO6wHqM0pbWTmSJpghjZtzTaeaHpTpPECJX15C9rlH8BxlnGBteyEc2P9uY2hEXtzcm51XT3iz75RMFzl0VPt+9fUDIETo0uA298ztq9JTek/QHddIqxDGP1nsgpuvEZ5fnVFOU/VpP0EcjtabLQRK+rghWH9A/r5lvpjhgJFX/od781OyLXgMFY8yv+fGd2ovIjw65Mremj+nt27vGIIy9rlpsLFK7KeuOrmz/Y66TZ0KMQte4EWeshQRk3vdpIjSRp8qpg4ix/EeKJ6ij5+/i+1Zk5KJOg0D/uCL+zLGr8CHS+VgSoQaOtLnQwelCR3d999F2zPo2syhzOizNS/SLPq2n7Z1G3WXgedQ GhWXydu2 Gz1LxvKK/YUGmFPYDfjMtA2EvYjSzJjMrwve7WH2zvpZ+kKfCKa3NKhvzzHPWrXL67N89t6lpqAqAaCxtP+59/QV3+Sqa483t6ind3klVo47kaH9msvNrzb24vRsJ36PK6HZtCS5wbIvdk1RWC2H2DnRi2fXrpMKDqiMGXL+bNq7dgltN49xhgoTgTIvQ7UpWR+pGA1Iw47VKXPfuT2N6Nw8bMjcc0RWvym55Rec3TMxVAGJgP5uLjSj+RZavZF//f/F68SmEqTMS+KMDKljhSXJRl8wN4s2UULqsKXbEnE8KfTdyi6d22RTpOKI4us4mooD3sea4RCUdwafTY39gD0/qbU7Mm2nS/5ikwV42aLdR1WJlz00+qnf3n5KXukVZBLyqJpUtpgwmo2TKj/Mtbf2C88CSG+8442iYOGkEzArJRDv3pNGCcefaE+LLfdna0fRLx6UniaNnSzv6y08Pz/9Pbyv0aVSSgE9a7nOl2n58vykDXUewD6lm7HfdBU+rgsoxFfzuVRFA5Rcqi2mtIyYPmuMSnZi/lCO9S+6/eJrB2QbvNXdwThYJq17i72uMd+k1ypmGTgzbUoHMdVTJCnvoc7p6pabdT/21 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 03.07.23 20:21, 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 problem is > being investigated. This is expected to be a temporary measure. > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=217624 > [2] https://lore.kernel.org/all/20230227173632.3292573-30-surenb@google.com > > Reported-by: Jiri Slaby > Reported-by: Jacob Young > Fixes: 0bff0aaea03e ("x86/mm: try VMA lock-based page fault handling first") > Signed-off-by: Suren Baghdasaryan > --- > mm/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/Kconfig b/mm/Kconfig > index 09130434e30d..de94b2497600 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -1224,7 +1224,7 @@ 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 > help > Allow per-vma locking during page fault handling. As raised at LSF/MM, I was "surprised" that we can now handle page faults concurrent to fork() and was expecting something to be broken already. What probably happens is that we wr-protected the page in the parent process and COW-shared an anon page with the child using copy_present_pte(). But we only flush the parent MM tlb before we drop the parent MM lock in dup_mmap(). If we get a write-fault before that TLB flush in the parent, and we end up replacing that anon page in the parent process in do_wp_page() [because, COW-shared with the child], this might be problematic: some stale writable TLB entries can target the wrong (old) page. We had similar issues in the past with userfaultfd, see the comment at the beginning of do_wp_page(): if (likely(!unshare)) { if (userfaultfd_pte_wp(vma, *vmf->pte)) { pte_unmap_unlock(vmf->pte, vmf->ptl); return handle_userfault(vmf, VM_UFFD_WP); } /* * Userfaultfd write-protect can defer flushes. Ensure the TLB * is flushed in this case before copying. */ if (unlikely(userfaultfd_wp(vmf->vma) && mm_tlb_flush_pending(vmf->vma->vm_mm))) flush_tlb_page(vmf->vma, vmf->address); } We really should not allow page faults concurrent to fork() without further investigation. -- Cheers, David / dhildenb