Date:   Thu, 16 Feb 2023 10:34:05 -0500
From:   "Liam R. Howlett" <Liam.Howlett@Oracle.com>
To:     Suren Baghdasaryan <surenb@google.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, 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 v3 21/35] mm/mmap: write-lock adjacent VMAs if they can
 grow into unmapped area
Message-ID: <20230216153405.zo4l2lqpnc2agdzg@revolver>
Mail-Followup-To: "Liam R. Howlett" <Liam.Howlett@Oracle.com>,
        Suren Baghdasaryan <surenb@google.com>, 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
References: <20230216051750.3125598-1-surenb@google.com>
 <20230216051750.3125598-22-surenb@google.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230216051750.3125598-22-surenb@google.com>
User-Agent: NeoMutt/20220429
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?yby38xH7OkZ25/tXxbCIxpzMRxu+MDbWCaUU+4EUygoxzJs7Y2NZk6ClW16D?=
 =?us-ascii?Q?m2mAE3cSIr4VSK5W8AvHzOKrnOzN6afn49UgCdl6bMSf0z3ZHEgqcJ1zvMs9?=
 =?us-ascii?Q?EdcyQCmoQSRprQDhHGGTAclW8xhnwyFGzhr+sxXsT6+YM4vLyPU0JYXkDkI6?=
 =?us-ascii?Q?vKgmCwTZdhIJmR3h7Z3AAe4UBpIPIsTGcM5mah7ocHCYqs5ZyFe/ikaMzi7o?=
 =?us-ascii?Q?FAEfjjgRRh64clZ53CxKWnMkOwGyJjQWb8//oSa6XMg995u/ZogzV3D1ci1o?=
 =?us-ascii?Q?3bhHl48x13V5F2O9LH5sDVfGK0jR+SPS768TBay5Ay06vZhWKjqRqC3sUgoH?=
 =?us-ascii?Q?FeoG6x5Q+qzJHEYE5HwKL8lC04Lr/xDLgYzyzp/wWh6afo6b5QJ5zV9AqCDf?=
 =?us-ascii?Q?Zj13+HkGP5Vfdamd48te3WFqCtph66qDx8Al4xHN9+UCxTLlwH8YIVzFLVnW?=
 =?us-ascii?Q?kH65n/17tp9+dHkMEhJrwRNobdxyhdI75aVu+PJWvSe6hJgzNPoObelQgp/X?=
 =?us-ascii?Q?mPYSLw9EpOI66GkAMN+PhfGvqY0YlY7uScBrdu1T+MI1xSWwO54egMAaYwT0?=
 =?us-ascii?Q?P551xZkFFVxgurvf6/dx/+zImpq27INOFV6GljfanonGHeofjiyinjinbVzs?=
 =?us-ascii?Q?+ieYk1TN+3ak8THUWHO0+eFvwVzVfIhQSa9GwMH0f4OEAJR3Rn8vsT6szkTu?=
 =?us-ascii?Q?0sWFB2BKJND0NwRwjQFWR3efFxN4BNSShue+vfdT+TJY4NTmX9Bu56hXB0v0?=
 =?us-ascii?Q?kgDOJ6V+9yu8edpcQovHGZQangnMwZoQd0Veu8qlu5ivJFlXqQg+dpiVcgP8?=
 =?us-ascii?Q?PR/bEv2DytIvpDxZkItSjCpp3rB/xnf/d5ZxpXU5y+QYWShQW6Mrc4cZWMIT?=
 =?us-ascii?Q?dy72+GLkEI8Kt9+RyofFReHAt6KIo+2zJKyBM3ATkvsjYOBoVmlVLIsHJihh?=
 =?us-ascii?Q?oB6HZUHHwH6r0aOB5EUn4RizWS6x52/WCsdSVPdK3icLJbFdScJClFcNBWEs?=
 =?us-ascii?Q?Fdbis4SHIKdP+E4Qnv1pBD2StNMTuQPW2g2Gdjh8/PY5Z0BIXo/8N9UObM/p?=
 =?us-ascii?Q?faYlG5TT/p/Xjf5JVTudPNc/dg+UEM/Xsc/JsunSUIaeXG35HJ4GSRynP7dm?=
 =?us-ascii?Q?TPmQwevXDQ3QH7BquKClL5IJd4AeiPPDFLj1o6trewavHTnkKnwOXcyJpf3L?=
 =?us-ascii?Q?EQEs0VgCuQ8BddNpvdv15PJbAWvxPFzvIM3672Lx7yiRHEpBnl7/vE8CA6hr?=
 =?us-ascii?Q?wZbzrq2N4bKgPyE09+ghRJcg1XWXBYiVGVBusV0FhGwpG8xzFbRCu1VL590J?=
 =?us-ascii?Q?zTPSAU+Pgw360B3hdDbUcZseoxqXe0ZwIfo1TW83vdZ980gyGYdy3C9JLSwI?=
 =?us-ascii?Q?ZluDl90JHSyjAK3pNh/mB0AZILhVsE3cqczehdg3Pt/i5042i/FsOZhLM/6q?=
 =?us-ascii?Q?4fqIBCZzPbuoUApsbTq9q4j6vF2DahKiRGykYYDv1bYXcpB9lNztQrrq71fp?=
 =?us-ascii?Q?BkYiBrr0/UFY+Yu4DT4MGUaUrbBr3hCI8ajTlhUOqLYLGMFJzsKWGAdxHrRs?=
 =?us-ascii?Q?5w5H0Ka88Pi98NaCOQb5SIpBmfr9wDo1z5bYrERPV6B9tC4D5f/QwO2ZRqRQ?=
 =?us-ascii?Q?5A=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: =?us-ascii?Q?Tq+lCUe0FtqX0FZhpzxJJOoQlF/M1IDbPa6R8UrYqB57Mv9QMSFa8dY0fBOR?=
 =?us-ascii?Q?Nxe04eQC6H+pIuyWHuO68efq1o56K408PIxnGgqBuU1QrdakGr6rMUR7htkF?=
 =?us-ascii?Q?+V8VKsWY0ssFdQafeg/8ow7w7zsd1/D4IzkZWxEfiEq1RxXbql4KwY2yAkEz?=
 =?us-ascii?Q?bd1XuYRX0ZPWhNutn3NBXBxRG7KzDv50FfKKE4W7s+cgXsGajmThb3opZKSB?=
 =?us-ascii?Q?gvRPDKpImr0VW0yumV338jyEID3IFPStbhn98KDNHVOoojETlZMOOy5R3lv6?=
 =?us-ascii?Q?NYNwZIiHs6Klbpb1pdX6hL4l5AysXlIvTKsgS2zjOvBzeLvd9F0yCgYFd6dB?=
 =?us-ascii?Q?uuPohu/FYSjpHZdr4N5WSp1BIehtKxSzT+hW9NnAiJK3Bn1i1LbdBJqVx/mp?=
 =?us-ascii?Q?8fgfaPgmUK4lA91uVH+VCAMVe5VgnkYWPiIzvY+Hg4RT49QhP/l8fwWYdKPe?=
 =?us-ascii?Q?i1/ng9dF/JbSOBZ5ChWhmwbN65P29o6KOumrHZeGG8wyaLPf7omD0htUPIKq?=
 =?us-ascii?Q?hTmORV6u60ObOwuXIf7GYsmMRJ5HoJpiCHKLshcuXDiY3thCZ4tZqhH/vjqb?=
 =?us-ascii?Q?JDnAr0a8mHvzXbIwHqbQUDXcc+zT4FjkZW20TQ7FJV59LA6poJblXT2nVk0A?=
 =?us-ascii?Q?8JtnLPS4oByk3Ii0TbRcGScRmYIeMyJkJ1gOjymWtE6EyFI4hNtmtORXg7C+?=
 =?us-ascii?Q?XWK4U6E+ienbdp9SjwmyEDS7mEU2dJV+3U8ytH6wEsQ7xVX7zyQbcwhtLtSC?=
 =?us-ascii?Q?Znv21Cqx7eO9wY0vQeRd/oShrsq6CRTM2eAWdvYp/jpf2RkMIkB053Utfz8A?=
 =?us-ascii?Q?k+9pYuOvsoBa5/dAZGgK1Fqx7C7WCxESZLArSPo4UVCYmFgnOhCzMpNANs8L?=
 =?us-ascii?Q?o9aE8iLoE1sW7GbvE6Fk3eLoAZnbcaALdWTSHuyvSLsnWVKsVdM6P2C+89la?=
 =?us-ascii?Q?Q43l2nQuPCjnmdzRnJIhinNoIX87rO/ULXxZnPv39HVqUQBioeD627Dv9fNg?=
 =?us-ascii?Q?i49x6xf+4XbGKVmurVAmCKjWPQhZMNFXRWOwGtKe91lOXq6DHSg4r1wLIrNA?=
 =?us-ascii?Q?IglmC7i77E25OEXIJpIorDlrBsTsDjrkC5jIUkEoM0MJbxlkVHsJ68tSa1qW?=
 =?us-ascii?Q?vv7g812NPmxotma6tJY0ojLP0mwm+kf1NTV6NydhLmtUKLG9kNFl8bLSsUwW?=
 =?us-ascii?Q?la1ac0iLIXoNTdbDt3RMyK5cPRmnXqEH0mKE6e8eRQFckxjqhonog4WwiAtb?=
 =?us-ascii?Q?4rOduRDDAInFu0rS8Q/ioxJ8Tjrzci0Do4cq9qd7Iqi/50NoLFgeByfi7Xbb?=
 =?us-ascii?Q?rs43muWhEnvSL2Xe66IL/7EN2IBfTT5xZ/z56MrBinZF3uh3tfHZh32fdD0x?=
 =?us-ascii?Q?YxHo2dJLPvGWS5av638tjiHcnvKklJ6fnh4xFH28NzRog4tVwYEtFcmH4lc/?=
 =?us-ascii?Q?y3qco21aEsyGyF50gNP6OOZxWNcOf4JPfRNYF0XVUSNX2mokFzhR6ZVedeTF?=
 =?us-ascii?Q?wIL2ZzSVrVI6ktb6Xr9GhmDhOOMaVCDRtc9rvw4+aTx1JwFiGHCqAYHKKw?=
 =?us-ascii?Q?=3D=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 06481105-5d3c-4145-3dfd-08db10333f33
X-MS-Exchange-CrossTenant-AuthSource: BL0PR10MB3011.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2023 15:34:09.6193
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Ogf+yc4IBa6GsnpyM9WBcH4Dll/dZKl/O1GJYO8ohIgJInvpr+xQgEuO1w0JZzSGT+TiJ7qUbmgcfUQKe3Ah8Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR10MB5865
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22
 definitions=2023-02-16_11,2023-02-16_01,2023-02-09_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 phishscore=0
 suspectscore=0 mlxscore=0 spamscore=0 mlxlogscore=478 adultscore=0
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2212070000 definitions=main-2302160134
X-Proofpoint-GUID: bBH9bPc4RPmB5WazVNqrdw5ikD12RdKj
X-Proofpoint-ORIG-GUID: bBH9bPc4RPmB5WazVNqrdw5ikD12RdKj
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


First, sorry I didn't see this before v3..

* Suren Baghdasaryan <surenb@google.com> [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 <surenb@google.com>
> ---
>  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.

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.

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.


> -		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