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 9F66FC8303C for ; Mon, 7 Jul 2025 06:12:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 219D66B025A; Mon, 7 Jul 2025 02:12:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F17F6B025C; Mon, 7 Jul 2025 02:12:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 06B3F6B0400; Mon, 7 Jul 2025 02:12:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id E41106B03FE for ; Mon, 7 Jul 2025 02:12:52 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 6A10A58B11 for ; Mon, 7 Jul 2025 06:12:52 +0000 (UTC) X-FDA: 83636450184.26.3DDAF59 Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) by imf29.hostedemail.com (Postfix) with ESMTP id 9277A120006 for ; Mon, 7 Jul 2025 06:12:50 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=H5r1JJqx; spf=pass (imf29.hostedemail.com: domain of hughd@google.com designates 209.85.219.172 as permitted sender) smtp.mailfrom=hughd@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=1751868770; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=k47dZt0Crs1sORHhdpWLtZdwuIrz1qyGCHW6wK+Mmyw=; b=FTdIOMpJ30ilWmKxjyx+exR6ORPr/9/8uWYocs7fr7JtqGWVNNNWiKDB+enT94CWr+hy7X mjI/ag3oGLjskiQzI2XkgpENZ8qLEaXzqwXLo5gNsoQyfm4jZYf8B5+p0FsXbXOOnmbI92 MVbJuAamQiYj2ouf1dBc9/Hw7BM520s= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=H5r1JJqx; spf=pass (imf29.hostedemail.com: domain of hughd@google.com designates 209.85.219.172 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751868770; a=rsa-sha256; cv=none; b=BoBhIPAG6HiUBuf9BeD2lbPYPWTZhm6ik7aeMf/yoWvCepZh/VykEjVX/+//yOWpEROkHT O975hCbxrw3dXJujglnpnd2Y2g107GG0EQihR+51oleHTkQPkhBCEo3uS/au84sNykVeLT soZh1JjeIYziFbjrQzajFQ1enzG5MYc= Received: by mail-yb1-f172.google.com with SMTP id 3f1490d57ef6-e81826d5b72so2224174276.3 for ; Sun, 06 Jul 2025 23:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1751868769; x=1752473569; darn=kvack.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=k47dZt0Crs1sORHhdpWLtZdwuIrz1qyGCHW6wK+Mmyw=; b=H5r1JJqxbd6j7UydhpVZPMrcKAC9xXVp4oQbrWaA1w/MpyjgY2IcrVbiNPz2/yl+Qi 8yrLVPzGXSlAVXfCFgMoXtd5yaBO+onzajymtPrW5NBdkVF+82I56J1P3niAG2Xnz040 O2EZvQndzZ/OhQaLBQjlSvyk0XIBbHABiAmNR4Lzo6/3S6pipp5Grr2/v9VzI4Ohp6KD 6uGJvhvbQHozkl91TvyxkSnVz8R56aTCMz68PN/wKc1aD2vB+YO09qXA2Hyh01bWOVlD 9FOatYv2d3TyZWbONsWA6TxTF3qzaj+pRaEOpcKmKEVlcip5ABESAqOjE3SlWb3oe1GS pdhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751868769; x=1752473569; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=k47dZt0Crs1sORHhdpWLtZdwuIrz1qyGCHW6wK+Mmyw=; b=qPUCV6ad1TChmdfN+8gqkwyU995eTnMNXsH/3yrU2yaKjW3nYXuJdcbpQhGaEkl/Q1 y+q1iFb9R2+QIaVUOgJ33mn2IIqhgHH74pewYA7qudxbsiYqE9AJJzTD4INPnqjXhZii wgj/4sHt4ex+nqvjb0DinJYJZSb3+nHjfSRaZOksPaOhNfVG7Y2R+uVVNXT7phmhcUQl wMIP/MT6j/9RXLjOo3zlgmA27JXbNEuq3CzQx10ZbnKW1hSu+hzWu6i4J2WTYJVYyG9P xbW5VRWPVbq6WYe8EVKd2qaIbs2/zzGd9sgMjoZJgkXrlot3XFPf7CPeDJegpiYQZm2J HhHg== X-Forwarded-Encrypted: i=1; AJvYcCWXXiZWQyzDUzSmoVD6yXraMsAMVYp4n1egrhPe+fLrbz0jh0T9EJmTpdLhdDmaTWjw645Qc9OENw==@kvack.org X-Gm-Message-State: AOJu0YyjHO5fV7ZRstUlUilVOZILDglJ2i6v5CeHGzz3jsxO79/6A2FC ralnwGgWkDHNtsu7WyhTdWbKUZuy55UIRSDkOe9Gvc08Bq9qNa2wM1OxtlVVm7N4xg== X-Gm-Gg: ASbGncto6Xny3RZF0DAZeE3bAI8xDH9F82O13QtCql3+suBYm9aY76zUv4vbfShYa8q 0jSpchgGA6gxqy419NJQbJ+DlHW6JEms9EM0bqZNoUfrDUPy1m565CAm2Qh+T+HOx/8Cv0HxrhO TjFdA16NKr7q/+vKu9Khczd2jGAxxQhkVjKI1wMWRcvJmCcwOFiFIWOtiMGt2ZSxgFcZ4NQQrK4 B61ocHB/S32gx9BTxdLCl6bGBXVl1Dic/yU4UZlvANpul2oCQOVI8y3/6mmacKdfeEQq84UOCC2 sieQSzyn4Aa2vpJg79dpy4hBJUg9y9fEIDKTGkEgjhIfXb159aaD0XViefOS2ecDXRyEZE//Dy3 rn+ycmXV0N5cukHxPF28dvKZdx2uMd355T5rQAOqqmCm+aF4= X-Google-Smtp-Source: AGHT+IF9uQB3C/Tk35uzYdwuZvbuiSoulQvT3LDcgrKfi8L4w4dnTGxlaUN4ZI/H1HoNYSPT7Y5GKw== X-Received: by 2002:a05:6902:18c7:b0:e82:1c60:4f7d with SMTP id 3f1490d57ef6-e8b3cd8d184mr7723935276.39.1751868768837; Sun, 06 Jul 2025 23:12:48 -0700 (PDT) Received: from darker.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id 3f1490d57ef6-e899c440860sm2451588276.30.2025.07.06.23.12.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 06 Jul 2025 23:12:47 -0700 (PDT) Date: Sun, 6 Jul 2025 23:12:35 -0700 (PDT) From: Hugh Dickins To: Lorenzo Stoakes cc: Andrew Morton , Peter Xu , Alexander Viro , Christian Brauner , Jan Kara , "Liam R . Howlett" , Vlastimil Babka , Jann Horn , Pedro Falcato , Rik van Riel , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH 00/10] mm/mremap: permit mremap() move of multiple VMAs In-Reply-To: Message-ID: <4a4344b5-ff68-d57f-de7a-68a091bcb092@google.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Stat-Signature: 6z8prgdrh5ksk5snyzxp8x4rhcmjup1c X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 9277A120006 X-HE-Tag: 1751868770-514500 X-HE-Meta: U2FsdGVkX1+WLJc/FmXOIU99F3oHsaiNAm82ZEgqkmFhOE9Ii0yhDSqRPGgzQUMq8DIzZZgm/PMR1jZg+8Qsanyrc2KSO3NyD+ybXlidzXFIR1Up0z8b7rfeSzfPBRNyO8Q3YyB5GU4MgUDtxpOrPUG3w0l4AvbT4jLt1LNgXoPqrhAOTkPa7p9egEoKYcDfjngH7N3R1cPXG52HoaAleGQ1JeHA/36NeCN32HU55XFwaNP4GrdmKjwr2d1x49tzUHSiFFJZD6x83de7ZqRJGgrBe1dkdb79tIut7XA3ueQmO9Yuu+EgYkk8nABLNva+0JJZJpXfTDJsdY+zQwnhonlkP+OAlavpbczxH0OBipYr4AdKomV/DOyXb/GVISTGXLdFQ5m7dcWqVtS8PV0FVzUtn8gnZaK5BSD2UcExBTdxeuNpXBQbjQsaktovOUwsTKc7U845VTTY8hpG8kYno85RkFhUCzfU+M6ztZ3GGT/xu3SlupGG/zi93200ni/MWnatYwg5m/UBzlHy+EHX+/yoeSDzp/YZsmD378gNATEqWpvbmK43bdqob5MhOjz29hBEdUEfj+z/JSLq7YQk+hdVNwbMcMeZ+mq+Ulg652tAmiED3rtQbo7Bh53KrNwwwcdrR9LmcnwyWrKXj89eKs3qf1JBjRGCvnuvSqFjXzIzLpb2KatBjLD9RQvnPLT/HA81zABogQiYlXP92NcScNUbcF216MYXS6S+Spe3i1lF4XepyAGvddC8Ybgvbdj8BqCJgp+Y30kCDbGygysAy90BLZBHCo+zsCkGrEWS4RHZ7VsVTaCfGW1w4+NltN/+2MUlBrHiszbjav9bEHkbpcrasEvf+kY172YWfeZcaSCvlkBUyRtvufdrMB56fOP8+RPi7Bmbnw1jrhC9PSUJn+BRWTY8thbbhUXgPoLOVNI/shHuPb1Ntcjm6pEyPTaOra2TxpKMlkzrCJGp+A3 wdDFXgm1 kUfGnv5Pw4n8D6+Jifedv45N7sTT3cDvbsyscCAUqgbOW8u6oiiTU+Gi3u5gXrMkcfloHp+k127Gg7HYl/VBz2PmU70kfXRKXfbpfnk002Hld2xbXP4jp4Jx6j7zENaavksRHCvhxIWb2Qxap6PxYPOu8xxRLBJeRjh/OB17Ajg8QvpH2hFf6/fd08IL9waGWjFXZDJq6EaWuulFoxn/ozpi5VoPy/oqkzq1BdjwGglZ7AlzrDLyW8hFgAnjQiLY2EU84bWq3d9PUT7Bz7baoLDKGPcEG8j93IQRz7jZi1jpwXDHUfV8ygFQ+mlzb1pWe6Li8p+cB0vZ1XrhOoSJD7OSw+eeRm2jD9k5NNA6ay98BZ6w= 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: List-Subscribe: List-Unsubscribe: On Mon, 7 Jul 2025, Lorenzo Stoakes wrote: > Historically we've made it a uAPI requirement that mremap() may only > operate on a single VMA at a time. > > For instances where VMAs need to be resized, this makes sense, as it > becomes very difficult to determine what a user actually wants should they > indicate a desire to expand or shrink the size of multiple VMAs (truncate? > Adjust sizes individually? Some other strategy?). > > However, in instances where a user is moving VMAs, it is restrictive to > disallow this. > > This is especially the case when anonymous mapping remap may or may not be > mergeable depending on whether VMAs have or have not been faulted due to > anon_vma assignment and folio index alignment with vma->vm_pgoff. > > Often this can result in surprising impact where a moved region is faulted, > then moved back and a user fails to observe a merge from otherwise > compatible, adjacent VMAs. > > This change allows such cases to work without the user having to be > cognizant of whether a prior mremap() move or other VMA operations has > resulted in VMA fragmentation. > > In order to do this, this series performs a large amount of refactoring, > most pertinently - grouping sanity checks together, separately those that > check input parameters and those relating to VMAs. > > we also simplify the post-mmap lock drop processing for uffd and mlock()'d > VMAs. > > With this done, we can then fairly straightforwardly implement this > functionality. > > This works exclusively for mremap() invocations which specify > MREMAP_FIXED. It is not compatible with VMAs which use userfaultfd, as the > notification of the userland fault handler would require us to drop the > mmap lock. > > The input and output addresses ranges must not overlap. We carefully > account for moves which would result in VMA merges or would otherwise > result in VMA iterator invalidation. Applause! No way shall I review this, but each time I've seen an mremap series from Lorenzo go by, I've wanted to say "but wouldn't it be better to..."; but it felt too impertinent to prod you in a direction I'd never dare take myself (and quite likely that you had already tried, but found it fundamentally impossible). Thank you, yes, this is a very welcome step forward. Hugh