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 ED991C678D4 for ; Thu, 2 Mar 2023 00:54:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 517006B0071; Wed, 1 Mar 2023 19:54:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 49F5F6B0073; Wed, 1 Mar 2023 19:54:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 319226B0074; Wed, 1 Mar 2023 19:54:06 -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 20DD06B0071 for ; Wed, 1 Mar 2023 19:54:06 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E9E2340E7B for ; Thu, 2 Mar 2023 00:54:05 +0000 (UTC) X-FDA: 80522136450.01.B3620EF Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by imf07.hostedemail.com (Postfix) with ESMTP id 0F31540019 for ; Thu, 2 Mar 2023 00:54:03 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=dIuwnaIQ; spf=pass (imf07.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.178 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677718444; 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=1p7gLBnjTY2NzqqDfZ3+sK3ELM0whxNqoGWgGrbWZok=; b=S9QnvgvZ3XsRPUZe5BGOdanqKjSndr9QuYBLoVrfkXPyB8C3lCKjXkNZR43t4l6JCOFXSs U1rshjXbX6JxKRkgDaoYuP8PwjHZ3lZjsUER2rmes+WYpd2uwzmWfn/+W9KDLwwnkPewlR E04M4ZnKiZnXxhwR5TyKQcwNLzAFJxo= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=dIuwnaIQ; spf=pass (imf07.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.178 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677718444; a=rsa-sha256; cv=none; b=RFO6B6jttZ7yUbxF8Z8uUg0JAFbjI3jdPH66hvjjKFkwlMsN+z1JQ/yThgvGBuT3oIpta4 /2g41sIW8+o1PdimoCljqWhgAPN9AQwZdqrNMZ0npBy19fF7hpnk0gL22k4eBOwl/QyhFw X2qMfqi6bAqMmN0DcecFNqnXn2Q5blQ= Received: by mail-pl1-f178.google.com with SMTP id z2so15880873plf.12 for ; Wed, 01 Mar 2023 16:54:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=1p7gLBnjTY2NzqqDfZ3+sK3ELM0whxNqoGWgGrbWZok=; b=dIuwnaIQ2bBUUz2optFpHImdgLTXLjc71Pyskqyty88uSV5WuiXl4EF6AzbQz/NvDA bnewBQ8MDcrZ3ZNu5L92lqAmIdJYxFkE39GdDnGIB1WAuljQTRNHcNkW6Ug1O76YUDIq ii9cc5JIQNsExXmUEy6NT3bGWAn0vrvp6IUyDQHQGe9STLpLDGrPNztuq+gJuPBVf1sW knhPQtyF1OhCU9vVlwi3oypfLyPDcxoNZW9OvJANM9vYeephCdst1w6i6OPbiK24p0Ye WpobOonjOm828sKMocXSeQ/i3h3VC8YHc62eF6VDSwVoPyhmf1FldFlcNVZEtveAyPgR b4eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1p7gLBnjTY2NzqqDfZ3+sK3ELM0whxNqoGWgGrbWZok=; b=5uq2gVQyZb51uRbN6NeNHbHopVIUJsF1qLOzxP7Zi0JMYLTA5NnyDvaRj1pffIFPGp S15Mh5y0B8DI/4s4DnzVZZXFz46X07XAnT9om6VkE5QTSWAXcUgElKrL025kxU00CTnT SfVPFrby7UIIv6nSNAYia59K+zOF6/ZgFu6rip26ZirByIoCYVVm6gEmZNRFOyE2uTSh Udr8INkWlBUPivknl7MgTvuSNr+4FsqVSc4EryqYVPaBilwj8+npGbQdvg5xpu3qudM4 I7YTM6r+CwqlJi45qMlRqL4EtYjolkRxdx/If7SON4rvjkJDeBWIALh41VO38wtCh/o7 xEtQ== X-Gm-Message-State: AO0yUKUGU2cpHtvvQXISqYdXMSu8VJLuhgMVtRfkhB2V4+rfT4GQIgpG 82SolIQDh0rWeyVH5EryGcc= X-Google-Smtp-Source: AK7set9xYz9SPyOCt7tLgYDSF/C0yAQqSuW6dLV1Fq6uvubFXXpgs+hx2VuoCASTSYarsrrYwT4C/g== X-Received: by 2002:a17:902:e886:b0:19a:ad2f:2df9 with SMTP id w6-20020a170902e88600b0019aad2f2df9mr10366596plg.55.1677718442825; Wed, 01 Mar 2023 16:54:02 -0800 (PST) Received: from localhost ([2400:8902::f03c:93ff:fe27:642a]) by smtp.gmail.com with ESMTPSA id a11-20020a170902900b00b0019a9637b2d3sm8999040plp.279.2023.03.01.16.53.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Mar 2023 16:54:01 -0800 (PST) Date: Thu, 2 Mar 2023 00:53:45 +0000 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Suren Baghdasaryan 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 Subject: Re: [PATCH v4 18/33] mm: write-lock VMAs before removing them from VMA tree Message-ID: References: <20230227173632.3292573-1-surenb@google.com> <20230227173632.3292573-19-surenb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 0F31540019 X-Rspam-User: X-Stat-Signature: udpyfytgc7mm61wqidepftx55dyjnapf X-HE-Tag: 1677718443-855962 X-HE-Meta: U2FsdGVkX19S676xVuVg+zB2UnHptuG5gYAnrpdTfsdADEOJTByCfSEFWTHn1jXYise75ENX7lmgs409fTiQFKsoU1xgnQM44ED1op1QfoUNK+L5WYt3Lw7GRD+7nOkr942vbjWpGy/Cd0O+WOC5jpfjBWmYmx9ssZREr0UzxNX/52U+OgNqgZqM5QmAfVigXmFMITx3opO+1rtFM5HyVEKfpyud6S1Nfrvj8dqc+HPbO5LhBQHhg6Bly8Y1LPtpytcL5YpSYltt1yqPOosyDrzZqGprgEVVx6xhfZU0Teg0eMmkYd2hUclBV8U3qYTiIOEL+LLNWs6zqhTH8hHTIg8M4voYobTly9AHKeb5/fe9SOwILxeyQf1t9RrC5/IiO1yQEe5sytosWe8OLa5qpxIWPZS8XYwJe6rh/l0tJZRPSGI6a9ev2fwy6k3x8+JRJxodFpB+hTs6RFrFmLIxOGDmsiyTgr/x6lcbnyzyQnd7J50mP7O0seEswj5FpXJakxlMViCWJMAPnkNSg6hTmSCQKtzdriTf4HOYouJAKkvGkXV1ua40LwD5sjMCFMWMbaE4BeFlRsCHX2ugOK0ESm66c0COj3iq86Ct1ApsyFRf+hduhHDsvmvB4Js0pb2+uFawu9ChhfrbVHcI04ZiOZAXsRGpKdDRqLta2x3/9lhZ6pzV3AqozKxHGBpceOkJD5UfNzl5i7XMRMXj12JnJlJoXh8hotvX1X6J8N8tjfwD8f8aNXn4UKwqKIybcs9E/jpl0kmyQIClJo14CeIls9lort7Bg+1JbvsUPbn57Vil5Xr36yJTkp16fHWKkuyhaP10BMbUJat0MQ5S121mlFjuQhc+pHU8zVuNNmVuBD1Sc8eNA6vO01hvIASqCPN5cCMQig/9ObrNQFdBOepDGG6iqIAxtvomaACt3qfdCFO3zmChETEIOdTWdtvoahsHQq4dN5Avn+az3Es+X9p YcKPaiQh WiFG9+jGfG6MjCWF+3nYimk2z4suGmIiCujDPbAWzHaucU1czKEB4verRyf52cVw+BYBdkLgPV9219WjatQzq114pXomqr5pTIntMTaCtGgH3LoGu2R3kKFfJjQZo15XrATUv1UkKMHM7+13SendhXdOFSaCgstP8LzbOaz0szIX4VIHGKgI3WZBckuCbSIac7jIRtQpXk5/RFZlIAkp/jKFGDzdk1n5w5GviHE+1Smg8Nb2AdV+f8CI6FyPWffiu70Yte4eSqFUCTiWMqrZ7BYHmF45Cewn8SsVtdyvQkdPf+bqXuC5zCvC2TZQ3rhmxhn2O5Srgdjs/ZjwooEFwGhDtlroB/Vd7xxhggGnTbd9aXj0aIlRGQJ0dXNXzoHH2c6OlVWWtpw6NZaFotUWXOOYaDIXmFUP6PthyZj3f2cauxfsvWlgYLy12em2oOj4IgRkBk3Y26svD+mBNBIzeUkqcLsX9Tvr5/7Nwkm4FzknUglxKSt1eW+Q3Al0C5oReTTXD 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 01, 2023 at 10:42:48AM -0800, Suren Baghdasaryan wrote: > On Wed, Mar 1, 2023 at 10:34 AM Suren Baghdasaryan wrote: > > > > On Tue, Feb 28, 2023 at 11:57 PM Hyeonggon Yoo <42.hyeyoo@gmail.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 wrote: > > > > > Write-locking VMAs before isolating them ensures that page fault > > > > > 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, struct 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-lock 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 = mas_walk(&mas) > > munmap_sidetree > > vma_start_write(vma) > > > > mas_store_gfp() // remove VMA from the tree > > vma_end_write_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 in > > 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) Thanks, Hyeonggon