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 B039FEB64DA for ; Sat, 8 Jul 2023 21:18:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B59C78D0001; Sat, 8 Jul 2023 17:18:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B0A766B0074; Sat, 8 Jul 2023 17:18:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9F8998D0001; Sat, 8 Jul 2023 17:18:51 -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 90CD86B0072 for ; Sat, 8 Jul 2023 17:18:51 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 1952DAFA2C for ; Sat, 8 Jul 2023 21:18:51 +0000 (UTC) X-FDA: 80989709262.09.4067AE2 Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) by imf19.hostedemail.com (Postfix) with ESMTP id E1F361A0006 for ; Sat, 8 Jul 2023 21:18:48 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=YAZ3dlkC; spf=pass (imf19.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.172 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688851129; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=NYkpMcCqLkVQ1Acc1vLb6z5Gk8ZLjHpR5RYSSOrvZGs=; b=76cxF+crjYvz1gV3FYOUg1u7EKPZ/b1uSbaPOCOfNRKkZ+Sp3olTCORtqwBwLcPTj7bAav dEJLl+WjjY4+x1nMcY+lo0KkyAS95ug18Y88yC2VoB1EBuIxI2Y3CME4lOO6BCwUwmF0xa LsTnLRDfMgu2LrRjDtE024VXwaKBjp0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688851129; a=rsa-sha256; cv=none; b=M5mZhEUrHvQmQXxMMT/Vk80N67ifCdiZTaYW7cmfXd9coztDBzZLyf9fDkQuOJKNJJ5nSv O9qxiKuGzCaSbLaTYs+kon+ALJiFc1mmaQYBrQoAZMgPiqj8fWNeR6t68ZukYxVDUdtekY 1J+lf4A7VDxj4AKuUwEdLNVhWhVM7oY= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=YAZ3dlkC; spf=pass (imf19.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.172 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none Received: by mail-lj1-f172.google.com with SMTP id 38308e7fff4ca-2b6f97c7115so46954001fa.2 for ; Sat, 08 Jul 2023 14:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1688851127; x=1691443127; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NYkpMcCqLkVQ1Acc1vLb6z5Gk8ZLjHpR5RYSSOrvZGs=; b=YAZ3dlkCU3GzUmIGGNKk2biNpVrzxYfNhEwwjE+bOmS1sd5gMPaIuug3Ccj+d4mvYr xT04g5kyiIOLFqSn36I6zopXsEEUftopeaNUq/db2wt8dizzZU8ZY7298CiL80rtqBde +616QoPEosxnj0DGBJdrYAbfafgyzgP9XfXl8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688851127; x=1691443127; h=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=NYkpMcCqLkVQ1Acc1vLb6z5Gk8ZLjHpR5RYSSOrvZGs=; b=fGZQWIAc496D4RpIHBf4lUnvevlpCi5i5kwIvqJhRX+0FQky+a9h5DPHCmM56FXL7K EDB5YxOdpDXlNix+MkFi1mznwLH991PXVI+xMduhlFKZf04B51pGrn3R05ItIoWFzYUv JSeUw+vyGZCa4vGlAVveBpHD+C0U1twjL1TogH35ipIjoesSF/j/zMUhu2GyENBH/qC5 p1POnMICfE10gViojIkxUkCsc44/L2zT/Y62AOQMV+j1IlYU7iAAIzYuC1IsV6B489CW c66tVUWw2PW7ZxVOC9GjBPK9LyTabIe53UZD2OD1FplZtKkfV9UzKPjEVEXZRBFpjmL3 59eg== X-Gm-Message-State: ABy/qLZSc753X9mvL7k0dUQia0Eoe3l3eVQMFN/ODoSbeQlDNQSKXCvK YSsgEOSUf3y6/6FgClJdr6jHTJPaq5kHyEvZFhmR1B/L X-Google-Smtp-Source: APBJJlGysNusHpdadEEf7TWr+omVt42XCaRFucqktcFFh70dTryiiPqnIeABvQhyklikuEIIYQb1Mw== X-Received: by 2002:a2e:9104:0:b0:2b6:cdfb:d06a with SMTP id m4-20020a2e9104000000b002b6cdfbd06amr6535025ljg.22.1688851126935; Sat, 08 Jul 2023 14:18:46 -0700 (PDT) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com. [209.85.167.42]) by smtp.gmail.com with ESMTPSA id y20-20020a05651c021400b002b6dba16f28sm1324807ljn.127.2023.07.08.14.18.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 08 Jul 2023 14:18:46 -0700 (PDT) Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-4fb73ba3b5dso5026263e87.1 for ; Sat, 08 Jul 2023 14:18:46 -0700 (PDT) X-Received: by 2002:a19:670b:0:b0:4f8:742f:3bed with SMTP id b11-20020a19670b000000b004f8742f3bedmr6097080lfc.37.1688851126226; Sat, 08 Jul 2023 14:18:46 -0700 (PDT) MIME-Version: 1.0 References: <20230708191212.4147700-1-surenb@google.com> <20230708191212.4147700-3-surenb@google.com> In-Reply-To: <20230708191212.4147700-3-surenb@google.com> From: Linus Torvalds Date: Sat, 8 Jul 2023 14:18:29 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 3/3] fork: lock VMAs of the parent process when forking To: Suren Baghdasaryan 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" X-Stat-Signature: 5an6tyq567eqmigj8nmu1q9mpdt1utox X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: E1F361A0006 X-Rspam-User: X-HE-Tag: 1688851128-215369 X-HE-Meta: U2FsdGVkX18lbmnGWDFTLUtlACvTwJKg4zEal73upHLmVt8P4F/MM6+L67O0/rqSFUpIW53YlStE79KwcZgah/Nz91fqAFV45Om56bXErYcWb0LCDzeW161rQf5q+iykk/foK6l8155YSkIGtglOiu4SvOBODDmAZQhpqvRSnQdXzDmayTyGw+nn+JZ5INKz/b264+xBgvvJpGNVcYBXV+ZnKSZy0WnjZcbdGZhY9eW1MAAD4sfDrLybraLnK+KyZHJrtFWWLZqqu6UPmEdsb2Dr4EqwCl9Nn1f4oAgGFWAiKKsXVqodFb50DLXHYFfan5c2WYt0jXlwbma2qqmMHjC7WHTsifyclTk+tYZfDFBdsERyHE1PuqtjySMfMWs2VKJzNd7DmDLiZLXYE1uPSrliEOH1nX990tydb1ISr7Of9Q4v5SE42JXcj1kJvj0oqBi2ALIIM19J6aTpeFDIG3B48JLAZcMei5HQip7CIJStpKI5TaYyhvLdEb4MDZp+JYGA7w7RKBZjvHUDprdbQPiBnyNsIFlPCUH7iGa6S4+3M7s7TYG9Ce9YEuKc7kzNqFDz/zAeT6nTGzapdQ7MgnC8VsSzxZb3UbPga93/RpLJJoz6P3KMZ3vw/70G/FXoxur7q6yxRFKIAe2LcKZr4sKAujRsg0r/LdfU7a3RKoIbi5pV1icM/aBbcMJkJijsEbzJcYUFo5xZJWOoVG29Ybyh4SQ0P9dUhseVnFxr8/tMjfm9pg+rLmLEGh5S+6i8f/bWM+G/sLlqgaxqpEf2BMBXFRZb7cbni8V0zHqJrWc4OMkZE1dtabUnRNseGiNp5cT8ZmvquKykhiTEjLySgGAl9iQplHIiGVkOeJ7n1U53BKBPwopHLcqPhQj2QCgn+qG/qxMXGI3LscWaUtoLfJT5r5wyc/VLyRneYAteNm1wh5D+v7z4hKIWqehiv6XeUG4sBPm1xnRZl6uRodC JJx2nXKf 8i1o7p2HLdSK3rfmi8D2CZzZBf+sVXzmYEOCTIPaMfkKl8Z6RpRtoYH80/2qkOvP8z5osMQfzLLQooZcQFl38FQAPhpUqKOGnj/4W40gWQYlPH/1rluebb3kAjQ2uMU0kWonzgeuOe4z7JKZLVFdayHY+FeRvaXhVlvraLf9KU/ObnQaqwVHA3aTngrT8gcYH/i8lGu5bOkMFntTZn0VY5TwoJ8fE+FKj8Nsm5nePuRb+d4jhNOA85mMS0OWVD+NCylD0KVhKpRPNfuJ8ZVrbzcR1MnnnH2gwz9KK55cxrPV+XvQBv9v16Kix6rFJ1Z5b4Ja3muSqQDRFMjuZoPb134Os4tl8R6jhWbHTpv0qjPsZWK4h52RfqVmpWcepy+BRKHYiMKxAIDcEc99038KSkbzHj+Ymxaq7y9IaM6/rGfLY/FtE6ePx0RLT8ySR2db89Ud+2szMKTyKwRQ2XLsfLmRjar2KrJ4jDO+YkRtBh6+8XjKQFb9Z1vPvA1CowPQ9EKOhYr1KLS8S/vgVGbeszJJecqb8Lu+flFpGKFTV/Ex6uNfuCNOp0tHMamDl4YhJVN+qeGTgW+YJpFpYNczXh4V/pg== 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 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 flushing. 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. Linus