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 BBAD9C001DB for ; Sat, 5 Aug 2023 00:34:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0A6DA6B0071; Fri, 4 Aug 2023 20:34:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 056A36B0072; Fri, 4 Aug 2023 20:34:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E606E8D0001; Fri, 4 Aug 2023 20:34:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id D62766B0071 for ; Fri, 4 Aug 2023 20:34:23 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 937A6C0697 for ; Sat, 5 Aug 2023 00:34:23 +0000 (UTC) X-FDA: 81088179606.18.0439B1F Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) by imf11.hostedemail.com (Postfix) with ESMTP id D2FA940010 for ; Sat, 5 Aug 2023 00:34:21 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=h0TxxwCK; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf11.hostedemail.com: domain of surenb@google.com designates 209.85.219.172 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=1691195661; 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=GE6BW9pFYdezUl7cDS0TzP1DYFsIzJQ0ypEfGdJ3TBg=; b=i6XlO/5X/AfJcbpEdthOsSYgtaNvb6sZBFm/1AumKbbNb7mSmbLzLIWM54yb0zLuntLfh2 iow2i1DBjLOC+/8UB3JNL1jRx47aggJnzEu0qp+zJ+eHrIlPOuZyJZtce0pJzRMB/bEs9C ig74MN+hfCjWBB8EWyouDcrD26mSFNM= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=h0TxxwCK; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf11.hostedemail.com: domain of surenb@google.com designates 209.85.219.172 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691195661; a=rsa-sha256; cv=none; b=hDQ3Ysg7TebLsmFVDIg2fgaMYAhA5gJPEbGRmwS/G9nM7zXn8JEpUd9q3cr6B4ZVe8qf0E Jyy1/TTdXAsVyxVeye+4K3t+6cDXT6Ru+cnK/JKe2SHzzZx8v1ju7Kswrjmsf6WzmxVF3l YPaYe/5QDNjionN6+rIsU6lCyJhPe0U= Received: by mail-yb1-f172.google.com with SMTP id 3f1490d57ef6-d4364cf8be3so1461368276.1 for ; Fri, 04 Aug 2023 17:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1691195661; x=1691800461; 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=GE6BW9pFYdezUl7cDS0TzP1DYFsIzJQ0ypEfGdJ3TBg=; b=h0TxxwCKVye0DQdqW8QciL6a/cGS644vYZUx3RI0OE1671HBfkLOeCjBNqcVrLOU2b ycUmZSGLpA9J5ensM11f+iadX9Igk/HzJLsetwc9ly0gURsAFjMfewFY/ZbbuNvVegBO zzsxkPT9b50kkszDh+PkQ3GspK2tIZt+I3X+8usJTbDu2o7JkhwHvqL4jBShd4IfGcpl UvUXcNV5NlwO1ex/P6Q99K1X+l1eVkU1QU5hcPg4wm2SkhYzjGIIbU58/izBoxYFf7Y/ H2/yj5m5CuBBcYn7Gjr7Dd36TjaoDemXFlAk5O+znIBaWL3JFXYYXipgVBaiJa9ssh/c YgvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691195661; x=1691800461; 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=GE6BW9pFYdezUl7cDS0TzP1DYFsIzJQ0ypEfGdJ3TBg=; b=kIy22Erqv76YiPb6fPjDDTuvUl9E0o4f9uCQol6ohKMSEgwDkCMjpjzPyJ2Up2SelU /nTajJsw50Uf0QolWDhqVtz4Ze+l37Ab9OtHruHE+CDpGC8j6+sUC42aOVLgha8Pexzb fg3rq6XV3QcevJFZ7+M8++CvoT8CsnO8onFbGqHvplkmm0KVzIBjpisx9QnRZXlAm5NM 1rYHjtAj2mUFyfyeMBAyxSUtOtthJr86ZZTGB6+88TldwQtaTRZc8m3djlJcinNmV3Wr +OUHbeJtfLrQDlHfJh4x/qVXgt0kwxtEok7OArJLeqcSakKttsaIuNvldNG66FBTQonr XrhA== X-Gm-Message-State: AOJu0YxUOrLEz2PDirXyt4csZ9ibfoDImxbpF/42GJuj613XuLW8BmIo g+Yn7NplWMb0fIxcGpta+E5e3eSv7wt/wcvHdc0kkg== X-Google-Smtp-Source: AGHT+IGIa1nXviU0YBg9eLF8cyB0v1ib0mH9PwLc2T9pyyHMpMQsFzfvoD0GfbNXEO9Va/0KSmKs9VeIuXib/uNqJuc= X-Received: by 2002:a25:250c:0:b0:c14:68fd:6e30 with SMTP id l12-20020a25250c000000b00c1468fd6e30mr2908586ybl.16.1691195660786; Fri, 04 Aug 2023 17:34:20 -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 17:34:06 -0700 Message-ID: Subject: Re: [PATCH v2 3/3] fork: lock VMAs of the parent process when forking To: Linus Torvalds Cc: Mateusz Guzik , 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-Rspam-User: X-Stat-Signature: pwypg99xrmxdff9gn5nkd7ff4w4e68kg X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: D2FA940010 X-HE-Tag: 1691195661-915402 X-HE-Meta: U2FsdGVkX1/8qvok/d4XSsRPugn3Dfhg6vIjN1W3y/wPWYXi8iyDVK1SnGDKOEAnwJ/BeOsxyRh+VGo+omkADOvOCOT75FKIJqsgLXpi8NxsOA30/mWv5WPwzFvAYV6FDaDN4NsXxT3BBRnxKJ+YCWw7F184/era2IvvTIZ9gGR2UcNeYzVorKbOKUP5DsV6oFFrSB1YoKtSvnerJ+C2JaiyESgKEW48fOx+1DvTYNqNZvdkTzYOvSQTfyUEF7TTbOVMnveL0qXqkg5aso16vsEAN1VTfMBtRkfPeM5qitb8oQVAcEsj00m/sZdNS4L5VV1ntKoIAg9KRlhCnEZoqE9eL9ItAiVLXeJMwtUyP3w6KHuPTc95jLMBzYKSWnorklBzk0T+hNH1csuRwsZfDoxrmasKStkUieWwi1lbgkgPoGKPuBDVYK0eOS2w2l2N/vT6sPo1+If4nm30NT7vSdHiMTodLVwKcb94AJ4L4F0J4gD590NmbaBlYTObAXMcx4HrQIo6sPt8nSU4Ajh05Q7W6xu4AJY73d6ucBSiN9KQvG8HAqAee9FTlhaXAvmB8ZYVZXtYDe4k5OWWnCpo0a9R/+4AwTrgniIWILyCK+0ZTTbDOqeQY90iVOZUBAAS1yNGLnYR0mM6qVhM359p5NbIkIMmBi7eYc6k/Xhcwu2NT/6l22t/omNj1FLPlEBekC460q6wP6oSDzfV9MIer5ixs+nKrjKat0lrM8G5dFumjuVbBbKr/WWLRbouyKpeOvTzFJzrrgGoSlIDgt+LJED/Sp4d+rXdSrhnSS9rkexMN+4LHzPtioPynWOfRDdi3mgGgVdWqf/0vK6fjUs17+lgG9CBjjPXHx2NvS74DYGUE2RD2H35gL5J8zh1t8J5L61iUPJtsmqtJK7+MsPWFDmIvdS+FKzaHaAp247BJevxGRI/H5skWF33znFCh9rWr9CF6p3AO8B2B4LuTz1 EOEpo/WL goZ8ZiYPFewoTEhyDNR1HzvlHFRAehKaSpzl+Asg0G6QFlq9MPZboQnpDXT6uZxkthOvH4SsRvv7sM9JB44E6mKzLIEG5e6YJkrGzF+yMuedvFKFsZRZtnomPHqUqle+fikehh9Hu5mLDiElhSbKDSgtNK2TW0kiy+TPPHzdZKGtKq77DlBpMP0E5xB7oX/30gnIOXrWdmgbpMYrgtsPfZkbMsB2SzeUDnynuwEGebjMeHaugY7U8zUyn3b5N2Vr/QmvpyVJB4BRM/ttzSllZWsBqjY2pxyLM/h7wvL6+EQQjIgOUvBK/oSFPSkiQ9+gUxwtM+mww8g8nTPhIog6ogl0Ni6xM/Ar1lHBMdWOrgFbtk585s7giZloMRwJ8ibHEoQxoe9KUQl064wbzs7FDI1xPoBUoa2nToRDqJavqasrO9AEUgr2b4EOv2M3YWqJtUx3jJoYJ0fwHnz0u3quBkVZxHA== 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: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. > > > > > 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-=3DwiCrWAoEesBuoGoqqufvesicbGp3cX0= LyKgEvsFaZNpDA@mail.gmail.com/ > > > > and it's a separate issue. > > > > Linus