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 B130EC04A94 for ; Sat, 5 Aug 2023 01:17:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 310FD8D0005; Fri, 4 Aug 2023 21:17:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2C1048D0001; Fri, 4 Aug 2023 21:17:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1889E8D0005; Fri, 4 Aug 2023 21:17:03 -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 086E68D0001 for ; Fri, 4 Aug 2023 21:17:03 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B8523C079C for ; Sat, 5 Aug 2023 01:17:02 +0000 (UTC) X-FDA: 81088287084.18.D48350E Received: from mail-oa1-f50.google.com (mail-oa1-f50.google.com [209.85.160.50]) by imf12.hostedemail.com (Postfix) with ESMTP id E4A6A4000C for ; Sat, 5 Aug 2023 01:17:00 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=folnjqF0; spf=pass (imf12.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.160.50 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=1691198220; 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=cu168Y9vRpg+vzxEgSTGxY5n1ZLC+DuEViAjXzgPHZs=; b=eglZO0DwFTwboehWlElq9GGwR7E+h2Om9d7JIQ2uKH5XIDTzk/Z4LRUhhHjYOMXn8GOqM2 Y8ufUYu06aDxIS4K5HGCop2NfveMSO49MGNJqhEorFuXyFmyJxGZ3S7wZsy3V5jQvBa1Z0 ZhIw5PEf5aVLy/NbWps8mDE3oySaPA0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691198220; a=rsa-sha256; cv=none; b=rmahBav3hVWmUsSRGT6CfNJb9Kj1EwnBaAbsOcuYq7vrL4yyBgMcKQCD001JBs0T8qT7tz eDcqkMUXax7qyleaU6BnoNz5l9vOX7jIoyteGRHGBdDfhaBLvQDtnzoVScUrA27Is6Yx/g 8Xb2UQXekYha9J2tLIq0b/GP6Cqd1Jk= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=folnjqF0; spf=pass (imf12.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.160.50 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-oa1-f50.google.com with SMTP id 586e51a60fabf-1bb575a6ed3so2022024fac.2 for ; Fri, 04 Aug 2023 18:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691198220; x=1691803020; 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=cu168Y9vRpg+vzxEgSTGxY5n1ZLC+DuEViAjXzgPHZs=; b=folnjqF0aKRuew+xhfxHFYWs8LU+t5rP5KIRDLS0LazdBGhH9vtd1rk3BObzT3m5/y ukLp+VvYZQ4Ov8BDfr5g28AkAWB4g/hxW1Ssb8KRkKEt5RbkmTW2rc739qTXAxeDDDUE iIwn+0jXiPiqotQdwWEEf4v2EV8llX8EjhKSrtIZFTH7mwFarOlyk1wE1w1aDt0GwCX9 2i9+2hZ2zwdOB7u07/U9V1zz19XN4xpjHrLB6dRkyuWahGPwMFFO19gkHFqsD51e7KcF SGCnklBW6xXIGZNAIl9Y7eHS6bVtNiEuidNQcV2Z29dq9T8Xtl8zifCjWsz1/ZOz282N Y2sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691198220; x=1691803020; 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=cu168Y9vRpg+vzxEgSTGxY5n1ZLC+DuEViAjXzgPHZs=; b=HeouU9cn/E4aqWeauJrd+3eZtSaj8tyCA99UcKFF/qM2i9nhK/45Mjk4Afif5IAcgm XvMEeZz5HClMRrseM9OsX1ptZMP9yuaqh9FbDuD97nvFoZ6A6k6pag72MPTQUAaSPE30 ar69RZzCS17gEGTfXlS4fv86Jh/JVqh0mpf6d8uPm6vpQ4XwwLihwjwYcYpfX5aF1C4O 1XExB9Mfx4DIxzs8P9zUb1cIKic/BDXsTAnDiI6RhJv3g/DA6LOKd08k50ObuuWYATjY f22iq4nBUYVbE3zvnRr1U1F98MJcxjyjIeFr5OiG8L3jHqjozn0ev4r1oPwxR/M0T5eH i37Q== X-Gm-Message-State: AOJu0YwkOOTMEoJsuitNdfzUqsXGsE8hPsN+xQrN0vK72e6+CGhJLwaw xyVoQttE91lD6TkjXft741Hvzn4T4dYNfr26jGM= X-Google-Smtp-Source: AGHT+IEuQ/dvOW7eFSBM63FzAr7WHgJtR9IpCyPZws0vFNx4oFHhozb1cWWML9qeqWJlkUR7TgqFe1XMIHdejPAlQbA= X-Received: by 2002:a05:6870:ecac:b0:1b7:2edd:df6d with SMTP id eo44-20020a056870ecac00b001b72edddf6dmr3872658oab.10.1691198219991; Fri, 04 Aug 2023 18:16:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:7b87:0:b0:4f0:1250:dd51 with HTTP; Fri, 4 Aug 2023 18:16:59 -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:16:59 +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-Rspamd-Queue-Id: E4A6A4000C X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: wm93g9rxjtwjre8xki9k7g3iy7ngsnqo X-HE-Tag: 1691198220-848192 X-HE-Meta: U2FsdGVkX190X1dveKfMIZ3jOqP6qBb07tPWHajhWFAYvr3kinMtx/5t3utxiC3fNVCAgE79N/iFoYUxdWTka+y+pYJjnr2fubjSe+O7TXAEmO0ZUo1E2KP3lQ4df1eio2TKnswB+bRrRuz2WRtljGJoLA0YwHiYoc2TXDo7KNUbBMbmWnk7Gm3fLnBu9OhBl8nbXVipCAGw682+QRK4sMyxqdaC8wo5FTIxX8F0Jg6A/5Tj9ntbknsvGh12eiZbbtYYj5dh3avMK5ogXu586CTD/Qe5p335dyyNTit2g6uyUIEBQcTfsuvcji7tnDXqlb90J7p0RJ7hN9APfuVNjmc48PW4AFtVCBVSif9xif49NNq3jR0a2jv6KKheml7lGtOsuf04n60Hdk5Qbs0JvRXYpMNWEKEr36Ftg9CE0Eq+rnFxSkLLj8K9Fbo45ZRJyBRFvmaEVcljnOqipHlyPZcExgq1C6qIp2LTdmLNVq/Jh7d6yHwrTZqfY5p8bBAoxV7z9NgVf1PSzV6yyJAb8tsVgmB5S8zm9bqHSonevVmPa4e8ry/sXpbDjzh3do5ivi+VRjkG6QlF3A8gso4mf4Cz0UR4BHIwh14+L0YOEsWMINRWhcMWO8GJdy1UKp2u5KXGkHGIFRkx+x02F7nCk23jfuG8u5sMWigfaoWVMJMrieuovb+RQ4K4h2thXy7s5KCuP+LGz6L4udeC/Roj4elnz06C0p7AKa5Tf9NP9Ss8gOw6LGPZ55FDT8hCUW9MTUvQE8W9oQU6qlywjwygHw/qovrK3fYXSZfoZiZXUYEhlcPQdICIYTYQ5sYtN4d2YyPu8dbRaqPotWeFVfA8IIIOiqW6ZlPCft4SNs+dhbC227D+zX+mJ/Uqd3W2iybKa/KBDYszj4UhMttFVk6qw12Xbl8KKbao+2efhPbCPLE0vdWNoUj4dr13GOQesOeeEbWpc/nOd/iPQSm0iA5 pAFHzxU2 SENlXKvBd1J6pGUXPfz4Q1wut9dpTYP/nKRmpvlYU3kXZwIYLaDeqgDA4L+w9KoMOkf0cib8/BjlRUOsChJ7CtgiGB211rDN1lAYJqKMIZ2X7EUsA+1U//zBp/IMMVNh3weAKDkatQ315hHXAwOw4PzaGbspgjcYr4wjnLHv48aN9MdPOfez7lUcj5OpPN5BUq2ouIaem6dTos/wcMH7UVNEZwt1R+d71cSBEo8Cz0CdmoqcKssGpyrdmILFXFdsqIFEOe7DMN2FTBp7VeZIkpqTiyZXzjHc1BGYPxG2efqlAd+1W2EgFViDgnWkZlQHmXWqoGI3/iOXIGA5TBgcHl31J6TnSK4Y4yuMfduVbtCunSAD6iBj9XMp/ZG08PEMgkgaX68M+HpBIgmc6Djxlu7nHrifqwZR5VrwoylTDGoupUgtltLfyOtj95D2I2TaCmSIFX2xosp4QXnaYU8liemsOxA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000033, 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:49=E2=80=AFPM Mateusz Guzik = wrote: >> 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. > I have difficulty parsing your statement. I am saying that any 3rd parties which can trigger page faults already read lock mmap_lock or can be made to do it (and I don't know any case which does not already, but I'm not willing to spend time poking around to make sure). One can consider 3rd parties as not a problem, modulo the audit. Past that there does is no known source of trouble? In my original e-mail I was worried about processes up the chain in ancestry, perhaps some of the state is shared(?) and the locking at hand neuters any problems. I'm guessing this is not necessary. Bottom line though it looks like this will work fine? That said, I'm not going to submit a patch I can't confidently defend. As I did not dig into any of the VMA code and can't be arsed to audit all places which mess with "foreign" mm, I'm definitely not submitting this myself. You are most welcome to write your own variant at your leisure. :) --=20 Mateusz Guzik