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 6A016C04A94 for ; Sat, 5 Aug 2023 01:06:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B1FBB8D0002; Fri, 4 Aug 2023 21:06:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ADA468D0001; Fri, 4 Aug 2023 21:06:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 997A38D0002; Fri, 4 Aug 2023 21:06:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8AF648D0001 for ; Fri, 4 Aug 2023 21:06:17 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 3AF6A160A33 for ; Sat, 5 Aug 2023 01:06:17 +0000 (UTC) X-FDA: 81088259994.14.5E93E13 Received: from mail-oa1-f51.google.com (mail-oa1-f51.google.com [209.85.160.51]) by imf06.hostedemail.com (Postfix) with ESMTP id A6F9818000D for ; Sat, 5 Aug 2023 01:06:14 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=JWEJoBXO; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf06.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.160.51 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691197574; 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=5wLxtngQDf95laPzAr998ewYrpc6/LmQcNIxOteIueI=; b=VOkWRNjcjSnI0+ty4kp8schdr5rGYBKzBgq2dvZEpPJe6vSkDO+jj7uQxEILbyV+hTnKyI 3AYOCG/1f02LAKvbBEolIXI0vDUWhW3Okv3bIG59XO60GuTFlid7VS/zuKSwvYWEbzYS/R oF2JYG3rpFwW0MMfKHeu9K0TUw+1Tjo= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=JWEJoBXO; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf06.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.160.51 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691197574; a=rsa-sha256; cv=none; b=nF1+20xxeHkMny2IYMq02snnkXdO+bLLE8Gbb0rzD6ISxc3Bk8hpBPjXR+3HQjsAm5yZeO 8shX6443wQN4JDT0FOgWUFeTD2SNY3VQBMD/Ey6b0ZE0zSF5LegCdPz9GvwEoJgsaTb0Dl 7kfDZ7q+gSV8r+MRiFhbve01P8bVBDo= Received: by mail-oa1-f51.google.com with SMTP id 586e51a60fabf-1bb89ac2013so1873786fac.1 for ; Fri, 04 Aug 2023 18:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691197574; x=1691802374; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5wLxtngQDf95laPzAr998ewYrpc6/LmQcNIxOteIueI=; b=JWEJoBXO0UGnBg4xLdw9KEUhTH4lf77t4U6moAOmDX1C3WqbrVn5+P7FXQ8ajzo70m 3e/bt6Yn9H5A6cs+o19Z4C1zxcT4Et4m5abUWYZInQ1vxhkrUERvFXsImX2e/W3YpV0y MJDLZNtb6Mz6g1WmggiYRNxAYKbjQPfE9Hl/4M9hLwFDdXJi166vWIcQYeRTPnhJJYOa ijF8FYpFkp7oqHhWSIXvlxrG+UOuYO3wy+mJ2meE07tjEMkje7c42ME9yAweWkUXz+33 4uV3V8Ld4pJPhV1V1BINXfsLX3bscp/Uu7w4V/Rj3IlZV3giEvAfAcTDasK9x9+ZBd7c HYhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691197574; x=1691802374; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5wLxtngQDf95laPzAr998ewYrpc6/LmQcNIxOteIueI=; b=jHUFyZCAzXHG47S54gjYS7j8FD74VZfq24S6ph3/eGvee+KiLx4PY8FQeIQWzpnH+Z yMM9sl2wqICXhvVMKG0VT+TUMDD6HSiOQAnFPTmjCZ93KEV8WLZcVgKw5zsJGqBNOrYV SL8sbAN7OGlTzS1DlvO1H0unDl/TAEXwWtWWMSdSlYwE2ZUYWCF4vPjiXDn8aenIlsLp 7VaFLfV9HmSXXXRDx7RlAYMV4CXBylDyDoMyBHAu7ycyu49WjL04XpR9N3A55BBM/qQQ BFzdF6FozKaLhXGpPuvmvJ05tay6k45TyFngfOfMi+Fy36Mv2WBRoWmM06Daej6sGEGL fWog== X-Gm-Message-State: AOJu0YyHhH5lynOHsYV0kxLV49o2dTcrGdRiSbC1mGdV8QJd6lDi4/wb QXelhW2LxHmYGcDcF/rsJoeX3QmBCyLc5t0rhCw= X-Google-Smtp-Source: AGHT+IG8PbrHRgIVAkXmrYRri3sk0mgD3rxRszibk3mbzi2/k2uRhFt/+JykTBC0PKuE3GPwCgYcPa9/gb2M+tKCYKM= X-Received: by 2002:a05:6870:82a2:b0:1b0:449e:cff9 with SMTP id q34-20020a05687082a200b001b0449ecff9mr4064524oae.57.1691197573686; Fri, 04 Aug 2023 18:06:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:7b87:0:b0:4f0:1250:dd51 with HTTP; Fri, 4 Aug 2023 18:06:13 -0700 (PDT) In-Reply-To: References: <20230708191212.4147700-1-surenb@google.com> <20230708191212.4147700-3-surenb@google.com> <20230804214620.btgwhsszsd7rh6nf@f> From: Mateusz Guzik Date: Sat, 5 Aug 2023 03:06:13 +0200 Message-ID: Subject: Re: [PATCH v2 3/3] fork: lock VMAs of the parent process when forking To: Linus Torvalds Cc: Suren Baghdasaryan , 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-Rspamd-Queue-Id: A6F9818000D X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 5ask86u5k7wwg4jn1ucpi6taoxn3bshz X-HE-Tag: 1691197574-811776 X-HE-Meta: U2FsdGVkX18uzZbHkPr5S2AzsQG5sjjOXXlTY7LSGizOh3ExTiFDU2YMRsbiuGZWKs2BTFEZac3jEO3hSqdnDL4iQ5iwf0vYOFFTbjX1gJ+qt+aKS1j1Zung/UggQP7b0hdCc+rPIpTkrUucekZw6rGrnLGOOgmY+gW2wlKDWzbvkQzWzSW10MF4XcEn2owlVl+Z+r6q9JraR+20PF4uobvavT8oCFuaBSzp12PLRqFR2Gj4ofzhkWiYp/t86Pnf+1YJ2B8tWWcuVuMgLghYUoztPpcS14A7tcVcnd/IMQN5jGbgr2J4mJlqHptv/K3jYNZrZHqt3c+HBofGlTTTWXTLuhMo3YXDzoJ3FMkaAo1b4M/tBe7OofYbNKn6GgFQjkm3R6/IpEBdPj6dkG0aUXCnC0p2VWnUCnIMXq+yLnei4oTcfGuiRpbSmTAu1Kw5yEQ2lPqlwEgMhLvm7i/9a4zzJh/K55Ed+M521Fsg0oPbxj3JDpA+gHkCiL0MA5+Cgegw10h6/4baNfMcX51fFUYxMWBl0pIncG8eY+C9+zbKLoxAkaqK6xrUuggZkkdfHmZyJpyUAQPLUF+LrRhIeEs4SNvCJbQ5YrLZ7y7cJVMq/tzfGns29aWEcbARIAJfPLrLFTSkLh1viVe235CqbYuq2vwZ/AHKkXsIVLaR6DGZgoYRd4VsZ706+y6TfW8P17f7UOPwdRfSQ4UaXNL5ymwWgMXi1zZwwk+eCgRT6OuznTlFTmRn3ypowa/dqTHKQ7Xq3PB0DkgzmuiIkrAS0+T8HYrYDBZXa2qs9BYQBHf5UFVOyqZiPuw2U4SfNi1uK6tsTfvyMbxf0nLrhH0VgzYnzK7HfkA4iJ4z+4Vx42Fss873FA1S1qqmY1ROnuz0dT2KT9imcoNuv+uP3IW6Md8vn2z4TnVqgpuc/TagN1gDhSbHa6c3G/LTIP0vd4CKNNpzsdOwrbu6j5CdZQv QgbBLWeB Xl//hcG69rIqRPpqZVlyo9pdVBYLuzYfkrPpDXz2cfnezwMvTyk92kzns62W0q5GFIIV0luqPd4i4ZxfyakFYGc26mDccudT017E3u45g4Ugti4+GEkRCsS/AkCm+RvsKjm/0xApSZoeQSZEW4B0cSEfTyku4Rdv2NBVwEUNiYGb8oXVFyN6z5FvXkHkF+99r8hZtqzSAmDnzdYJZFYU0XYon3U6qWIztN/eC8fqKfFVYSt6ppkSU0Gsy0EfAelvwJUeRxCgF4qLow8++AuqpPYyTMZ1CLuXr/Zv7iaTHU5QtxJfaO6bNnhgV+ltnlfvshzewez37zwKWHJNCmHs/fKPA2KMiKc/LxiwauBUofYzB1r06mqqTXP2mycGxRwLNa2So4/f1ueNcmK71zDAmXgXwJ+qOw/4IHLcQupkMrc/6C0LEMEwh1Eywa3+6gql0fVqhx5mM1EvleY7K8lWapAijV45GPSPdp0w7b8h3KqioU6yh2OGPCr9sCF4AY/UwzHCSbrnecjlYAkevJ0cpT5Qb+s2zFt+8oCLUjSkzHkbtvpWCR2qWwOeQV+ZSMFaTmPxP 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 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-=wiCrWAoEesBuoGoqqufvesicbGp3cX0LyKgEvsFaZNpDA@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. -- Mateusz Guzik