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 76EF9C678D4 for ; Thu, 2 Mar 2023 02:22:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DD9766B0071; Wed, 1 Mar 2023 21:22:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D62C26B0073; Wed, 1 Mar 2023 21:22:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BDC766B0074; Wed, 1 Mar 2023 21:22:07 -0500 (EST) 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 ABAE46B0071 for ; Wed, 1 Mar 2023 21:22:07 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 75824141051 for ; Thu, 2 Mar 2023 02:22:07 +0000 (UTC) X-FDA: 80522358294.08.C018DA6 Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by imf14.hostedemail.com (Postfix) with ESMTP id B2A98100011 for ; Thu, 2 Mar 2023 02:22:05 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ICNzManC; spf=pass (imf14.hostedemail.com: domain of surenb@google.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677723725; 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=icYcAz4iENgGguq1MUlInM5/6GsRcXFU+8O5VO7eInA=; b=p71C7+OP1PAwqP6b3E9qFPMpALxD4CdQnptWRHSFr64eIKOHWRpAWe9fyx34z6eTOjeOZ2 pOUfXcfdYyErgiOtsR2JOp5D8IlOFlwMOO6Hh6GmLeOJCGvuTQ/ZDS5uoesX/GCNkAZRF0 5OSa4clymk09N1DKNyMJrNEeGQoa/zo= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ICNzManC; spf=pass (imf14.hostedemail.com: domain of surenb@google.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677723725; a=rsa-sha256; cv=none; b=KrfRhnbUeTt2a8tk4MjjIBmg9u42/CM1urPw1CyzQmpu7D/a2fyCbk/1IoiP0fQvtk8yNV cjbu6tpIs4PAKmWRkJZf3VHx+r9KpAK8LxDMMBLOhczKDY8Jw8sQSI9iuKc7WohCPjzMaz jkw7zYlS3PqSq4+4N/C3JrxrNyKdN3I= Received: by mail-yb1-f181.google.com with SMTP id i6so2303082ybu.8 for ; Wed, 01 Mar 2023 18:22:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1677723725; 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=icYcAz4iENgGguq1MUlInM5/6GsRcXFU+8O5VO7eInA=; b=ICNzManCzUgms4+COGza4gk5YsyseuO5Ijt4EWhpqNEDkAg12yxO+M+x6EF7wlGyGp 18xfcjTQdZvnANZNl2A9rF7rCOHTU3O7UgOEldBj8JFxYXSdYiuqfdORdbYK3a8OzBha GPx1R+762t651JyT8Cj6YRDfJYCZzRhsZnsEISTad9RtLN+lwUYObGJty8p+v5C9AyGP 3XXAHVdDVphOLPBe2/6syAoOKCOBT/gqoC22awkzHgd0AJ3EE9WzeagQuz79d2V/uPYP 8Lqoil99Y13JGIIeKOkn5jKR1Pgy1Y4lYmhZVpRrJLR83i3rnovCLcQAjwV4uywIdJzG i4rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677723725; 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=icYcAz4iENgGguq1MUlInM5/6GsRcXFU+8O5VO7eInA=; b=CHeCDp9HYAZBo2qLYXrs8bEgVg7iTUkE5Fi7xpFw0CSrYiee4UYjr/ol86OVlLwal6 V0UjxZ5AE8RdpT7HBXfuBQTYUF97DzsmDqHsFpSFfXtEWXYirukbjPtyWrFq6k6eM6H7 t6Eu2ezodLvUbB4qCwMkpEZHVnlo3R3YZ5ZN3YX/k6l1b0+pf0ehW2K08Dyi+6jWxHXy zRG3PTK301mtJ1/u4XIgj3R9pGTGap7U5EsxD6oD2eMckFu1BguWM0jFwc3NKptqnnsQ ZmgdHskwAhq9nROKGBgMwz9YjZVGtNL/42OulW6POMLs3marfplIABftwOQM2AAs1tvL jCQg== X-Gm-Message-State: AO0yUKUSSLVIlcFJxF1/Vk+78GwnSndN0ANb73JBUEE5OgS1duKtnPOJ 3NhpVgUw1zWkuNAc7QAEdOkLjzk5yjVIbbgO40DOzg== X-Google-Smtp-Source: AK7set8f8UCPLp9V1R6/ru3EOI4J1mkBQgV1T32GNF0OvprkrFWWd8Ter81Ipe29QBKiksN2yO0CRLf6M0naPga3SGQ= X-Received: by 2002:a25:aa03:0:b0:a06:538f:265f with SMTP id s3-20020a25aa03000000b00a06538f265fmr407354ybi.4.1677723724623; Wed, 01 Mar 2023 18:22:04 -0800 (PST) MIME-Version: 1.0 References: <20230227173632.3292573-1-surenb@google.com> <20230227173632.3292573-19-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 1 Mar 2023 18:21:53 -0800 Message-ID: Subject: Re: [PATCH v4 18/33] mm: write-lock VMAs before removing them from VMA tree To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: akpm@linux-foundation.org, michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mgorman@techsingularity.net, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, peterz@infradead.org, ldufour@linux.ibm.com, paulmck@kernel.org, mingo@redhat.com, will@kernel.org, luto@kernel.org, songliubraving@fb.com, peterx@redhat.com, david@redhat.com, dhowells@redhat.com, hughd@google.com, bigeasy@linutronix.de, kent.overstreet@linux.dev, punit.agrawal@bytedance.com, lstoakes@gmail.com, peterjung1337@gmail.com, rientjes@google.com, chriscli@google.com, axelrasmussen@google.com, joelaf@google.com, minchan@google.com, rppt@kernel.org, jannh@google.com, shakeelb@google.com, tatashin@google.com, edumazet@google.com, gthelen@google.com, gurua@google.com, arjunroy@google.com, soheil@google.com, leewalsh@google.com, posk@google.com, michalechner92@googlemail.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: B2A98100011 X-Stat-Signature: b6etjeb8u66k4c64uksnkd1p3doam6g1 X-Rspam-User: X-HE-Tag: 1677723725-773195 X-HE-Meta: U2FsdGVkX1+RuArsFW2VoeW2VrGmOnxRz173RjilGiHaAKqCY/2NVxV14PwRMofKZdPhQ9D66SAXm/9BiCtsmkBvV80Q82JSAEmv7yjrH8oJzTfS5SwZmv3x/6RENvTM+L84TbmYliRLCRjq26/jTKnTv2a1Qg+2/fsX9PuPBd+6IVps0WMeu4gnjgr/bC6T4SqEiSh+uxDJBDL48UigzyC54z3EeQbvemZnS24tWi/q4aC0P7zZyhiXbQl2DLue8DkjSes0zook0LWas+LyDrsrSY65SJZudiSdInXTtZM0BHOuVenuVEn+KoLNy7+1b3XEzlY8tEIbMP56I2Ge9nbORRyepQzL2iErfytYo6oXoFjDIGj48Ak1Ux8aNS4933vWpzgxfjAE6DdhX3kkZ1olc8eMhVYB599cpFtmm/BLGynVjVvwCdRCm7R9LP7rJccRCMSp4mFTSemyHgxQTXkGffDkZkNy26fL4SgHBugi9JeDEN/BDDKvbzmoiYsdMQMVvgiRVBDHyrmF6tobi7tLEKZS4Bn9mTzkRYbxH3Eg7v7EgxxhwA9C2InZaFt1lg9qGhspWmf9zk7ATjPO7SlZCNFIkX/5/4hVOgg13ISSsudCDI+lggzykOonAnT007q45mLfGzYHboRnPbfJMqM5k/9jZqAXWq8lRTa0R2jzLwjoKeExGQPCudJcSzkOpv0HXjf20QzEa9PZEbgEjntdRlmrxGZZ6+Xjw+wnM0ZA+w8KLRNCPR5bJI3jQDxOs1gEHeEqscCcUQJdxtxZiqMqUSttIvEBmujLHQj9L6XvLqcdvsaqbiVzVb4+8i743VHF11gz2QGEczDAUo2jcUBaoxX4B+bHkvuG9anAbueEPBOX/CRoHBP1QJdJNEGcVtRuD2zkzdjEZfV3sZcpPMVStu7VTw9PEfLi6wghEP8jzd9ESzRWyE3RoDLHa9BjxFrcC5pcgelYIOoLucl dpXx1Tnj 5sSRnk34dD66F9n0Xydw6+HIDGeROXRRzShEgMep5JI0sS56wgZc9wQkwHtu0oz076vLyj3wQJMN5d11bEWyFOjJoQMNuuVzZkUlTnLeaJMTxad1ymLCtvnNQGlk0gAlntnxKswtAlqPBQzT11Gkx33Wq4Z2C94lNEWTlxKp241iK5h41mOJXqoYXNG9oikzqzJBiZtG/vx+rgHBwYEZjpL+f2BR8jba2U6beSTMGbdHx03Yyi1e+CzF7Bqd7ff+/vVDOWCxURD54h7cutB3UE94LS7vg8ZgSsp09GLmo+ppaCBOORFUdXI3EVt+yGbZhqZDPXdaRYodaTa5aNS8CYfLHMOSdC45MwvzrOjjkHK94gxr2M7uf7Y5gimIHb4gbfjc6YK23sjjfyIxl8HVF25BuDm1EER8clCM2 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 Wed, Mar 1, 2023 at 4:54 PM Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote: > > On Wed, Mar 01, 2023 at 10:42:48AM -0800, Suren Baghdasaryan wrote: > > On Wed, Mar 1, 2023 at 10:34=E2=80=AFAM Suren Baghdasaryan wrote: > > > > > > On Tue, Feb 28, 2023 at 11:57=E2=80=AFPM Hyeonggon Yoo <42.hyeyoo@gma= il.com> wrote: > > > > > > > > On Wed, Mar 01, 2023 at 07:43:33AM +0000, Hyeonggon Yoo wrote: > > > > > On Mon, Feb 27, 2023 at 09:36:17AM -0800, Suren Baghdasaryan wrot= e: > > > > > > Write-locking VMAs before isolating them ensures that page faul= t > > > > > > handlers don't operate on isolated VMAs. > > > > > > > > > > > > Signed-off-by: Suren Baghdasaryan > > > > > > --- > > > > > > mm/mmap.c | 1 + > > > > > > mm/nommu.c | 5 +++++ > > > > > > 2 files changed, 6 insertions(+) > > > > > > > > > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > > > > > index 1f42b9a52b9b..f7ed357056c4 100644 > > > > > > --- a/mm/mmap.c > > > > > > +++ b/mm/mmap.c > > > > > > @@ -2255,6 +2255,7 @@ int split_vma(struct vma_iterator *vmi, s= truct vm_area_struct *vma, > > > > > > static inline int munmap_sidetree(struct vm_area_struct *vma, > > > > > > struct ma_state *mas_detach) > > > > > > { > > > > > > + vma_start_write(vma); > > > > > > mas_set_range(mas_detach, vma->vm_start, vma->vm_end - 1); > > > > > > > > > > I may be missing something, but have few questions: > > > > > > > > > > 1) Why does a writer need to both write-lock a VMA and mark= the VMA detached > > > > > when unmapping it, isn't it enough to just only write-lo= ck a VMA? > > > > > > We need to mark the VMA detached to avoid handling page fault in a > > > detached VMA. The possible scenario is: > > > > > > lock_vma_under_rcu > > > vma =3D mas_walk(&mas) > > > munmap_sidetr= ee > > > vma_start_w= rite(vma) > > > > > > mas_store_gfp() // remove VMA from the tree > > > vma_end_wri= te_all() > > > vma_start_read(vma) > > > // we locked the VMA but it is not part of the tree anymore. > > > > > > So, marking the VMA locked before vma_end_write_all() and checking > > > > Sorry, I should have said "marking the VMA *detached* before > > vma_end_write_all() and checking vma->detached after vma_start_read() > > helps us avoid handling faults in the detached VMA." > > > > > vma->detached after vma_start_read() helps us avoid handling faults i= n > > > the detached VMA. > > Thank you for explanation, that makes sense! > > By the way, if there are no 32bit users of Per-VMA lock (are there?), > "detached" bool could be a VMA flag (i.e. making it depend on 64BIT > and selecting ARCH_USES_HIGH_VMA_FLAGS) Yeah, I thought about it but didn't want to make assumptions about potential users just yet. Besides, I heard there are attempts to make vm_flags to be always 64-bit (I think Matthew mentioned that to me once). If that happens, we won't need any dependencies here. Either way, this conversion into a flag can be done as an additional optimization later on. I prefer to keep the main patchset as simple as possible for now. Thanks, Suren. > > Thanks, > Hyeonggon > > -- > To unsubscribe from this group and stop receiving emails from it, send an= email to kernel-team+unsubscribe@android.com. >