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 848CFC41513 for ; Sat, 5 Aug 2023 01:36:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B7F008D0002; Fri, 4 Aug 2023 21:36:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B2EA88D0001; Fri, 4 Aug 2023 21:36:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9CF048D0002; Fri, 4 Aug 2023 21:36:50 -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 8AEC48D0001 for ; Fri, 4 Aug 2023 21:36:50 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4A5A480514 for ; Sat, 5 Aug 2023 01:36:50 +0000 (UTC) X-FDA: 81088336980.17.668D4AA Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by imf18.hostedemail.com (Postfix) with ESMTP id 93EBE1C0013 for ; Sat, 5 Aug 2023 01:36:48 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=bpswymm8; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of surenb@google.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691199408; 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=AujeCo6jm3AYe4qZ6y6dt+l/y9fmf46ls+zy0ks6uBk=; b=7oQpjcxISd5na0y98c+Wd/4nDL+GyFPfqVB517HwGbhC9hubXH++ZVkaVyHoOMrB5QRdwZ 3ZuBerOXae/ENw4SfUah8B98YNNs6AetAI4KiIVnXHTYULxABraBG22uhdXraB5y+nDVUG KyD8BpJ5qu/E1Hw4HkZGnb7jfQlwz1g= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=bpswymm8; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of surenb@google.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691199408; a=rsa-sha256; cv=none; b=tJwT3ZM7TOymPN9V9E4vgPOY2hN16PAcc4tD3z4r8EOI2N7fJ5Gr7qkkfmy/tsVBCe3akT 443Ic6tApbJQNvZqmVBpUJ9d19OYLPIElJmNKw+jAImgOQUfACw8jxPWnwSrVYjI1OccF3 QgUTuvoTNdS6ML3CVVo00DU+TmsHUus= Received: by mail-yb1-f178.google.com with SMTP id 3f1490d57ef6-d3522283441so2685853276.0 for ; Fri, 04 Aug 2023 18:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1691199407; x=1691804207; 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=AujeCo6jm3AYe4qZ6y6dt+l/y9fmf46ls+zy0ks6uBk=; b=bpswymm8/aHd6mYtUujhG2QErdghxkdOBUSisUuXISL43iBt5anSiCY7npzyoUiEp/ 2r0DThfOtkG+yPEzC58xZLlele5B03sILA+y2PDwjAPMcXtkwUcFy5lrcWm18fIezCd2 TvTlOQPRw7trWWi7TFwzUQOVcXl3hZGoUY/y3/OIyQgS+g5h8gNRs0QcE+lMY/pkkoXy Ns1q4mZuMDjIYZNsw7vuvEEABh4IA+p+ZsHCspKeMOXHkfvzh6yntnLUxWpgnw8t77Vi bBEHLKcSkpQzi5wly6AOeCVeTC0b886H1B0C1idctkdvu2YXbxSIRxaC+odXZzrzeWAu h22w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691199407; x=1691804207; 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=AujeCo6jm3AYe4qZ6y6dt+l/y9fmf46ls+zy0ks6uBk=; b=Zd0NFgeCxCy2FVsNIlNZwCLQH3Oz5jZO3hu7eIzKiqYxaYtOCJyMX+Ef1RvD/BSNgC YCD14TP4MjtFzcB2r858raQcWRFhslXFMtXiuUnyDtsSG8ZBl+OZfdrHUQJZltr0ZFge hei8p+qRFrCE7qaCFQdmk6vhu0VxFoCL8cQuFPPZlA1enhodVz46i9P7KRKsJBYlm9b9 NT+BhQHSWU8id8EbzfFBfzbhyX6bVxB5hzTsytnhKu6WI6RGx3plLrn5kkH8ywqxe2Y/ 4ir3OSs/GG2UXbJqzz7m2ixxHRGZwDhJeKFGGHDX5BbbcdIzraEmfGE+iFaiaQ2jG4Gb TC0Q== X-Gm-Message-State: AOJu0Yx52qklVXxluSyvQUSczoSj2m863aOh09YdfMEsZol2oQ3golW7 qusGha0VO3UrbKwUPp+L0Dsji1POa4+CkldZUE7zgQ== X-Google-Smtp-Source: AGHT+IFJHUDmRmfkaGOcYBONV1HYLRgCo/dnuTAMETxoZRKS9/hRI1iaTAV07Qp4qriq/KEZCcwC9+dZWAiPFh/72cs= X-Received: by 2002:a25:d08:0:b0:d1c:7549:4e8b with SMTP id 8-20020a250d08000000b00d1c75494e8bmr2986579ybn.29.1691199407388; Fri, 04 Aug 2023 18:36:47 -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:36:34 -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: 93EBE1C0013 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: i4q4wt1frc8aqwmwr3ned8q5i7d4dk68 X-HE-Tag: 1691199408-459609 X-HE-Meta: U2FsdGVkX185Jxv2uCeSKefrfQzDWc504hScnA2arT3te1KLZGJX/WQfNlyJDAHi6ym7afsEIKkiP4sHl8974B+IjACmPhUtISVIg4SI1oEvjbUHAUNNbigrnKq7eq4HqYQXMxLcYVQOnG6GGWOF76N/T1yk90os4I2TqCcAGS+TqHzmuLjq7laIAS6m/i+RfWNlsXqBe79H4HdlfQ6GidmxLqDNrHRY05TWVgxBpoMyb15qvz9oOl3/dkMhThDGCZAYbqOcuCbGffaii+C0lTGpLqhs0U+AwWxLQkLEyivQ/wA+v4n+WGaDHsQkcTA5uPtmMk5x8smFb86gkEnnSpVCo42n9c7CDScQWG97m43zIFZnCUM2eNzoHkW8bFHb4PiJ702fK+IYt8LCB+mqFNWTcK58Gm4Ba1eAouKdbLBpClfbpLm0ZABCVwangMrLIz0tsHuLw1y2Fk/CQWpwDnwlmz0avJyIN6/afP8QgdGDySS7vOOEFIUSAilm7CBn1tNH4uzbFmo6HnoMiE6K0B8Il3KbocB4neZ3deEmeXN9aZ3OVNIst4gnf9Bac978y5jJ/UVuZnNgYZM7Nmg1OLd8eIdiquzCqyWP2JQrKaxTk6C8e+rmzlgCFUCq9htFLx3W12AlnIVKiUszorYpFBJ/uvFYuMN6/p3iXAs7FnjcYmCvn4fv9C5ckGX7eHQ6XCJfGFeRKvZBDBe22ouGDzFxLuXNRIbwhNNJ7Lqm7aZAmYRWQZZfZDts0vQpwlrYl6ZdsJyz8jySswSS+5lfHL4cWAXbAJqa+tUa5H74uCQiKI067+czeA/v1h7nL7OBw37gXvFTvFZSXjRXv6Ksrp66QMKoWNcVDcIZ+MYYC1Uusa6A4ZcPU+ykkVjauDAxpBOFEfSHTmRRzwYHTKMM2yvDaWPnqu0BO+M/wqmj6OutI5kxWsYdHkjqnfCD3reLJBZVXqSlR4cDewJe7cV jxLqK+kB VX5uEnTvrLuVb4qQLvETw8j44YxZWuJIANEMEg/LGPQJ2WUmd2vkYqo4oidVZrzJHalRWJrl43lBrxNR8JuEy7e191MN62ZLutjtw/ym75wE/SD4LNFwZ86BdCwRqvMSa3BT9BqWpgJM6zC08bD8VUnXGI8P8pfrYozUYva4Ky7GZtOnPhWBgziEXTI/wqK9YDRxxGSnn1nhPAlXrPM8xli7UTRCtCm36RC00AWmDFYtR/fOagobFanxHdxYkRk0BsWm7UJIOWxCVylvUosDtIDWy8DcPFWeGZuGkfiXi0eM92/oTDoO5ksO47ofPMYCVfi66cSKyiX+t1YoxiONpUdHHr6PiOO+yFcur X-Bogosity: Ham, tests=bogofilter, spamicity=0.000010, 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:17=E2=80=AFPM Mateusz Guzik wr= ote: > > 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 was just saying that vma lock patchset did not touch any other mmap_locking paths except for the page fault one where we try to skip read-locking mmap_lock. > > 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. :) Ok, I see. I'll need to double check locking when a 3rd party is involved. Will post a patch when I'm confident enough it's safe. Thanks! > > -- > Mateusz Guzik