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 EDA90C001DB for ; Sat, 5 Aug 2023 01:42:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 62C4C8D0002; Fri, 4 Aug 2023 21:42:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5DB7B8D0001; Fri, 4 Aug 2023 21:42:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 47CFA8D0002; Fri, 4 Aug 2023 21:42:39 -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 348598D0001 for ; Fri, 4 Aug 2023 21:42:39 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 00D46A0212 for ; Sat, 5 Aug 2023 01:42:38 +0000 (UTC) X-FDA: 81088351638.12.1DFF0EB Received: from mail-yw1-f175.google.com (mail-yw1-f175.google.com [209.85.128.175]) by imf01.hostedemail.com (Postfix) with ESMTP id 26A914000D for ; Sat, 5 Aug 2023 01:42:36 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=plN7Lmsf; spf=pass (imf01.hostedemail.com: domain of surenb@google.com designates 209.85.128.175 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=1691199757; 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=+rSm29+3cw5ZqZkXj3qFSUuwbm7CIlxZaN5vcndHFEY=; b=jenUd6Pjz74AD+oNU6tLZeGPvs6j6RfUVrSYQoWFPa9M8x7laN4vAxa/9HEjiKCOs4DxYA AFQvMHTVZSANMVYsgB3wNAaSMVljHw+eEBxFlLaIE6sDoi7yiaJvVxQC3PXb/3vVcbUPQE OVC/RPNNPSmwOuTGMtKOZ/ZZSrXoyLk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691199757; a=rsa-sha256; cv=none; b=1dh0Q2upn16vH+X3LDZh+Bpe2AKQ+qyWLYYh83AvNOMSYN9giMZOaNLkOiEvXmtuUDwvcR cTHSNBi6v5CbhmkmDBP05kQwDk7sHKIac+1Iz3OD/lPARiBLl0TIcxKM04S5wPG9hsUyOB bTnU1vW7V7bK6G+hY+VGg2ozNVzYPL4= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=plN7Lmsf; spf=pass (imf01.hostedemail.com: domain of surenb@google.com designates 209.85.128.175 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-5862a6ae535so30781117b3.0 for ; Fri, 04 Aug 2023 18:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1691199756; x=1691804556; 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=+rSm29+3cw5ZqZkXj3qFSUuwbm7CIlxZaN5vcndHFEY=; b=plN7LmsfHyvXpPp/HAgS7nXgIXteE8264IDa/o2tjDOX8unsmYk7EojQmTU5cUe+jV cjliykudifFvc7dLk6/DwgOH7+9X4MDhzMIsMQm/onYSQqKdwNZX8UqVTYKuJYl6Ha+O 9WZhXR18J7XAaXbGAAwEXZ6ix0+UBKlzsTvo5jb05KSoRLL7qXvNBl5pNC1d6tXmVHMW SXIZLO8BP/DYmu5uEYaOUv39DLoLQlpwPV7BHp0dSXWIa4usOAk1N8w9mKX5V2IkcGwp 8LnltCq2ELwZcpwu4a4wWAkmF+JXVmG8o9gLjlgrYUu/NaekCF94WvOvLo4XO9zaSpD4 kw3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691199756; x=1691804556; 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=+rSm29+3cw5ZqZkXj3qFSUuwbm7CIlxZaN5vcndHFEY=; b=lNJBOqBDE1FQ7w9U3+EReIbxz7x7oPNC8k1HetRJQEL76PxtxuCN8pVzE/F3uo+Td5 2c6gqUbWdL5rgwKyvsqsmLzswItfXc/SAAy9gtx9MPB5hCFF9HeQ0T/mPq+HPNTOgIdh 2rP9LdVtvBblZxPXnDeaswByiJ5LHUxLUTEg0DAZNLuJLBiB/B22xnKLgFMx+38nJOiW 61BobXSCP50Fqxj4sdqhyah/O7b3/La/zDYm9hwkLmWunGnPbnAL2p74fgjrHD6ii6cO 6DaUqL8cRf+nOGd8M+yARAh26uLS1/Q9U+GT8oUk+1VNfDlaATBCaKCra1mK82FazO3f peAA== X-Gm-Message-State: AOJu0YzoAc/lfZ//BIE2jAe145cKrfyOLEkppvx9LdiJ3ob0PlHKTgBz eyRNYYhAK750851f0ANEtVb4lxwkJfkIepTBCIBYbg== X-Google-Smtp-Source: AGHT+IG/HG+1FkEX7JGdDxDWOldixEM0zkMBonCbqf9PfeycEQrUJ/6TiOpqPkR0mOG06UahG1Vw84tdIhU/dMHaqDg= X-Received: by 2002:a0d:db41:0:b0:570:2568:15e with SMTP id d62-20020a0ddb41000000b005702568015emr3945027ywe.43.1691199756040; Fri, 04 Aug 2023 18:42:36 -0700 (PDT) MIME-Version: 1.0 References: <20230708191212.4147700-1-surenb@google.com> <20230708191212.4147700-3-surenb@google.com> <20230804214620.btgwhsszsd7rh6nf@f> In-Reply-To: From: Suren Baghdasaryan Date: Fri, 4 Aug 2023 18:42:23 -0700 Message-ID: Subject: Re: [PATCH v2 3/3] fork: lock VMAs of the parent process when forking To: Mateusz Guzik Cc: Linus Torvalds , 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-Stat-Signature: ipe3ib7bwicimgo8x34xz89117kxygc6 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 26A914000D X-Rspam-User: X-HE-Tag: 1691199756-69369 X-HE-Meta: U2FsdGVkX1/4eyC2Luub6pE9wZabxvyg3bXq2NSHaf/++HBzrCzYK5s5ly26/55w2ZPoOhJfK89T54lJY/RnyOvAmfnkaYCm8QSBc+MExnsk/6V1YIL3EhmFDs1CNJRL3SgQHEjLBZZ5qEK8hbllZw44Grmd87qRd5fQNQSSJoZet085kJNUo59c/DfafLfYNPLIVsjeLYCbicLPTOLGPN23MJcJNTm6M6IDTeOWdyhmqTp1OL63PF9Zh22ZPHzC/apiH0SZ7iKhRYaVwpOL6dbCIIPa4oo84GRN3pNFpbU4IK9eOve7R186fUQSsn3zpbLFiJ67sBiNfyDtJVUQ8TjpYMCEKWoOZ98teqHET2Pe4KAug16wJwc78XOjhV5QCgn3f3ZzAVeOhW3kunmXjJbvDuxZfK9Zb6quyBBftFNllrbYiSXwmhU9jZwDfHOfDagc2kV2pIsXfY08OfXUGrPRe6ICoO8GDG8wVED4HzvHE5g+QfbvmM8sdgLfiFwD8Iz8jcS9xZBPxE3kLV42wOpRYZ37WDPJbKiD9KuE71O4rdb4tWQbBoip+vwdzW324Y3iTMD0YLwHRGt76InrDMpbuuanLuWeaVI8fgISuiEUSGv5/Xm0PDkY0MPXQrAFsORGF8h6yO3F0FNRr3Hh7CpAQFDMObmdW9hb4FGUoNfBm5WZgZll1z5EoLfg5yFqs1rwzLLTqVGUKI78PTzNQQtJ4yhwGHzLheK/l8kD+1sDqclz0aUDoDoKSfO6rWWuDe+0gKiRC9FytAbirDr+J0UC/t1fKx0Adq1Bh92RMvSvkKcZCd+2KHtLcXHNRmI3+5A4vK5xKisOSsd3oeP+vCTuu8IisaajeqEPjDoIynAoHeiqsnzcIOPvNLfi77KuPSz6bs37KAgB8rcMH0AHX7d9hvWJj3SV7ugpytUJgHINlM3tj0hr9AX+rNPZwVaGfFmsTPCofuCgarA7cd8 XCrCaAjo YsGkPj+Ji2kjdpNFc2Iv37glywBgri/5clCVXxCYG9VPMYSTIqUcSxISIjKvP01teHeRdw9A7OKff+o9xaNU9br/CaxbAWBlZBUbe8IApB0/zhekRoRq9TpvxjTaWDF+pCPWofOf/Waem+i42o2E592Wjk1YpSSFZVnEE4BDA+MoJ54HQfGmLxPVbSjzq5CcbdkCFut7U1KitHlSgV29nn4bY3WOqOA2ntI+YpchRu+8C+kEtnlAzVV7bTmiJ3BZGE11q9tgSCBsnO0Fp5hLTNCqE2KAVmWyjOAqYjDhK2GLquz+OvsEgtOJtHRukF2N8zoBy62qlXYwzMs1ujkYlTD1ooI0Yeirp199rzUJBer9QusJdzxnwrjj9ndiS7zsUNw6Nu7DT9l8imEIZwNFGWIstz5p7c/oYfsy3jgNOXJJ8/I+VCRvBhIdONg== 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 Fri, Aug 4, 2023 at 6:06=E2=80=AFPM Mateusz Guzik wr= ote: > > On 8/5/23, Linus Torvalds wrote: > > On Fri, 4 Aug 2023 at 16:25, Mateusz Guzik wrote: > >> > >> I know of these guys, I think they are excluded as is -- they go > >> through access_remote_vm, starting with: > >> if (mmap_read_lock_killable(mm)) > >> return 0; > >> > >> while dup_mmap already write locks the parent's mm. > > > > Oh, you're only worried about vma_start_write()? > > > > That's a non-issue. It doesn't take the lock normally, since it starts = off > > with > > > > if (__is_vma_write_locked(vma, &mm_lock_seq)) > > return; > > > > which catches on the lock sequence number already being set. > > > > So no extra locking there. > > > > Well, technically there's extra locking because the code stupidly > > doesn't initialize new vma allocations to the right sequence number, > > but that was talked about here: > > > > > > https://lore.kernel.org/all/CAHk-=3DwiCrWAoEesBuoGoqqufvesicbGp3cX0LyKg= EvsFaZNpDA@mail.gmail.com/ > > > > and it's a separate issue. > > > > I'm going to bet one beer this is the issue. > > The patch I'm responding to only consists of adding the call to > vma_start_write and claims the 5% slowdown from it, while fixing > crashes if the forking process is multithreaded. > > For the fix to work it has to lock something against the parent. > > VMA_ITERATOR(old_vmi, oldmm, 0); > [..] > for_each_vma(old_vmi, mpnt) { > [..] > vma_start_write(mpnt); > > the added line locks an obj in the parent's vm space. > > The problem you linked looks like pessimization for freshly allocated > vmas, but that's what is being operated on here. Sorry, now I'm having trouble understanding the problem you are describing. We are locking the parent's vma before copying it and the newly created vma is locked before it's added into the vma tree. What is the problem then? > > -- > Mateusz Guzik