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 CB092C6FA9D for ; Wed, 1 Mar 2023 18:35:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4F9CC6B0071; Wed, 1 Mar 2023 13:35:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4A9C86B0072; Wed, 1 Mar 2023 13:35:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3991F6B0073; Wed, 1 Mar 2023 13:35:04 -0500 (EST) 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 297D96B0071 for ; Wed, 1 Mar 2023 13:35:04 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id F3785AB450 for ; Wed, 1 Mar 2023 18:35:03 +0000 (UTC) X-FDA: 80521181286.09.64C0DA5 Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by imf29.hostedemail.com (Postfix) with ESMTP id 0D3B712001B for ; Wed, 1 Mar 2023 18:35:00 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=sMqxKmMP; spf=pass (imf29.hostedemail.com: domain of surenb@google.com designates 209.85.219.178 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=1677695701; 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=sf6UrJ/lIWn1fjlxCohn27ZSd8Q0TfJriVXXcU5qWAE=; b=NTmfsDjL1Rc8stnJqw8iQaNobH6ZlSCqV0I76uLjw3swgA+2mRyPQkl9MMBCodZ0Ky3JPk SHngzdguHOUNoyoj2VV0Oy0MyOPhbTLA/OnDoH1l8LmWPJkEG8xlTfW8mPZmMxXBNJGGw2 cqtTLSmsfmioRPDWReXj6jaoTKTJLJk= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=sMqxKmMP; spf=pass (imf29.hostedemail.com: domain of surenb@google.com designates 209.85.219.178 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=1677695701; a=rsa-sha256; cv=none; b=VoVynjNDMmnrDq/Grvq4g2nO24U+iZS3wT8p86kX9rVpcktcr8TQmi7jqXivwdunprkmrT UZCeo3fZimBpB+gOswyS9ZG4TwRNKLSY8A90aQA2Ofp7dQJicIqzVNCc2ADmToUrQF1cb6 zO8JJzGlLz2w2Ccu5a7o43W0KS97IBE= Received: by mail-yb1-f178.google.com with SMTP id t39so1312317ybi.3 for ; Wed, 01 Mar 2023 10:35:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1677695700; 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=sf6UrJ/lIWn1fjlxCohn27ZSd8Q0TfJriVXXcU5qWAE=; b=sMqxKmMPWADCyZTd0B+sCUFvSsU0xwpbUR9hz5KDANoBtXhUgELy2PB9S6CmdcPdLB 9DuY263Lca20XWKvkKm/VeE8UXAxbFZ7UbMDjj/GdF33ace4U+qR3SuprdJIyGlg0kh4 8ZY6tqKyRCrC4qSvVBH79BPeROQDCdXsUZHeJsRV9J+lzs8QF19Sft8unbL3LhV+NyMQ rULPzaHubsvYpBIvwRVqUZqOtQrYMTbpInxvEOTwI44gseylO/JwJ1XsAHZVMuGFZ8ce lLm3lv4Ir2Kuf2SdE943w0lXUD4jHslpCCCCxHMHmN15vxuLPQ0RJvPoRPshybRhAX6v 429Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677695700; 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=sf6UrJ/lIWn1fjlxCohn27ZSd8Q0TfJriVXXcU5qWAE=; b=QrqGVl8HiN4pcKQy0RdfSEvmV4upZBAIZABBaswx25wOTAnPpmZLwSkLF5XJcaL/Y/ 4LAOgM66bBHl+Q8PsqGuele6PH8ezELsM6ImT2AI7s/+Kz4eDzfjs/+qu0DVC3U2LYSj YNFncj84hN9JOOhrdh4lDS0CS7VGJisJLh/j1I9b/B0GaFkwZmkua09c+wa4PaKq92x9 ZMfdLPdAyBA69T/QPdLmrncLt/S/HockLKLOPv31izQE3/DATif4gAuXkTQ8+PhGTL7N WGsoaeZlpmChXMO8yOdixivp2jU91j/jl1Y9s+UcMPLZWhOcTHkvWAoq+wVW/gUh2W5l pqcw== X-Gm-Message-State: AO0yUKXGFplWt2D/bpP6o1usKvT1Dg52bs1TZw1dHx61xPBYe9qHR+xV Q1taz/5XRbxwvD1212qTC21x07vevdS7kM/YZVrWLg== X-Google-Smtp-Source: AK7set/vwIRLhIQIPE3GkkxKkfmhP1CRU34HRxLzx1/Rma4BTfbR6X5PIRaaOJxNUaM1YhGtm7HsF2b9hYcFbnNAeaU= X-Received: by 2002:a25:9704:0:b0:a30:38fb:a2e4 with SMTP id d4-20020a259704000000b00a3038fba2e4mr3269439ybo.6.1677695699906; Wed, 01 Mar 2023 10:34:59 -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 10:34:48 -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-Stat-Signature: cq3wf88xzjk1gjaejt94ksauf3kdx7jq X-Rspam-User: X-Rspamd-Queue-Id: 0D3B712001B X-Rspamd-Server: rspam06 X-HE-Tag: 1677695700-416082 X-HE-Meta: U2FsdGVkX1/Y5lSpBgnlmStRx3hMDx0DgpAOtwZHCksdSeI7OD99OTvbVAix1abBHIaqzU3Pdi01QrTgLXtuBXjuA7AsNKNJ25ZNlC+ofHCBvOioXcM5sqgeG8CcwuNqdmrvQPeESmQVc5NCc/ANl0qnC2wJjKWzNHHPmpVfs4JIdTbzYrwPyRSw4BF4kjWAcB4WjNVmVxKT0UjwieCVyDlAKQkJnihgFEZylWnxejTUjF1AaPJ4Q7Zs+B96nv8Xrsidhv224N+mMD6Eu6VT13NytdvJ2i4Y9UCOb30mQ+SQu6nhHgD+oIjP+lJAyucXFv4IaHsIHUnI/JjORf0J2vQrP8U+la5c1dgy3xmdxgKnvOwNPM87euGPw++giy/Ja3X2sVG6QlsXc3CYMKHqxDhsM24gY03MMowzMN5qpMWxzSLatxS7phAunYodH/Sc/pFS6Sylkjgtt+qMdM2WWKUp7oocLafILC3tHzs6jlTVpG+xErWbGrHANfUchW/ODFMSp7kuQjDlYfUTdRvOc0Q+qSz8QObjtR0GSVlZUCzne1r3n+S0EuWgHANVIihtZJzgIGf/f8a6lcDlS5eLVxVbFYOIgHw4gfoy16Id9LwY+OmYa705aAQz7vly9IVRIlGpOreMlg6unfAkFnXEUjQWCOSrWLtMcV3cLeKlnOxbUn8Y+pnDDSctd/Gp74egZoHCDTw85+4yAKknvqQzVj22vFLB+H3NP6bIZfsrixIPJY5/9mUfeMXZAMHf9BRipCFdnz1P4jybaLmH5KOkm8V7nKHev8SdZ6N+c50mPN/rcQs626dZs02sX5KyUBgIV4Gtft4W//jEW4nQZyzSldqs7c2/gaz0COm2b7DA+yrZQV6c8+/BU5Y8jSkts06zBH4qTP+NNHAyqTyL6++qPa482PYIZMez0lKX+9SbUy67OpaTipvgF3ALbk6t8l3/k+7agT6MSzT/oFS2yXU g5zxRKcp x5x+ua/lOxBRrJwoqZVaSdB1ni+3QlWwiWJRWkU0ZHr1hkcEDouIMmgoD44FzRSF1wIoJax2hzAWHYHNy2mVh+VNqqvGF7kjW2Xqe67XHhcItEk4EDlORH49tUAOpzTzLIajmCMEKpDaw/7YycKaNDag1qT/q274v+vgPImMKN9gVJ+yGArpM/I7NzPWpRZAx/3IBJuabeYpP0Mvqi6BJ35xvm6w8kJFkw00bifkGx0UoFtiZ3Ask1j797tzq2ZMUp8zfBwlrXieGpYz9jS/u4V5GUutWEfYunxioQFMWlQ2gn3/9ef9b6dUN8RuZi9+U9Om8pS1NOiCk65X9YcQu9dGj93QukYXBvid+LCgrojKca8bv9waYt9BHhDKTFmLd/24McPLtCOLz6cRVNT4yM6IN3w== 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 Tue, Feb 28, 2023 at 11:57=E2=80=AFPM 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 V= MA detached > > when unmapping it, isn't it enough to just only write-lock a V= MA? 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_sidetree vma_start_write(v= ma) 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 vma->detached after vma_start_read() helps us avoid handling faults in the detached VMA. > > > > 2) as VMAs that are going to be removed are already locked in vma= _prepare(), > > so I think this hunk could be dropped? > > After sending this just realized that I did not consider simple munmap ca= se :) > But I still think 1) and 3) are valid question. > > > > > > if (mas_store_gfp(mas_detach, vma, GFP_KERNEL)) > > > return -ENOMEM; > > > diff --git a/mm/nommu.c b/mm/nommu.c > > > index 57ba243c6a37..2ab162d773e2 100644 > > > --- a/mm/nommu.c > > > +++ b/mm/nommu.c > > > @@ -588,6 +588,7 @@ static int delete_vma_from_mm(struct vm_area_stru= ct *vma) > > > current->pid); > > > return -ENOMEM; > > > } > > > + vma_start_write(vma); > > > cleanup_vma_from_mm(vma); > > > > 3) I think this hunk could be dropped as Per-VMA lock depends on = MMU anyway. Ah, yes, you are right. We can safely remove the changes in nommu.c Andrew, should I post a fixup or you can make the removal directly in mm-unstable? Thanks, Suren. > > > > Thanks, > > Hyeonggon > > > > > > > > /* remove from the MM's tree and list */ > > > @@ -1519,6 +1520,10 @@ void exit_mmap(struct mm_struct *mm) > > > */ > > > mmap_write_lock(mm); > > > for_each_vma(vmi, vma) { > > > + /* > > > + * No need to lock VMA because this is the only mm user a= nd no > > > + * page fault handled can race with it. > > > + */ > > > cleanup_vma_from_mm(vma); > > > delete_vma(mm, vma); > > > cond_resched(); > > > -- > > > 2.39.2.722.g9855ee24e9-goog > > > > > > > > > > -- > To unsubscribe from this group and stop receiving emails from it, send an= email to kernel-team+unsubscribe@android.com. >