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 1B231C636D7 for ; Thu, 16 Feb 2023 19:36:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 85CAC6B0071; Thu, 16 Feb 2023 14:36:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 80DA26B0072; Thu, 16 Feb 2023 14:36:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D5476B0073; Thu, 16 Feb 2023 14:36:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 5B8B46B0071 for ; Thu, 16 Feb 2023 14:36:41 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 21C711408E8 for ; Thu, 16 Feb 2023 19:36:41 +0000 (UTC) X-FDA: 80474162202.24.AE844B2 Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) by imf29.hostedemail.com (Postfix) with ESMTP id F1A62120019 for ; Thu, 16 Feb 2023 19:36:36 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ofef3CWO; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf29.hostedemail.com: domain of surenb@google.com designates 209.85.219.173 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676576197; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=7kPbmP0HEcZpXUsWhibQteNAlMcCYqcrNbxA2g4JE/A=; b=AsXN+WXGASn9XseHucGgKiAQpn5t/Ck02KJ7+6OeFkixgzr06/PxxXKeh0Z7IHGNjKEPVe JRUdK6CmXITHTDZtXD24YGvtRw7nTtwyI2caJseuO1JgxfREXEcMI+z0IwVcoXes1RXZN1 sEZOavD6fu9fU2hfQYcS2/RjneiW6zc= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ofef3CWO; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf29.hostedemail.com: domain of surenb@google.com designates 209.85.219.173 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676576197; a=rsa-sha256; cv=none; b=A0e8zyd1qdni4xE51f3GllxKvSx24M7I8N4Zbfn21GM9XBihX9Iyo0Ki1A+N/rvWgz4J6z XSVNz4EwHjLXNAH0vO4ykOhac1g1sNPy4EdBFtyp7bao2dg9tKs09kQHcMiuSS87SX4R3v GtM8rLsDZ/N4i+PzOE/LN8OxkZcF38U= Received: by mail-yb1-f173.google.com with SMTP id b1so3463865ybn.2 for ; Thu, 16 Feb 2023 11:36:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=7kPbmP0HEcZpXUsWhibQteNAlMcCYqcrNbxA2g4JE/A=; b=ofef3CWOUeTxZZ+PIIwVk8SzvwcsVuW68YnGdTw0sJZfvvLZRwG1rTv+k9fTx+zmY0 PE+VFGCtwaQeHc/Q7XMRjsyKtq5v6pfu2ev2sPQMb6UhIu61GUINkjK2pMfPtzeCkg5o 6Gjn60EBkfD/UVWNXjrWJZQIdGTPM/jNXjLbXL+SInNkzvFVogdETkZAoteauf6LPlI8 AgbAdlE0fAYulqZ1ET3yXlivnH8nosnvGQm5O+vqx8fc5mJNQMBxl19NpaII9TKyV+Lb 0ghtuwgUVAq0SlQaFPa0ikdsi4vcic/WEKbLdudqbreIUAad8DgTKMEozeVtakIWzbDz Eq+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=7kPbmP0HEcZpXUsWhibQteNAlMcCYqcrNbxA2g4JE/A=; b=3jY0oCSmYFdi5EqPl4Ta/p4X49Djok/pFsHHH1uCeIetwAQf0WHNDqsdvhXv2sLlvf oCru5fLKrRYR73yxhSJm75NT+IXaPeIqtvzRMO4lIpNKCrDXL7F4XrMe544oh5tExHlF PINeLxc4rWee6hkDrGzSQOe4pZEomZ5cN8C2BEjjEBTUcgHCV7YN1N11Cc+uKZfAAllt lxmS2z22Yj36AYUujYx3q1JGdmL+Aliq8mDvFLj0HS8jxBBfYoEmiUB5BwY3PjkStva4 syKs6VrmmBs0WzaJJmOjCgWDuib9gl3gSB/lq9hURFwrnD19CvxEiBHOq5DXsvIexnD2 drIA== X-Gm-Message-State: AO0yUKWOb1yiA2SAvzse1IUq2GLE1cUG479qczkkwGeXjHPJ8MKuVp2p R+tfInRXOeX0QEhQ53wfnv3VQfvdpreFCBfItU3kLA== X-Google-Smtp-Source: AK7set+RMcw3ZcSV3HGm+iFjEGJ0Lev4v85qKlq2LIi8Vsi9NpR/fhxseBWzeKpPsLOx+aOI+tOgrQwVizPu7Xy8HOQ= X-Received: by 2002:a25:9941:0:b0:90c:de27:7f15 with SMTP id n1-20020a259941000000b0090cde277f15mr873659ybo.428.1676576195831; Thu, 16 Feb 2023 11:36:35 -0800 (PST) MIME-Version: 1.0 References: <20230216051750.3125598-1-surenb@google.com> <20230216051750.3125598-22-surenb@google.com> <20230216153405.zo4l2lqpnc2agdzg@revolver> In-Reply-To: <20230216153405.zo4l2lqpnc2agdzg@revolver> From: Suren Baghdasaryan Date: Thu, 16 Feb 2023 11:36:24 -0800 Message-ID: Subject: Re: [PATCH v3 21/35] mm/mmap: write-lock adjacent VMAs if they can grow into unmapped area To: "Liam R. Howlett" , Suren Baghdasaryan , 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, 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" X-Rspamd-Queue-Id: F1A62120019 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: xbpxc19hwucegwd1774ejoeqf6xccr6g X-HE-Tag: 1676576196-976424 X-HE-Meta: U2FsdGVkX1/MHSS7RqESBtJ+FsIyU+ICo87RI2jt3hFyp0WfPcK+Y5M3pTSXk6P3JbbtOTeokFPfsW4nm/9L7FRyJAGik42rWzTGF7t/lOm8wGv9RPBBFi8KqzLQJlotiLRg3XBszk/ipSP8sgM9WdQZKvtQEIwdmfefUIDPzjxsOnUW+rqd0HcHw+RSUsFW0iJd8LSOBiqt1SzO1C4+b6LvCau0T/MgArPoi64X93kUriSVIuSdm+Hs737jAIhlZMB7fa/nhV5+Djl3NDDiD2mItLeeoEal2lW9Cib+Mq8SQJrct4ZM6lDoxQqXejRRuSN9RWzcLon5UrwxldWbd3Rr8S/QVJElwVCUKxqExXPVoLwIBMt3gCOG9A8jEcJ5X6azc4UobDXMorT4Q34TAdkmTlLTtKJugxKegQfmgLbbd4Jmzl29ZbGuxrDHf9yJYxzeKcyXcbzbm5E8aouwEyqKlXk8d0lDo+SokbF7QJ3XqJZjy3/pCx8ucRL3K8juilYPwcvoeUUGGNOBPS7Xz01m4vKA2oPLdlMfwklG3MoPbfY4N9pT0ZaDDEqAYUK8jVUHZG+9QTJ5lyq0NUq9IRAMSN3ml8LiKn0dufulaMnsK1UJNBbByAk98rA8jlUMe8WdC8e1AuRe4mm9nbrxZ/0m2S1hJb/+Lnp8ZgH+avKbJSfPqbRAA4BW70vO5wl6K1Ti1ru8DAs7FnV4n6EzpXm896maY+qqKowNjX4fDYexw3Oi4AgAZUWOA57NqpyMjNK4bnPxoIkV+GJ7NbC4JU0u+SM6CcM61hKx3G8n5jVktEBr+kgrENRgGmNzxAYjUGPWXzMOt3d+d0ZTh0AT0/gf/xxZq7lyrmpACeiaOkhv8ejH4vsGtysknHMd0KrVi1gQFYB+nb0hsD/3RprKkCPZGYovS0n9FVAvVjUskNxXuemfk92iCGvDB7KBbjondP4B/8PrAcIip2xKC4N ZyQVWlfi KDjF6NTWWlivF0rZwqCEyzjTwqAEPFjBjFEpSmbJdBni07SB+BxEmOyKKMrZq7LA6mQisE+aKOQyB26vZ+Ba3S5VTMsPLwSic49q+AZVIc776uc4gmSl9xWusrgQ4FR4d5BwcxwV3gkq6y+ws1FcNJAlF5EvMWgWwfYJ76vOwrlWjXAuGwdNd2CdD16plJiN/cY0I2ptaJibj1QOcIyXg90LpHwciBjKsRtXMhzamG1ML31yzYn5l75OOWSlnMqE41CDNy6EnU0agE32b39OfXuHoYsZmvbmsfxONTVuWRsUTEehlMyMn+beXcoAe046sk2Jr2TJhvOLhTYHhe1aletR76Q== 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, Feb 16, 2023 at 7:34 AM Liam R. Howlett wrote: > > > First, sorry I didn't see this before v3.. Feedback at any time is highly appreciated! > > * Suren Baghdasaryan [230216 00:18]: > > While unmapping VMAs, adjacent VMAs might be able to grow into the area > > being unmapped. In such cases write-lock adjacent VMAs to prevent this > > growth. > > > > Signed-off-by: Suren Baghdasaryan > > --- > > mm/mmap.c | 8 +++++--- > > 1 file changed, 5 insertions(+), 3 deletions(-) > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > index 118b2246bba9..00f8c5798936 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -2399,11 +2399,13 @@ do_vmi_align_munmap(struct vma_iterator *vmi, struct vm_area_struct *vma, > > * down_read(mmap_lock) and collide with the VMA we are about to unmap. > > */ > > if (downgrade) { > > - if (next && (next->vm_flags & VM_GROWSDOWN)) > > + if (next && (next->vm_flags & VM_GROWSDOWN)) { > > + vma_start_write(next); > > downgrade = false; > > If the mmap write lock is insufficient to protect us from next/prev > modifications then we need to move *most* of this block above the maple > tree write operation, otherwise we have a race here. When I say most, I > mean everything besides the call to mmap_write_downgrade() needs to be > moved. Which prior maple tree write operation are you referring to? I see __split_vma() and munmap_sidetree() which both already lock the VMAs they operate on, so page faults can't happen in those VMAs. > > If the mmap write lock is sufficient to protect us from next/prev > modifications then we don't need to write lock the vmas themselves. mmap write lock is not sufficient because with per-VMA locks we do not take mmap lock at all. > > I believe this is for expand_stack() protection, so I believe it's okay > to not vma write lock these vmas.. I don't think there are other areas > where we can modify the vmas without holding the mmap lock, but others > on the CC list please chime in if I've forgotten something. > > So, if I am correct, then you shouldn't lock next/prev and allow the > vma locking fault method on these vmas. This will work because > lock_vma_under_rcu() uses mas_walk() on the faulting address. That is, > your lock_vma_under_rcu() will fail to find anything that needs to be > grown and go back to mmap lock protection. As it is written today, the > vma locking fault handler will fail and we will wait for the mmap lock > to be released even when the vma isn't going to expand. So, let's consider a case when the next VMA is not being removed (so it was neither removed nor locked by munmap_sidetree()) and it is found by lock_vma_under_rcu() in the page fault handling path. Page fault handler can now expand it and push into the area we are unmapping in unmap_region(). That is the race I'm trying to prevent here by locking the next/prev VMAs which can be expanded before unmap_region() unmaps them. Am I missing something? > > > > - else if (prev && (prev->vm_flags & VM_GROWSUP)) > > + } else if (prev && (prev->vm_flags & VM_GROWSUP)) { > > + vma_start_write(prev); > > downgrade = false; > > - else > > + } else > > mmap_write_downgrade(mm); > > } > > > > -- > > 2.39.1 > > -- > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. >