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 05E65C00528 for ; Sat, 5 Aug 2023 00:20:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 666B86B0071; Fri, 4 Aug 2023 20:20:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 616018D0001; Fri, 4 Aug 2023 20:20:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5048A6B0074; Fri, 4 Aug 2023 20:20:28 -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 3FC006B0071 for ; Fri, 4 Aug 2023 20:20:28 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 0C4ED801EA for ; Sat, 5 Aug 2023 00:20:28 +0000 (UTC) X-FDA: 81088144536.29.097027D Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by imf15.hostedemail.com (Postfix) with ESMTP id B88A5A0004 for ; Sat, 5 Aug 2023 00:20:25 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=E2noBUQP; spf=pass (imf15.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.47 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691194825; 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=BOt/owxzUYbRmdYSMwC2b72ailgyx1LyngYZzbpA3ng=; b=mSAVARljlhedXQOHhoUDx7mBUFTSpW6edgTcCxXj/W1aIHEG+B7FMuALWjzie0N5FxyHXc vru8DW+3qlj5mpU1EA89/wDv44haP6rwdmG3N9HHh5DNCAMFC0RqWwoxh1zZ83zF/wWlZ+ 8FRRsXluxVCvC5nWpWs41fByg8T8P+I= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691194825; a=rsa-sha256; cv=none; b=uAvWpEzTm0RpO9Mr8OODWpkdb0GQmJnXP85f46kmWKiSvCVrd31M28r+AoTNoEnxM0YhlV EqLu7VUMb3Z5a+amQQRGE3qB7AcophDZ/jfaUpiYJadTWVOOSddnJo8BIxBcGoVIv0QmVI rUOZ3BZBF7LD80WD5JHoJgtI4Q2sOjA= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=E2noBUQP; spf=pass (imf15.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.47 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-52256241c50so3454274a12.3 for ; Fri, 04 Aug 2023 17:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1691194824; x=1691799624; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BOt/owxzUYbRmdYSMwC2b72ailgyx1LyngYZzbpA3ng=; b=E2noBUQPWc5xm/yHWJ2Hz76Kt+du4EUyQ1S2maX7o+oP4egEEnlN++cqan8smf+nfL OjDXR0HaldNi9EPbQP1/hHTLf80TT92hhcfIbXU4RDEkAiKe1C96VbG7LZP36kxxOxgy vZCn5pmFCXYgVDllT+cnn0SnmR9Ox8X/RJT70= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691194824; x=1691799624; h=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=BOt/owxzUYbRmdYSMwC2b72ailgyx1LyngYZzbpA3ng=; b=DjqK60JbWOH50g+TQ4Tna4RwbBMl8Y6LtWnEJJQoin/atlT/gVEdLOjJv2SBu+fRw8 HenQmqRLsr2XCrbnl8orK7JHlcqVHOYLsI7c+3Ug7CmN4zlZqAEj3CCsdY7HcsCH6IiB h/A871FAxPz9bNhe2UKXaMc6WUcQdqxlEE9Wl8GIPpPwvo5bYkf2WU/V8ODP7ExCm10u 7Vl8i+QrkPuO8ZNTMjft3F4sasjOXCGWYbT22J96RUy9ODmcRXeBfGpuTxm3juwwsFHS yKIFpBMy9mvCzBnkOnZXNcyrqA+z8k/M0ny+tUzGTy7zmXkvmHK+g5uxXkMnBoN2mnfP doIw== X-Gm-Message-State: AOJu0YzMms5Hm66A5duvEXlLaAOO78jUi+rjoT3XWL/6uHfQ5XvUd7yi wlnVPgJOIsdsg1euf7tjk/ocZgkw8RFTyreF8loG+P2G X-Google-Smtp-Source: AGHT+IGQzZMYvq/q4ZowSo5YAUTe4LzvxeWiaDwOCpTfMUYLnQnC5yM7NZ3Tx/IvsqI2yavMi6YtGA== X-Received: by 2002:a05:6402:28a:b0:522:455d:6f6f with SMTP id l10-20020a056402028a00b00522455d6f6fmr2807130edv.34.1691194823716; Fri, 04 Aug 2023 17:20:23 -0700 (PDT) Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com. [209.85.221.47]) by smtp.gmail.com with ESMTPSA id u1-20020aa7db81000000b00522bd24790asm1904759edt.58.2023.08.04.17.20.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Aug 2023 17:20:23 -0700 (PDT) Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-317c3ac7339so1927721f8f.0 for ; Fri, 04 Aug 2023 17:20:23 -0700 (PDT) X-Received: by 2002:a05:6512:74e:b0:4fb:ca59:42d7 with SMTP id c14-20020a056512074e00b004fbca5942d7mr2051745lfs.33.1691194495615; Fri, 04 Aug 2023 17:14:55 -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: Linus Torvalds Date: Fri, 4 Aug 2023 17:14:38 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 3/3] fork: lock VMAs of the parent process when forking To: Mateusz Guzik 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: B88A5A0004 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: y9tocom4tsiasgzzugjtf4m8s71as59c X-HE-Tag: 1691194825-650994 X-HE-Meta: U2FsdGVkX19PGEvGxAfdwESYXl3++BjdV0gIyoVlOeW0rAkb41ojjec1vmHsO5lir9qD4qKzDLrk40A1QImSBl3vCxyUZISNG8Kdwfk29/mbg5pq8YXIdtcuWt6UmezMwlIASKbchU5pxWusegP5+bbPU76wUPYq4gahG5XIw7nS6tsOuli5VQ8qQNTdOjcBOTX5eo9s3Cd74137qxisx+aLudWe7bR1Kj4H4XX3kucVt++wZAiXCHfFxwsC8HGqv9EfwvIHq7Pfn/4gLuQiSoOh3VWuF2z88ym02aT2x/MK2o5J1r3Kvl/K6XVZef11PceywlvjbbSUDzlF9loqdWy5pWBG/ErAoOU8fHhXJi2XriY34DEHPjewShP794XwAjvziOcAeGZ6UNCW+4YOJNZbVgla+/jaqwUcb0YThUXaqO6penbNorjQECXMVjje5qn4wsO6vT0MkxTl+fcSUEwADmeAk1v20dRNyjlupMKh0GXEWKdMGztUDYCP1mbHfcnFLEvKKZQfWC6h29ZiL+S9fkuTgs6xc/xj8TgNADCt6ffe6L6VuMFab2drjuLI4VD61YHP17SabO8E3QsldHcPPeI3lV/hTJEPbN3QA74okd5vm9qk9iCBqgbZ2uMa7EmGjaG5wLx97XoHpUqA+/jLR6lUQ1SvMd9i/Wxkn/O6p2MAQOODHxRhtFXXWqWJQGht7eifi6iVt1QORxcLcUOJmFgMLfStCwoTQsdkrNpfWDbS/YhnhNNEUXNXglO4bQbJpvvmupnGp6/XBcfsLeNyzX25iEWi+ToZtP5uXBecs8zl56y9YRrXS+tv+jHGG7LUxMpq4ktqXAY3DugJZN8Lc/TI+3JWe6R6krva7IGdxGTk8+sOvcT+ogBUjmrqmAYfLqDSv7tACJZ4Qy53Swc3rLGCklF3ma7/KVfJfdHdmpBmCsfkmQffspPq/O8xRt1Hj5uqW5XL0OfQS4t OmcsP+uJ KZY+dJnVkPrkbDTmeO5P/2wnNjfowPXTqWNjoaWIUuUo+fNnylfctCb4a6MVnU1dJvpRKqCVmLrtW8WmPU899iU7K/WTxkHFmPHDzl2IHPv2nZ354/7kO2yv9vJ/jwr+3NS0UDf2kNNhxUg2YVrLqF1nuK8g81XDPmncQWCQoJzZlHMfBjj72iXbcjWARiX9p4D37kRZ72kDCPEFahODPKfsZ/ixOR1kARQbiNpb3e6tEvsG0dWNw5tN13ayIN5MapnR+BUXm7dqPOS115CUBv+S3z33Ol0AM7ctCN0cswCDOcN6d/ukOWNIUl/cqA6dRXB0AZwInM6WHvzG4/iU0DOm+0Z5C1Jopz5eU7g3rceWWu05jQeXSOrwY2Z9nSvnY8d3nMofjP65rRj8IYzZWZ3g7S8fk1FZS56x/oy1uUy9NftjMswcN5Udd13K6kX8BGmXNiE/beWHW+aDMjnR839yfczLE4XEjsh88Z3w+InSEObiq7lURAXXrfn4GR7wElj88MjmCKcRfWnjs33bxFOiOA2gVrl2aDA49bF+irKWbzxiOAguKiWiO5DV40Pd3Tl2hbVhqRcNDCh/0z3UDhF7LaDT4f0N2UNyN4Lsc4zodJJdYRtmxTHjzRk7VLRRVfZhRCXRxmxRdKlt99zmW4Y1qlJ2Zq0mFulo07i2ieStY+ZMS+0NDSrWTm2eMZYPMulqfwz+van5X/1o= 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, 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. Linus