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 C15B3EB64DA for ; Sat, 8 Jul 2023 22:36:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9688C6B0072; Sat, 8 Jul 2023 18:36:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8F23A6B0074; Sat, 8 Jul 2023 18:36:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 76BA88D0001; Sat, 8 Jul 2023 18:36:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 6174B6B0072 for ; Sat, 8 Jul 2023 18:36:31 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 26A0016024C for ; Sat, 8 Jul 2023 22:36:31 +0000 (UTC) X-FDA: 80989904982.27.B4D5CB5 Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) by imf30.hostedemail.com (Postfix) with ESMTP id 5652980003 for ; Sat, 8 Jul 2023 22:36:28 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b="Jg/dnV7W"; spf=pass (imf30.hostedemail.com: domain of surenb@google.com designates 209.85.219.179 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=1688855788; 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=GM81ytcQAbvY1rpHjBMQS8O2py0eRXT0atPhQXgjA54=; b=AbUUjw9vgGFQwMciZMlRWX0UvYuzzKclU9h9FlOq83Y2PhnVREXCaW4ovR7jdWndava1oH zDleX6HD7u4MDZ5/p8VqEvXl3JSvcdSQs8B6KrvWqEOWmJh3hSscXF/XD9KNVpVYAk6Ov+ ZfeDevp5gAe7MG34tT8P/jLJMjNG1D0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688855788; a=rsa-sha256; cv=none; b=WulPamlWVfeRmfZZ9MapnhRehVx4mmYwJnTx93vMR2UmB//L1sN0VKfGWs37ZAguCGyLLT /SXWaQ2jzJhBC0ubLSVAKeccvCBQRaUKQzMSf2nu2jlG8XedtKwD/tGkUe/yob6dppjlRw eH486MJFJ0Z1hhJWq+4akfNp8Llmh7k= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b="Jg/dnV7W"; spf=pass (imf30.hostedemail.com: domain of surenb@google.com designates 209.85.219.179 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yb1-f179.google.com with SMTP id 3f1490d57ef6-bcb6dbc477eso3099344276.1 for ; Sat, 08 Jul 2023 15:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1688855787; x=1691447787; 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=GM81ytcQAbvY1rpHjBMQS8O2py0eRXT0atPhQXgjA54=; b=Jg/dnV7WFpsjyNkLXFSJxvrYIbV5y67MbDJvmLrUOpsSl1LalBxzIJWHJrFfJSep+L kfZUq9UEYRlcCIgngXW54qsHIAzed494k22aoeQDCFY4ti+EvUlIb1BGsWldwxkxHI+Z T0O1rSIqZmQLXjw0ciOxBZnryw5KfH13QEmjeIwQpMHYqnDxWeFqRwsi0j+AkxhDt5Db PubOIUcLGyJx197rF2uJfbZ9Yjwt9Z7yJB0/yJIrVGW9K8Wcc2dwI+q9RUKuLpMhIfMV 0O1pGeVudSwRXlE5gEeIlz84wqdwxg/t6UU9/nN9EWZGGgMME7nrCyrW+oIZPuLQydV4 +a4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688855787; x=1691447787; 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=GM81ytcQAbvY1rpHjBMQS8O2py0eRXT0atPhQXgjA54=; b=I72Ays2XX6cZmpgPL1DwbBTJTHAYLdglzSTl4KXDUrhncmZkWVX40uTQ//A6/YeC/F xAIPUXdNv16QNlx9ObYUhsNAwMQYDTHuNhwDUHSA4wD0p5eozv9wUGPvwjcxNqRXPu95 Dpjuvmu6ZPqwTGrYUhwXKH43BBVsfNKgeTrkbcrR0Kyd/mT+SNWBtC0A/p4wUzc8SBxa E1gciix/e4MljTvU2BY+9ZFk5G4eAyMQRF41xKC344e4CjBnCUzDpn9eIhw2UfDNNIsn s5+ZsH6PlY+poBKtPpHuF03EtbzkXnR1czG6SNMBDj4Go7HGyce358AemnTlnc/ZmCvj 5YCw== X-Gm-Message-State: ABy/qLYhgah+/06hthfsWu074rs0Q2nnc+pwZK1OpA3AnjCqmVBDoCXC A50wG90Digx3iM/DQuChiw5ZLH0z+LPD8u6wK+NHLg== X-Google-Smtp-Source: APBJJlE9QX36fmJ1qqEKpR7UCT26mt3D5smIFQ/5C5ArBlb6gmqPuqIREas9VSsGWwWtUdtNurt1pOKbRKnjQvM5CU8= X-Received: by 2002:a81:7741:0:b0:570:63d3:9685 with SMTP id s62-20020a817741000000b0057063d39685mr7997297ywc.25.1688855787129; Sat, 08 Jul 2023 15:36:27 -0700 (PDT) MIME-Version: 1.0 References: <20230708191212.4147700-1-surenb@google.com> <20230708191212.4147700-3-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Sat, 8 Jul 2023 15:36:15 -0700 Message-ID: Subject: Re: [PATCH v2 3/3] fork: lock VMAs of the parent process when forking To: Linus Torvalds Cc: akpm@linux-foundation.org, regressions@leemhuis.info, bagasdotme@gmail.com, jacobly.alt@gmail.com, willy@infradead.org, liam.howlett@oracle.com, david@redhat.com, peterx@redhat.com, ldufour@linux.ibm.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, gregkh@linuxfoundation.org, regressions@lists.linux.dev, Jiri Slaby , =?UTF-8?Q?Holger_Hoffst=C3=A4tte?= , stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 5652980003 X-Rspam-User: X-Stat-Signature: 4sgz76kjjcshnzwou4waw1etyks8e8fk X-Rspamd-Server: rspam03 X-HE-Tag: 1688855788-235746 X-HE-Meta: U2FsdGVkX19B9bMFuHRoKpwOt22FPRMt4i9R4G4jAuc8e+X6F1GkKvLK+fXDEjAk64SO1haLAVHfLm43sLDp9Zf77fYg4uHuzq5iHuNfTeB6CIpzm2YIOrxiyJUkbgcAr89QhoL2NxB+ISp6QuufRNDs8WCRfRDBMvDUmGj+dUFKxQXq1ETFXIor9HxzI7n6lm6Qyjo+Pi5qAe3clboWtIzTuz4sb9OiPRo4bWKBxGA29Fx+h2EX+rlKznYfUURD2ToipOH/K3U6WLxDI1M6TnmUJEi9pZDkKu7NLauDhPRc6yO5otl83xnqGga4Vjyeqb25s21VC1MEJLdQa+UWtIqWifw0SsMxcVPi1JgV+fFNP0CfTsKsbWRe7ldnMUiKvKIkTzYDBHR/REHu30fevV4A9jeeVd41ldhfk2eUBYEQ8lYig1qFbvTZZJGSMLvxiVwFNHvS32irQuBuDG0abQ4Q/YTgVC22OhiJ2WAbiQLqSjnyMWLvkkvJZWNfepTxWbkFJM/UhlNpaoq3q9720x1JLWYwhP50KfZQYJDOG5FjHuJmTcgaopz4XYNHZU5aI9nRut9BWoMISuizSYhfkydRrBEltrE0/myUADyerafrHmptrdZ+thEPZ9i9G7VPOhSSShZnKQq2m2073jq6x1rM2o14Iy2qtHKuOVwxjgBK5FDVUvO9VMGESNmeqBvxUN8Hl39F0A23eYIRO4Z78ZndHp+UjHNR8l4yHbDAXsu7aTMVTPtDBPLJWAi/488hN1Ifq0Drxbr58ZQc8tixjcMz6Eyyae/uO2TH1oCVWuo0AHIDFWo6Dxg8Ag9E6xVqcyJPPjYNFZvq2IvfnnyVvnyeIvZoTxBvOOcaebRIL1ytGvJqyuNNd3DpoZA1G4ZrUOPCq+h8g9UFm7FLqDcbB5AsHZXLmMt87talo/u2PqmGHQ7rpejq7QZlQHYCuSRcDlJib8+NaBM+0MJRa5D GcddPVkH aFk0CTTdS0VQX/YRMO4pgUy+YnstC4+r9LIbzbKOwx3PScVieHofeA37/eicOrm50zvFExdanym/7QNsJuesJNZ8OAqg39zeCkRc6tRR5bVoauJKHGFCjojAr9ntt5K2EIXrDj5H52v5/bshy/Br7c7zCLRc9URwFGI9SydLr+FY1Ay/Y+zds4ukzd2E3iPQeAaS0CutEysYMHCbSr1J+/FeZw559pKblUlQZS1JomWl1PfTrvApmJjbfqe94z8MP5rdvJiWjV3pJEC5GrnwcAjdnkIhZHpVyLPhXLqj3SoHpXOAwF5xD8ZREDOdMU3H5fDT6Ih85MlzHMkchXcb8QjPDwGnr245I6ossH2BFdL1gRTzeRga1VLsGOcLcebscLKgm X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat, Jul 8, 2023 at 2:18=E2=80=AFPM Linus Torvalds wrote: > > On Sat, 8 Jul 2023 at 12:12, Suren Baghdasaryan wrote= : > > > > kernel/fork.c | 1 + > > 1 file changed, 1 insertion(+) > > I ended up editing your explanation a lot. > > I'm not convinced that the bug has much to do with the delayed tlb flushi= ng. > > I think it's more fundamental than some tlb coherence issue: our VM > copying simply expects to not have any unrelated concurrent page fault > activity, and various random internal data structures simply rely on > that. > > I made up an example that I'm not sure is relevant to any of the > particular failures, but that I think is a non-TLB case: the parent > 'vma->anon_vma' chain is copied by dup_mmap() in anon_vma_fork(), and > it's possible that the parent vma didn't have any anon_vma associated > with it at that point. > > But a concurrent page fault to the same vma - even *before* the page > tables have been copied, and when the TLB is still entirely coherent - > could then cause a anon_vma_prepare() on that parent vma, and > associate one of the pages with that anon-vma. > > Then the page table copy happens, and that page gets marked read-only > again, and is added to both the parent and the child vma's, but the > child vma never got associated with the parents new anon_vma, because > it didn't exist when anon_vma_fork() happened. > > Does this ever happen? I have no idea. But it would seem to be an > example that really has nothing to do with any TLB state, and is just > simply "we cannot handle concurrent page faults while we're busy > copying the mm". > > Again - maybe I messed up, but it really feels like the missing > vma_start_write() was more fundamental, and not some "TLB coherency" > issue. Sounds plausible. I'll try to use the reproducer to verify if that's indeed happening here. It's likely there are multiple problematic scenarios due to this missing lock though. Thanks, Suren. > > Linus