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 EA38AEB64D9 for ; Fri, 7 Jul 2023 19:27:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 848BE6B0078; Fri, 7 Jul 2023 15:27:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D2A08D0002; Fri, 7 Jul 2023 15:27:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 673BD8D0001; Fri, 7 Jul 2023 15:27:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5177E6B0078 for ; Fri, 7 Jul 2023 15:27:57 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 1817C40203 for ; Fri, 7 Jul 2023 19:27:57 +0000 (UTC) X-FDA: 80985800994.16.D92290E Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf11.hostedemail.com (Postfix) with ESMTP id 45D6E40003 for ; Fri, 7 Jul 2023 19:27:55 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=wCvnlZrB; spf=pass (imf11.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688758075; 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=XyPPUi+MRQXmfk9eJbb0Q/RJjC1R1VDWxOmvCavvj7w=; b=UHyF66lAGBbzmQkSHg95K9zluTOXId0T6vtnjggr6Z35Fm8ENHl1ivJ+F51edUCmZfySdy EJTBV6rIgAKVkUuZQJ38ptNjOigx4s8B5zPHnmFzFEX9IFic2GBcReDUzZajRHGjf6m2+v CzPU3FkNgU1cBJCXN8C4gfgzFNj5dKs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688758075; a=rsa-sha256; cv=none; b=m6uftwp9yocInix+pwrbmgKD0Z/EsKgonqmT39mqAzPfP9QF+zkfgscU0wG97rWb8WJf43 ZookHva+II/W3365fEfwbMLOuAK0/mR2aHLsH/jF6mvfcUkfAaE3obpeDWCJcJ63E8XZms uJO076EDyhnaizsZ92j0SwD/h91kXw0= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=wCvnlZrB; spf=pass (imf11.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 75C5461A38; Fri, 7 Jul 2023 19:27:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EE4E3C433C7; Fri, 7 Jul 2023 19:27:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1688758071; bh=b/nwBttY6PR9kozBothsfSykputrrbxrsvZzb9AG8AU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=wCvnlZrBJGLSDJgRrLUP8aaVEj7mKzHi5Xl7RY9sPfO9gEXCFboDs+BkPgdm2xi0U qL//eHQGQ5spOtGzccOdBx8sBHY0HKSffBwQhpYq8PjujN2Vd0UGqPG6Lc8/DJ+Zij +4ML/Rvc8EsrL1/Or79/KAuP6drfMI7GStW6KqrU= Date: Fri, 7 Jul 2023 12:27:50 -0700 From: Andrew Morton To: Suren Baghdasaryan Cc: willy@infradead.org, liam.howlett@oracle.com, david@redhat.com, peterx@redhat.com, vbabka@suse.cz, michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, hannes@cmpxchg.org, dave@stgolabs.net, ldufour@linux.ibm.com, hughd@google.com, punit.agrawal@bytedance.com, lstoakes@gmail.com, rientjes@google.com, axelrasmussen@google.com, jannh@google.com, shakeelb@google.com, tatashin@google.com, gthelen@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH 1/2] mm: lock a vma before stack expansion Message-Id: <20230707122750.f7cd77fe19b625cff37423ed@linux-foundation.org> In-Reply-To: <20230707043211.3682710-1-surenb@google.com> References: <20230707043211.3682710-1-surenb@google.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 45D6E40003 X-Rspam-User: X-Stat-Signature: s33zfgbseton8ybkmsoew7x7wk6q71rf X-Rspamd-Server: rspam03 X-HE-Tag: 1688758075-504327 X-HE-Meta: U2FsdGVkX19LFy1Ab2VknD0sEBKJiK6VwjQF7V9QBE3ktacSJxXRfe5zuJZEbiVOD0uv482o79x+W4VGDDWlXfwUM0gWcW9IHJfzPbJHkcqEaqavEIg1EV3PyDy3K6p6Ret3KKxYmtnel10qHo8QhOHpwFU7/Eh2qtMhVIZzcUS84dFTEemu1g9WiQonqxcfgrL9K//2wIiLmv1V3bpDe3VilX9z3i3PPhwt0b9AwaTcsXLSTmfVuJrZorBL4WlaXK7sRT4uEJO6hFJbu35dkAIpRWh4qBezQ1lqV3VAw7XsoZ01/e0OyCUqO05ImO3kT2t8AxRjHgd4Dqx9SJaHqKn9+1VdzQYs/J2xYI+RX0+qPBo1e6Q/Zh92768wGhIWibwOlroRcerSX/RcnY21QuoyzUfurm85qnV0H2asGye+S/Czila7NZ8kETSqbYj7QK3c8+U8hkFjMieDvQcMKwlo+b7bDV8R3BReNhBCHjggGKOBRB8v2odg5Rjf4cxRxps1FhDBoayD8HXSv5x0Ehznb+yCDfhS0bNDPWGPmcIpBSJNtjS4xZAe0gjS4IcT1GhsAd6jMc+UX1mKoC4klCNCHpHYhBuDtzgBEj/eQFJ1Qf3R6r1EMPYVygzff8HgcLBA62iA8jKx2LWRMimetsVIvdDawDy8TL/SHoOaxWrxPDKhUK1Zens4i2Eh5VwQ+TTFj/waFVHzcJBVAHtxblWuvJ2+9UlJ5xbqrEfMq+FVjRvnJbuagI0JexkyEV/Ilt4QObVW1FLa4Saqt2+JkjI7E9ftnnf+twpT6KC3BKfjFPOoQOeq3F3FGunT5nkvUyQM5TJgKZqby1u2pbvcIUWrP8xXJ5IRWDGRVSrd61/b75aeogBJ90yCNAgVUCdE/4x8It34CXkzqLvfRwinhaNxVjargackgi4dV4lj6QdEkxRiOYE6WBnjdi3X6Vt/Pqf04b9SZbw8CzHlVaI K3+GEROJ 4UlJeXQDy8ZC8fpDjD3U8MAOvE4zya30m9UpQ8efTvEhfp61s68QOXENO7BaUKOaa/fRuLi5wiLYQ/X/IOTT7e4dX7NvklZb5y83OZQMBLbh8q4WrWAKMaU+tmVn09B2ZPXahkeVdqltIdVrw3jN7sMOo3NV4kXcaqhHadrNaQfDlZJBV5Nf3Xq/AOnugoCHK5joSZwFIi5H/fJUWMjn9zHo0YdR+V5sBX2bC1Un+lJ20mnnFrOR3LkI6xVXiew3dEqnxicFe/+KpZQh1Rr35Bd4Fn+q4TMcRblAwW1UJz9Jc8cOpbojjlsE1GuuMua0EvuKfdISKO7uzljCB8tYRpF+9rKnZXnOCm7w0 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, 6 Jul 2023 21:32:10 -0700 Suren Baghdasaryan wrote: > With recent changes necessitating mmap_lock to be held for write while > expanding a stack, per-VMA locks should follow the same rules and be > write-locked to prevent page faults into the VMA being expanded. Add > the necessary locking. What are the possible runtime effects of this change? > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -1977,6 +1977,8 @@ static int expand_upwards(struct vm_area_struct *vma, unsigned long address) > return -ENOMEM; > } > > + /* Lock the VMA before expanding to prevent concurrent page faults */ > + vma_start_write(vma); > /* > * vma->vm_start/vm_end cannot change under us because the caller > * is required to hold the mmap_lock in read mode. We need the > @@ -2064,6 +2066,8 @@ int expand_downwards(struct vm_area_struct *vma, unsigned long address) > return -ENOMEM; > } > > + /* Lock the VMA before expanding to prevent concurrent page faults */ > + vma_start_write(vma); > /* > * vma->vm_start/vm_end cannot change under us because the caller > * is required to hold the mmap_lock in read mode. We need the > -- > 2.41.0.255.g8b1d071c50-goog