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 AFE7EC04FDF for ; Thu, 3 Aug 2023 18:02:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 36F5928028B; Thu, 3 Aug 2023 14:02:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 31EA728022C; Thu, 3 Aug 2023 14:02:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E76D28028B; Thu, 3 Aug 2023 14:02:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 1170628022C for ; Thu, 3 Aug 2023 14:02:22 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id B3DF3A1260 for ; Thu, 3 Aug 2023 18:02:21 +0000 (UTC) X-FDA: 81083562882.12.B4E5092 Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by imf01.hostedemail.com (Postfix) with ESMTP id 6A2C140095 for ; Thu, 3 Aug 2023 18:02:10 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=BbCUOyD9; dmarc=none; spf=pass (imf01.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.54 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691085731; 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=2DvzNefb/LLJHkcM92Xy5CmVgSgsFXUiX9UPGxAI7fs=; b=Xu7Q5NUwSU7blEVd5ElJ4iv2IgFZVuDyFT1jsgzk95JuHoPfdCZZPR1GOP7lr5b44cDfoc VZjvVyGWWdP16bJI4SBSSVanZSWHagDcEkNfLKYCLhWBxZh3OgFdzqLjuqBCAH/+UbkTOG hoMtSipbPfa0GjJAfqodDMGPmWsja4g= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=BbCUOyD9; dmarc=none; spf=pass (imf01.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.54 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691085731; a=rsa-sha256; cv=none; b=2JooGCV14dPRHXFaDnSRsPQLlyDWZC4EeIeE4uwdpCDwdAfHKBAygiJ+71ikyUxBfGmkUF cqVS603kR6ggAdEEcX4jIi9evrX2uXtojt3ofgPrnifOIw8sLeZ/59Ngwxl/FV7QiPlYdk G5ycIxvYbZdc/aljDiVKufF1tDr0DDY= Received: by mail-lf1-f54.google.com with SMTP id 2adb3069b0e04-4fe07f0636bso2172840e87.1 for ; Thu, 03 Aug 2023 11:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1691085728; x=1691690528; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2DvzNefb/LLJHkcM92Xy5CmVgSgsFXUiX9UPGxAI7fs=; b=BbCUOyD9207CdZ4NVHPzWxLtH+xHiEGG/J61pIlnagBnZOe4djYIGS8Ke58bKdZorh W6sCkrjJvfNCQmWXjCiv75uIP5ug0E6ZZj3z8JhdbLS/tlI6eYwyxte3Z87HmThKixtj vEKjfATD2hNIP5SjUpLqNexrrZltg6OJLRwbI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691085728; x=1691690528; 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=2DvzNefb/LLJHkcM92Xy5CmVgSgsFXUiX9UPGxAI7fs=; b=KOTBRcr62y4vnypC2XWWQ3G5YfAP8P2hjHUTtaYrg9+wzRnseF6tzB/PlJ5TdyVxGO SZWVSIQB9YGc3zH+G0mN5CUR7QIwRS4UZEeOM1bEa55gE1rUpq8ryYFCegOQuUE5Bn9p QJNkjCWLkNlMzJXKkfIClk98GsjyudaJgclEd8NopgAfHVrWqLdYSs9dF0IY0i7ZWwyW O+5mxYLViWAY+E1f1CEWdxIsLA0okp3+E96QI+ejwosSMdcujTYQ3AlMa6n93O4plZ0i paa3das7OBr9WkH9zREAGMcmVfSbNmzytmMTjYKrTrtSZHqvMszPUNZgGHsaxYEhqSyk Gl5A== X-Gm-Message-State: ABy/qLaNwMSwaM3aGfDzwCNWIdWDin/kkYU2cOGQCUdw0WEPhSs8okAv DEcOdFg5cW5DEzgXK/UbQAbz/H6mrHJRLUdqbFNJo4vS X-Google-Smtp-Source: APBJJlEIbSwRBf11pg4PiVUHdZnD8ax8EW2GevQOOJnCbui4FZn79kq0p1xw5C5BjSes58B5iUKTAA== X-Received: by 2002:a05:6512:3f3:b0:4fe:958:88ad with SMTP id n19-20020a05651203f300b004fe095888admr6851145lfq.10.1691085728505; Thu, 03 Aug 2023 11:02:08 -0700 (PDT) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com. [209.85.167.42]) by smtp.gmail.com with ESMTPSA id q9-20020ac25149000000b004fb57f28773sm48527lfd.285.2023.08.03.11.02.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Aug 2023 11:02:08 -0700 (PDT) Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-4fe07f0636bso2172813e87.1 for ; Thu, 03 Aug 2023 11:02:08 -0700 (PDT) X-Received: by 2002:a19:384d:0:b0:4fe:d0f:b4f7 with SMTP id d13-20020a19384d000000b004fe0d0fb4f7mr7004017lfj.65.1691085727752; Thu, 03 Aug 2023 11:02:07 -0700 (PDT) MIME-Version: 1.0 References: <20230803172652.2849981-1-surenb@google.com> <20230803172652.2849981-6-surenb@google.com> In-Reply-To: <20230803172652.2849981-6-surenb@google.com> From: Linus Torvalds Date: Thu, 3 Aug 2023 11:01:51 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 5/6] mm: always lock new vma before inserting into vma tree To: Suren Baghdasaryan Cc: akpm@linux-foundation.org, jannh@google.com, willy@infradead.org, liam.howlett@oracle.com, david@redhat.com, peterx@redhat.com, ldufour@linux.ibm.com, vbabka@suse.cz, michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, hannes@cmpxchg.org, dave@stgolabs.net, hughd@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 6A2C140095 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: pfoaz8utz1shje5z1o8me83a4rnk8j4s X-HE-Tag: 1691085730-473742 X-HE-Meta: U2FsdGVkX18u4ZVKw89EXWiAC3wlRvPXdu12nqZyfBeFirExmTbSlTihlhXii6CQYTusGmV9lF0NIHrRD7ZxBCbko1fRiBA9Nx6trx3eFV/HERvmkWrMEIXbivVSMDM53u9YZcy9tet4OWErMr111qlMMYkIQrUZyUIgYhGhu9XgklWX5mW8L2oW3abQU15qmcw34msiMdtgHeERhg+ync39oIQ9YgWTPRWJstugekRP2EYfOYYH4pp2/etjg15W/wb7Njskqze+LjtlIpja7d3kUFHGIFuEE6o/Vq9lSJGRsOIayXgS3WkD2pY/SBiaeQVm+Cc+HnBABakLozfobxN3HRDsxyU7pgibImEs2ikDQL9J7qtyNmXff/wLlOK0EAn8irryUXNHXu9lRpklJHvfEt3pvFqOowkW1lYW1L7L8lXiXJU8se8qiPURTjft+FtCsEILd6V3dOd/ChpkeuXmRGPyZG6sVq7l+JQkvV3UnQblRs4b0pDbuCG/SfotpZRpUIi2WvfnzczxVQDhAJV6/pc5SjbulvISbIzLryTxuu7QPlp41ykjXtnFzsUdUU6WadEe1NReOlcLYmAbMjqJa/6lcgVULX57eQOFCMxhxpAlDOWG2ik9lidMNmdo0SPCIkfjZ/YyMyXAOdUAuxHxLzA/S7p6unF4k3Yl8vIfKynjDEG364DtTlaAr6Z2rZYxRcwM1i0/LIRvPs+vUs7R9heG1bYOIYFk8cA6x7qPpDk4/0A5X9jOcMQcArG2JSqtC+2ALC9KM0unzQey6u4/1R4WZBcW4jiGTt8typmB2+zdNwicLnXrDjy9a/HjvlE9517O/BYBF7H0bGyYWvHBcMvrglhNDUTH8wPpP9VWRDGKakWS0CCEMUhpDrRKxbYfmOonyW7OuOqqKZWzWkQMLD8ZZbywW912j34Ve3ihPGDp3zyWGsK7EQj/Cfkfg2U9RBO3ycAdno1t9DJ EG9q4Zpd xiimAuKg2FAH0hr9qNAYZBAuco+DX1BdI8mf/RXAnxO4VxC5Tz9ubaohQPSAyBXn4Mr9UJE9+upEKe3nKVTX8KJGbWLmLbM5e6HaNAe3QqGTZzkVtCqYRb31a6ydjJm64PKXkoiHqVOiAjXLHUthr7JDEiSDYvQp5Ed/z4Kif3rTZaXZLuv1rpw1Rdf+L7/9MROkrG5PxGIaZUo+LIzzxS5kgInyONuxHOn6zsdppfZg5PTWSxN7cW/JXr+8/bykiOjpoULC1eoOzfWrYFnJzqWAMTe4o9T/PZcLWXXtl02R9oukaQlcaezqEMNViRlK8nuAJbOKhwBdCuPVN+sSaVwO9JySLmlQto24k6nJA5nWiRiVOr+b/qGpiw4X6ZnzFdjxwa5Vhy9PAwE+0QYHaMubyGMo3mMr8SaCNBqhhnEs6TzSCWERdH9ZmEfRgQmCFxeRqI6VLsSR5CxIRiJy2g5OAB1o0K4b2cFpQSw3xFDTl3i8vM2obETLB1v83wYV1Tk9ZmsbN2vJH+gk= 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 Thu, 3 Aug 2023 at 10:27, Suren Baghdasaryan wrote: > > While it's not strictly necessary to lock a newly created vma before > adding it into the vma tree (as long as no further changes are performed > to it), it seems like a good policy to lock it and prevent accidental > changes after it becomes visible to the page faults. Lock the vma before > adding it into the vma tree. So my main reaction here is that I started to wonder about the vma allocation. Why doesn't vma_init() do something like mmap_assert_write_locked(mm); vma->vm_lock_seq = mm->mm_lock_seq; and instead we seem to expect vma_lock_alloc() to do this (and do it very badly indeed). Strange. Anyway, this observation was just a reaction to that "not strictly necessary to lock a newly created vma" part of the commentary. I feel like we could/should just make sure that all newly created vma's are always simply created write-locked. Linus