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 D3230C00528 for ; Sat, 5 Aug 2023 01:06:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 52D238D0003; Fri, 4 Aug 2023 21:06:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 48EBB8D0001; Fri, 4 Aug 2023 21:06:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 32FAF8D0003; Fri, 4 Aug 2023 21:06:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 1D2488D0001 for ; Fri, 4 Aug 2023 21:06:36 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id EAF4B160CD4 for ; Sat, 5 Aug 2023 01:06:35 +0000 (UTC) X-FDA: 81088260750.25.EBD8410 Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) by imf29.hostedemail.com (Postfix) with ESMTP id 3849C12000C for ; Sat, 5 Aug 2023 01:06:34 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=aUwo21ad; spf=pass (imf29.hostedemail.com: domain of surenb@google.com designates 209.85.222.180 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=1691197594; 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=P9nXyLSKlKDuUv7VJNfF6qvF+1BUCc5KK6MJ3lKMdxY=; b=GkaudgHS8XjyqYtM2bL/0mFYf5a+e1rSLxuSj6n0LmqcM0oYJxdbEGfsJUEFoEzLCQfSMT aBxZPwki8ASIQ3vu+2UwsMiAmwIIiiJbgBcYJ1QGYVBV7UMZANBYtzZR7/29sIxCNkYUJc rFMlRNngmHxu3tNFFqc4zHbUPHD2dEs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691197594; a=rsa-sha256; cv=none; b=dGzoVD4Lp8h7sK6THk1LgkiD7bu8SsK6sGklHLn+LUIs9ccG/7CgL+BRGO1NNt7Wz0HQGI VQjyxNteruTUVE/eWUkMJykEhbYb4Lxfh2MJnT5NaKWp1Pl21tUsTYQBX4yxDKK8FZyadj MC0Z383xUbS5U+W84WzLMSFGKdHCIxk= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=aUwo21ad; spf=pass (imf29.hostedemail.com: domain of surenb@google.com designates 209.85.222.180 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qk1-f180.google.com with SMTP id af79cd13be357-765a7768f1dso223342785a.0 for ; Fri, 04 Aug 2023 18:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1691197593; x=1691802393; 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=P9nXyLSKlKDuUv7VJNfF6qvF+1BUCc5KK6MJ3lKMdxY=; b=aUwo21adxNhts1FI6P2qHSPV+p0bQFy+AVXKarONqtMm86XWxkCeXSeCRN5rVOkbuA U9xu3v9w8K8eVl+8jZUOqrqfCHUny7KfanQvYPi1lJj5UnIuPwU2bBaexSN4P/CiStKM Q04LTz5qK5imoj1roocTbgXo95ivHHkcbkfr4yII/5eubPfs8VLuc99/bOLp5VICKq+l kJ0hzHB1Moy0QCkOK7RoLAULbNhhHbdlMhXQ/JWxfdDf2RMT/G8sPy/SfAyX6ujpFsBs 63FGq+adFIALmXtAt9wp8tA4MpkrRo5mr6xvzVMi8NdUsh/Ti6Hx/XABGLcNKVhvW9IT o4bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691197593; x=1691802393; 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=P9nXyLSKlKDuUv7VJNfF6qvF+1BUCc5KK6MJ3lKMdxY=; b=iFqARSsslcqWkGAYIryWE5U0DEii6YnUjzvezwM5iSx54HlQCi33t+IrelK4ksw7+C sivR5lgiZ2KRUU2AQt90MzfNqNej5HU3azE/mn9w8YAIHZ7c3Iwde/Yz7eLo8bWhTFMq +tSC2NxGRpuY6RKyipMPMuDkYDY3u2iS+ugXbqud0RB2gKGyEh8GvYWSaW9bgxecod5Y wp6MoXD0vYU8mVkUjhv9u7kxKbO+W8P2QMV4Moj2UDbb8rqGZ+0rsX4PKR1oiLFzRVbr Mr7EQwHlpWKRnWbnTOV4Em90niEomJwo59t2xvJNi/z3k2u3lhDY665yhOWSCgCHI56u w1fA== X-Gm-Message-State: AOJu0YzxRFmM4MKpMzaJsNB9ouE3+vtRvSP/fHCfhxTIZGZMDtxgxpGp BeUqRVyxzLs2JRfAxA1p28p24EipYIhhK20STuHJAQ== X-Google-Smtp-Source: AGHT+IGeI3aXL1BSqCSVQSPUC8HxCVhgOILs3RxiXsM7zZQNEZNHfkFdUoN4/MsbrHKtqT5U8IWBJIqb2DgGz4WHyls= X-Received: by 2002:a05:620a:4628:b0:76c:9fdb:faed with SMTP id br40-20020a05620a462800b0076c9fdbfaedmr4192886qkb.35.1691197593186; Fri, 04 Aug 2023 18:06:33 -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:06:22 -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-Rspamd-Queue-Id: 3849C12000C X-Rspam-User: X-Stat-Signature: hdu76r6gbwj5m67htcudj4fbuyfqkjxf X-Rspamd-Server: rspam03 X-HE-Tag: 1691197594-798509 X-HE-Meta: U2FsdGVkX18jKUlMEIlMyHTM/KuTQsnjzDrk6ouQnt8GYGSUwwpq2h4zWZdBRW8tK7Zg234N87eiS4qeOsWm+LST3hHwGNr+6UEV+WuCjePjmuwOTgLFbQJh9jRrXuFqa8OWkj8EcQ2mVRY1pvOwRXbkzBQDg63Hdj07CN4ZutWMv1gIm8JJXS7767a34foLez1OY9fSqtvMAfTwVFTy7eaqewTiTNmwA0U59a5peyPoTYTF6PxTL8M9/nRVD9ZyNF0kLvSPc5tuGsE9mQUJf0crFylSzv/ds/0bb9bBbPSNVR5H+jl2jsNDfcdAEJWvjxkSJ+nNUpAUD2Y/WLOx3vI8UhhM5R+UZfaCFv0LMZKuaxP10JFl3CThMaOOm/5W0N1hxGGeXl2Iqg/M9umfpSCBS546kw9TMVeJo0YvtomwK5Ok0cEl3wSri7yUk94+KsUgrhIkv70AAUlPYuMhl6OSYge0bJyZexyyOTaHYKRyDaofvsglE5wXxJhCZZUVbtC/Dxb7Ay9W8MmjmicK251nFAviPszRPXhHAxoQHEZEZINXbYcWBWpdwtfMX1vFlB2RByIJr2dQBMOfw+fzFc4pfPMyLmQJocE57OWIaoTXUIMyuGc0LCzCtisTh/MCkhGsRc2OsYqYzkBnxj7Vpc/oU5N0kuG2gLW/pJGwPN5oC+Vv7EWuacHGyCHnpj6Yhg9pOzeMamPwJ2mgdPsqI8Wl3tdEhhKrhcyq0VzY8h/RT5DzhoXDQi8IlFIhZ/xSh63U1xmJ88CUhbdpGHdqxnI8VSzsXHOpCQdIy5Q2TbOxxjq73nqYIzQwofzHMJTBiy1N0N1h0rO3rjUaBfyU4WLH9c49YXbpemU4sNygAxaAILsPP/HP7gD82SN4JfC10MQ6xNJee/0nVUa0cT9zWxR6U10QBPXMqHPxylagP0nhgCJzH3OALdD/n/Ylr+aWHHEq1bconD3PK3aZcTJ TH+Xjd9I +NncgbHEdp0IINF8sOJNf1vJnC9A7GPAKihphLfJSx9A9txUoTS37JLE6UWMv6UwpqyreP+zk7Y12RuITb9Vh9ui/jO1VKvg033XMzvNsPi87LqW3+AT45lRxn0QIKO+CBOv5J6FpYeOTnWy+1/Q+eroz3xQI1ez3aiIw2UvNeu6C9omeY+l2yl+IRKVYJXDxySJeil508SPpspOWNN6ViFlO3xeAV0QxOUwCntwSB90mAUi6mIHUJpd0MYvenhxJYsGLejQ0LrtunZL9DvkO9cXJBESKAx4dXoyWo/IRUOTKnICqR0K3tj9rvCXdYn6HMMrxSglpbL86/VEoh07hIQ4J5ZZ5Vyf/qhZswH6mRRM3r3rXSQKyGrVH9UCxMjwtQyUtA6GbU6h2hXqaLqKv+8ayxprFLTjouNjugisaAyUBvoLNmpWuagIC+OX8iurQskB/lA7Eg8r0OYhXcOACbu6UDw== 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 5:49=E2=80=AFPM Mateusz Guzik wr= ote: > > 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 star= ts > >> > 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. Ugh, you are of course correct. Poor choice for saying no new users (threads) can appear from under us. > > 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. No, the only mmap_lock read-lock that is affected is during the page fault, which is expected. > > 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-=3DwiCrWAoEesBuoGoqqufvesicbGp3cX0L= yKgEvsFaZNpDA@mail.gmail.com/ > >> > > >> > and it's a separate issue. > >> > > >> > Linus > > > > > -- > Mateusz Guzik