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 7D740ECAAD5 for ; Fri, 9 Sep 2022 16:25:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DBB586B0071; Fri, 9 Sep 2022 12:25:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D6A2A6B0072; Fri, 9 Sep 2022 12:25:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C33838D0001; Fri, 9 Sep 2022 12:25:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id B2A646B0071 for ; Fri, 9 Sep 2022 12:25:20 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 8722A1C6B07 for ; Fri, 9 Sep 2022 16:25:20 +0000 (UTC) X-FDA: 79893072000.24.43850CC Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com [209.85.219.176]) by imf09.hostedemail.com (Postfix) with ESMTP id 38CA414008E for ; Fri, 9 Sep 2022 16:25:20 +0000 (UTC) Received: by mail-yb1-f176.google.com with SMTP id t184so3453509yba.4 for ; Fri, 09 Sep 2022 09:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date; bh=miU+viOw7qa7tyRJ4Or3oAz5OewEcwcrhnBCcmhlJME=; b=c1ixqNT2Wb/tj4p47082iOqXbPydTfDCRlcpOnTU4AJzbxK8Qtae/w4e4czAPV2SvK +6I+nnYA53fBK6dM4Z6T8Op2DAgoc7La8FTLRFbE7tahS+Jj+v+fPRn8bWYANC7cJSnc zwuMzJHWo/9ii2BElyg3HNv9L1YrpNYTz83RkonKXvvQXpUPIus8IRdbxcgyFHbI85xm HyIl5BlEIVYQx6rYt2HrwVLsTpmF8TMDAB20Am6za25Qy6nd0QH1gO+PAHsqFkWSRj4W gu83JTU963AgC40cDTWMymlAVMPH/3Y8qL+wvX3QxdPBwiUUSdUBphZcJwpnM0F/1CWs nSQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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; bh=miU+viOw7qa7tyRJ4Or3oAz5OewEcwcrhnBCcmhlJME=; b=YLu5VIQUFC+Bo1uKfiQs45tf3DI5EsCvSlrYmcLy+swqWo/i12RSwixOBzsrAIYmFW r2JplzVBcZeJB5AEZGWsrKqyKYdlZ5E00pjBD6cL6r0NpboVdSbID4vCuPhduEHcPV/Q A6BIya1oe+N8mQxjdS9y8Sd+vr3EhQ7zWJedQ4SW/UkRJKe+nM3+WxsMuEVbNaHpP4ra D0AWt2x9WuTlixd2XuAPmF5mD4T6DCOX72OUZ9y7bvLkkBFFXi+86hJUl0ryxbtRehHa UArYwPGZbQOLrtv2/UqOYIWx7X76aDysXGSSLJxx/g4jbYENgmaQRvvgbmUouwd+NVQ4 0pIg== X-Gm-Message-State: ACgBeo0UH3/O6vvpCwID2VqqVTXT2aheuVj2f2nv3SG5Axm1uu+cYNh8 bcFk6fo/XRziw00wa+XJJ9xkR3TQwFtk/owPEoCSJA== X-Google-Smtp-Source: AA6agR57llNlr+vc/ZVT6e21cf6KHtYpIX6piWQlP7J6Ta4z5TBzfSbQtMPHvfFUwcQ/ozpxKb9IwDD+Gqf8hXDfIC4= X-Received: by 2002:a25:424a:0:b0:6a9:2954:87fd with SMTP id p71-20020a25424a000000b006a9295487fdmr12134434yba.340.1662740719262; Fri, 09 Sep 2022 09:25:19 -0700 (PDT) MIME-Version: 1.0 References: <20220901173516.702122-1-surenb@google.com> <20220901173516.702122-16-surenb@google.com> <83a36761-2045-3f46-3088-a751c5263b81@linux.ibm.com> In-Reply-To: <83a36761-2045-3f46-3088-a751c5263b81@linux.ibm.com> From: Suren Baghdasaryan Date: Fri, 9 Sep 2022 09:25:08 -0700 Message-ID: Subject: Re: [RFC PATCH RESEND 15/28] mm/mmap: mark adjacent VMAs as locked if they can grow into unmapped area To: Laurent Dufour Cc: akpm@linux-foundation.org, michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mgorman@suse.de, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, peterz@infradead.org, laurent.dufour@fr.ibm.com, paulmck@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, rientjes@google.com, axelrasmussen@google.com, joelaf@google.com, minchan@google.com, kernel-team@android.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=c1ixqNT2; spf=pass (imf09.hostedemail.com: domain of surenb@google.com designates 209.85.219.176 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=1662740720; a=rsa-sha256; cv=none; b=eFsz0fUNgVXcxHHue+Fudjbibr/0M/KjN8GxWje/CA3KKy5p6ugGQO/ewFWgeKKLMCitss pGlVvpNajiKqtcrnxIHgfeK+MWUB5CJHIRi3lsAXvUxeMu6yFJp+uMl91bVhgX1s0yssHf fH2+I+idx8houhRzjAzV/KiskcZbIVM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662740720; 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=miU+viOw7qa7tyRJ4Or3oAz5OewEcwcrhnBCcmhlJME=; b=ycx1C6U4H1gkkZI/zywVrzkyGKHKVQcclpl/AtailICPN0LPf+HBI33z5M9ytlXn7G/awl boE0rK7MC9Fwbdw7QCQGCW+VMIXRJ7bVKbLr+J5U32VirJZWid6GybQUGqHSzz7XAc7eD0 f6ci1SDEDkuDqu6W2g4Lk74/azoeh28= X-Stat-Signature: x98kfb7y9kowouw1fa6k3ybfi9e1szs4 X-Rspam-User: Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=c1ixqNT2; spf=pass (imf09.hostedemail.com: domain of surenb@google.com designates 209.85.219.176 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 38CA414008E X-HE-Tag: 1662740720-690737 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000025, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Sep 9, 2022 at 6:43 AM Laurent Dufour wrote= : > > Le 01/09/2022 =C3=A0 19:35, Suren Baghdasaryan a =C3=A9crit : > > While unmapping VMAs, adjacent VMAs might be able to grow into the area > > being unmapped. In such cases mark adjacent VMAs as locked to prevent > > this growth. > > > > Signed-off-by: Suren Baghdasaryan > > --- > > mm/mmap.c | 8 ++++++-- > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > index b0d78bdc0de0..b31cc97c2803 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -2680,10 +2680,14 @@ detach_vmas_to_be_unmapped(struct mm_struct *mm= , struct vm_area_struct *vma, > > * VM_GROWSUP VMA. Such VMAs can change their size under > > * down_read(mmap_lock) and collide with the VMA we are about to = unmap. > > */ > > - if (vma && (vma->vm_flags & VM_GROWSDOWN)) > > + if (vma && (vma->vm_flags & VM_GROWSDOWN)) { > > + vma_mark_locked(vma); > > return false; > > - if (prev && (prev->vm_flags & VM_GROWSUP)) > > + } > > + if (prev && (prev->vm_flags & VM_GROWSUP)) { > > + vma_mark_locked(prev); > > return false; > > + } > > return true; > > } > > > > That looks right to be. > > But, in addition to that, like the previous patch, all the VMAs to be > detached from the tree in the loop above, should be marked locked just > before calling vm_rb_erase(). The following call chain already locks the VMA being isolated: vma_rb_erase->vma_rb_erase_ignore->__vma_rb_erase->vma_mark_locked