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 E6B55C001DB for ; Sat, 5 Aug 2023 00:49:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 45BBE8D0002; Fri, 4 Aug 2023 20:49:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 40CB48D0001; Fri, 4 Aug 2023 20:49:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2AC378D0002; Fri, 4 Aug 2023 20:49:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 19C9B8D0001 for ; Fri, 4 Aug 2023 20:49:25 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D94EE1607F9 for ; Sat, 5 Aug 2023 00:49:24 +0000 (UTC) X-FDA: 81088217448.16.4505433 Received: from mail-oo1-f54.google.com (mail-oo1-f54.google.com [209.85.161.54]) by imf19.hostedemail.com (Postfix) with ESMTP id 183781A0003 for ; Sat, 5 Aug 2023 00:49:22 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=XmzIcXyh; spf=pass (imf19.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.161.54 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691196563; 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=nC9Fhp6TCZrfcsmijl3oHForktkxpl5KZQtthV/moAA=; b=seOWjAB/uQBFQqkflmIyl0AoAQS8At1+q9NvqCCt2+5DuS3srUiMbqWrQUb398exwPE43F ZGXsELTjdaU7U84Cp6zwjXeWgurhnHkeKN5/iIEXG82TXpeL4Dnx1dAy/D8bmQ77fVLPx2 oVsD2c4tgaQataeu4bCJDOfsv36pmDo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691196563; a=rsa-sha256; cv=none; b=0i5dI73WNWk7xVD4ig1qi/g2Kx46BpZEdka2VaAZ/E/0e1ofyFvVyOulac12fj1uCz62oM HKY7B0DmWpgStTrM1wzqabk3vw37zkwsF3SrgI446Q/KoSI6n3PSZBUlx1heItqJ0jCJmT Gb7GLpzPhZmNC37ukHDgWr0mHGZ3xd4= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=XmzIcXyh; spf=pass (imf19.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.161.54 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-oo1-f54.google.com with SMTP id 006d021491bc7-56c711a88e8so1817064eaf.2 for ; Fri, 04 Aug 2023 17:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691196562; x=1691801362; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=nC9Fhp6TCZrfcsmijl3oHForktkxpl5KZQtthV/moAA=; b=XmzIcXyhQzhX0FXd8abVbQ5vr4GQvF4B/upe2YhV2MbIpYJSp3DkmZkY8TECMAlUIO WTCgMfn4Q+QmGNgw5cF3/z4UPZZCrjcK06FTQK6nFocskU3E2ESjAZQKAMF8AGg+DMz5 MO/+48/nM4TtIms6jxkF/nU69cRPi7qCbe3ga4fesKfond5NR6g8vqfG+kg5tKPtkG4B scnFviFayDlXJfvqxb8d0Hr78wsFREepRUuFuH3JDcVrM0MMfBKqUb3Wk8RGV6MN/uFC SkgBj0Y3rmrQFm+1ZDAKmujRBFq1sNfUlOtaEpuGina78P8a+RZNBnHiTZNuYJF/qawW XPBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691196562; x=1691801362; h=content-transfer-encoding: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=nC9Fhp6TCZrfcsmijl3oHForktkxpl5KZQtthV/moAA=; b=WhM8+YChmNV7wXX/TQZA8zGojh3Tbx7IMinCf1pl9VzWyFsZlikHM/vl29zSjnzPca wqGrFeWBhWprLXeq0NQKi2ETmEDPiczXn8SyPZ0MdyEhyE6MERH6mwWBbMdqpEyqKnJY QyPs/pLIUrc1Hszsi2ftKC3ZkRBSKOaQP1qTnsIwWIqZMJx8ikqjM5DAB2VyzHbrtg2Y pnh+/WhCs3y5jXEtIDXnUdE3DSvVxIDnDTWWt/73v6vVq0PolUaviPcb8h6BEfMOL8St uQ7RucLrrftYQzDhJ++UyBUM9I0BsCx8BuZHira3wZ2hKVDR88lSYw6cLemFJLETcnqw Q5+w== X-Gm-Message-State: AOJu0YzGRnTSEpAhl36QSY+34S0pteLdZTnTWyM2SnFfn9o0u3IttS0L 8N2hfSeRa9bzDWis1RAw+xbYyYuenrIenaT9lMw= X-Google-Smtp-Source: AGHT+IFJ+zkF1c25z6S1/ksUOcukPgYD1oIxbWZwbBc/q6VFA3C2X7rYVDo6kvHYGGGXWhwRyRW6wkXCag6tb5+ZQqw= X-Received: by 2002:a4a:7651:0:b0:566:ed69:422d with SMTP id w17-20020a4a7651000000b00566ed69422dmr3497184ooe.7.1691196562165; Fri, 04 Aug 2023 17:49:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:7b87:0:b0:4f0:1250:dd51 with HTTP; Fri, 4 Aug 2023 17:49:21 -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 02:49:21 +0200 Message-ID: Subject: Re: [PATCH v2 3/3] fork: lock VMAs of the parent process when forking To: Suren Baghdasaryan 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: z3cgx9pa89oqe1ioysbpg14mtjdd4e4t X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 183781A0003 X-Rspam-User: X-HE-Tag: 1691196562-405994 X-HE-Meta: U2FsdGVkX1+tYpVNMwkOi4Zx9Ipv+nfSufnEPv8S5GzB4RqAY4wvkxFZukUjt/7D+UNJPSEMl0Rt6MAZzpcKz8CyL5z20WzSxJ7l5IfenjnTB1B603d1WbiTrChz4Iyf+DTQYC4HupYT8HS05IvXjP51efudduJIlDm/6KWKB95twCvsdAFnkgm37zA601Uym/8yA6kYzjZ4n2I0umZcXffpfm4y/uQNMkmu/x6YJ/E/XrFdmF+Qc5umhC4I/Gkb3QRqFDQkBpkc+QN7+VRwBH2wNWAZLcNGf2z7Hju2BMVnrrLfawkNH343tN9NKxl7KlrqITrbX4mXMO5SjfHAysH8TFDuiALtTLlezjjSfnCJkMS8VZxExkAjHXIwdnkwHOhrNydjgot3dZDamn81ccvCBsRML86lLFSMeBPQdSiEJZqvWPq17xhPYQN0J14EPmhp9yjLGvyXLyPL+KMTwKNmHQV6OW4DVTz+R2x/YJsJsKFXEyWrDEJwOpASuPa2cuWBx55h1JvgmGsH9rSAs6HxIHYokyf+MfQBBWH1RDIrOKd/IW4DjyosCc31Xo1egx8HaAtULeWbcoWXCiLplK0CMQif7NI1Qt019xq6b6R4dBBEfzUG5C0eaKSEZ4uAcRN/scDfC1Q5yAWR5GY/Qln1TsPuhW+8BXyGMKxWvQpqL8oAZUotii50W07FyMtEPeBia5e1/yNHEJMsGuU0vNCtBLWWcEsTkX1r448xb60erzWrEGj7Xg3fr/bA7xT1iyqHMBWXQinNwNacuVhbEw0KvSgQPfKUXg16k11mmIfHwB4S0KFi0AoNJJa0xL3X4/8EGtFg6BW52ntXvay35Cr1clErEpTpqs9B03XKYaBkOf+FfsALlyyNTD9aC4aDH8lC9pex0vi+0O39ENFV7hlLcFjkmeVrQNY4xxr38cNI82xyqt6qqu3kx+2ET+jFUW4zBk+QUcvIgMirGHB qI5U8WWG 5XdvQqO4wxAxKBp3sM9/jpfV03WCOkAqKoIjRgqf6optfftZArTeqpDpGrOXVYoFcEOnQrpSqYCd7/O00HclWR05WVTfv3vtHxcoCJPtI7z5gJiKbg7NThgrB34BsUIr28xnAO7mrWbDs26Q+xtbtCmbH8f/VQ6qDMlA5bUqV6ahA481qVe2ICDNkp99o1VM/6OxQk/qSVmotIcstAcrGQQnIooqMP6DQDSO+B8ZWM0OJpDTGZpOlopVgqLP/XO0uNS5MJHsu2RQxJqBeIKalgtt3afOoZ/+f2dwSK1WEmHoMeOrKMaxUxEOPlLSWoR1aZJPP3yODLPVRYn5FnFr3XLf/obC3o1dLbspT1Pv7VD/F4/WUHN8sHPCl/fxnPe5qxIgkDLUSnkMBI/HpTQZGLV3FzQpQeYA4mgi4A7aGVbLdvdWokmYlPranZMUcMdrx/75oRvhyKEM/yX5o6tqpJBt3Sm5emdk11NLD83r0HjKQC2FO3vjtLb/dghYpTzIsjpvbNdbmSpKhaezY/BNfavtwJNA8cVwm3duRJ3tgbiswvzEK0LkMu2XV+Oyfax+XbQcRDzV2X3I8NXIBD+9PHedUJw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000017, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 8/5/23, Suren Baghdasaryan wrote: > On Fri, Aug 4, 2023 at 5:26=E2=80=AFPM Suren Baghdasaryan > wrote: >> >> On Fri, Aug 4, 2023 at 5:15=E2=80=AFPM 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. >> >> That check will prevent re-locking but if vma is not already locked >> then the call will proceed with obtaining the lock and setting >> vma->vm_lock_seq to mm->mm_lock_seq. > > The optimization Mateusz describes looks valid to me. If there is > nobody else to fault a page and mm_users is stable (which I think it > is because we are holding mmap_lock for write) then we can skip vma > locking, I think. > mm_users is definitely *not* stable -- it can be bumped by get_task_mm, which is only synchronized with task lock. However, the other users (that I know of ) go through the mmap semaphore to mess with anything which means they will wait for dup_mmap to finish (or do their work first). I would be surprised if there were any cases which don't take the semaphore, given that it was a requirement prior to the vma patchset (unless you patched some to no longer need it?). I would guess worst case the semaphore can be added if missing. What is guaranteed is that if the forking process is single-threaded, there will be no threads added out of nowhere -- the only thread which could do it is busy creating one in dup_mmap. If multithreaded operation of the forking process was the only problem, that's it. >> >> > >> > 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-=3DwiCrWAoEesBuoGoqqufvesicbGp3cX0LyK= gEvsFaZNpDA@mail.gmail.com/ >> > >> > and it's a separate issue. >> > >> > Linus > --=20 Mateusz Guzik