Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Liam Howlett <liam.howlett@oracle.com>
To:     "maple-tree@lists.infradead.org" <maple-tree@lists.infradead.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Yu Zhao <yuzhao@google.com>, Hugh Dickins <hughd@google.com>
Subject: [PATCH v11 14/69] kernel/fork: use maple tree for dup_mmap() during
 forking
Thread-Topic: [PATCH v11 14/69] kernel/fork: use maple tree for dup_mmap()
 during forking
Thread-Index: AQHYmYdxJocTMfjFnU+bq7zgcKwyFA==
Date:   Sun, 17 Jul 2022 02:46:41 +0000
Message-ID: <20220717024615.2106835-15-Liam.Howlett@oracle.com>
References: <20220717024615.2106835-1-Liam.Howlett@oracle.com>
In-Reply-To: <20220717024615.2106835-1-Liam.Howlett@oracle.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?dzs1HbWMSxrp7Osw4VxgXcm4lfXIB5qFzLRTiqqVAD0xNIbQziKHBCyPk8?=
 =?iso-8859-1?Q?abnurRdeBBSnG3cn+f3t2QBHzZSTOFoOizwx8f+gh/MWe8UTCfFedOyZNT?=
 =?iso-8859-1?Q?1lcxkIpY3hZuLiUSsEhcxHk3mYqUwA54tDdSPhqG2dO0CRxLlt/p8lgHl4?=
 =?iso-8859-1?Q?WBQmT4cZ9vLP8+FXCe59uhQcvgHrp9AiBv/QyCDgUoHH+UichnJlwRp9cB?=
 =?iso-8859-1?Q?DMsr018HBGaH8DoGeFk4F/Hd2tm1iVw/qFANueHy2wrJYdspOKKK2erUqA?=
 =?iso-8859-1?Q?HDWV1lZhl5wk6QL//LUzJ3TjBNDF55oxFWGDjxprNLp/aOkVpHlhg0KZqv?=
 =?iso-8859-1?Q?s8x691ANd6MQJgfqnTpQWEaoFrLaa3cCuRF83+CnDUOglJKF4ZC2hh/I0r?=
 =?iso-8859-1?Q?m7XpjTMUbpqv34EpwuBY4YZit0Ggwwuyq9O2SsUw5gB5l/3NSmIYf5D+fQ?=
 =?iso-8859-1?Q?ylyMjVy1uwFwYHyP9RYkQ+g2pj+UI0OCDCEOw6GvfGszldO2aZhhYefx1/?=
 =?iso-8859-1?Q?8u98gv4IZowgpZDWr9DUs5W9XosNbCRk1yh91w+eGoOaDKAXjiWUU8Py/E?=
 =?iso-8859-1?Q?IkUJKjn9SbbCmQbVjiGhonPBCAmMOCXknjLzkC/5oesgfRF6Gz1rQw48Uo?=
 =?iso-8859-1?Q?3c5r1Hf0VNIOXcEh0PU1kM+m2kWuihU+DRAQ0p+aLQOdfubARB0eL0HqDx?=
 =?iso-8859-1?Q?ZbFmX3WJ46nmchemKc0lzqbXeVX5wcm1C/jrcBgULUuOzhf3VMDoYAEsTR?=
 =?iso-8859-1?Q?ahPX509k2D8LRxXX9DQhA2ro61B5vK8bnNK0Hd8+f7zHXtHLNdzG/HiD8i?=
 =?iso-8859-1?Q?sFVbeakxh1qq/PygBSFRNmgDyep/72Y8D8+ivO1A7NgEMjpIF67iQwZVdi?=
 =?iso-8859-1?Q?pRWuOg+6HNsqb7aSd0ytBcEcWCOFqCnYUejoJgopxqABUHzTtq+4iCyNug?=
 =?iso-8859-1?Q?bTDDu5u272hHXkcxxcYlNcIHHlZmiggi3wC8W6eXgHi7pcio1/vEYpcyz4?=
 =?iso-8859-1?Q?BxWCibRTc8FbT7METJjNP2PBUD3eyzv4jpoaEr/9tVe/TZ78+3Y6w65E5M?=
 =?iso-8859-1?Q?Q0S/vojFFAghM22mHnou7l0s2TaWEc3NnqYSFJY3Y2vLU9srq50oZxMJZg?=
 =?iso-8859-1?Q?zOTHZNHU/JmsL4OLGGpRFFtB3QoAnp3Y8sVXweeyeMRghiow6YM2SeuW3c?=
 =?iso-8859-1?Q?yV3AksWaZdlEztpkjDyxCJP9M1AMGqyrX5Qh54aDpQFcx5bVDU09E1jriN?=
 =?iso-8859-1?Q?vzOUOkdKq3OoNPqz5x0LT222FoQ0Z6EIF89vbXmJXkROb2FN0JIrSgd5ot?=
 =?iso-8859-1?Q?847DcXjvSX9F/mVTH195+VTDGw4sf3VzTiIMxM4HoxwRWAfVN4SR1NR40a?=
 =?iso-8859-1?Q?k6qgCFk8ApOtCbFBj8lW2qQoZgCcUBpWi7a2lLTSOh+n8LdhMHxDyvar5u?=
 =?iso-8859-1?Q?e/mRjf1uUxbE/3b1BOjBJRpXFxpRkY5tEfwwFkAHw/FvgymPgCyxhBDtVM?=
 =?iso-8859-1?Q?tPRXpectjDsCHHj7veMvMj7famvWKjF5FXt4eh5nybgpE98PNOE68bL+wU?=
 =?iso-8859-1?Q?SyWnHgW4+Y5CoSLfhd3XmnIgRg8SdlYhyGlUMVvPaDOZjB2uBlUKadXPLs?=
 =?iso-8859-1?Q?rgHdS7OXa29s6wclabCTcVkaLW5HAuZJ76TzytfLGGJq0dhPMSf6eCzA?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR10MB3022.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4ab3d3e4-62e7-4670-6f56-08da679e958a
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2022 02:46:41.2407
 (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: mvSM9WKfQVoZOWjJ+17npajZT2UO8IwUdACCYrwA2va853vSLnG0Zv9SaO/TgkQXY4TnRbf/dcnSGVURQbdxnQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR10MB2908
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1
 definitions=2022-07-17_01,2022-07-15_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxscore=0 mlxlogscore=999
 suspectscore=0 phishscore=0 adultscore=0 spamscore=0 malwarescore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000
 definitions=main-2207170010
X-Proofpoint-GUID: i56D8crtJluG5__5i6jWbPMts1VYPxbw
X-Proofpoint-ORIG-GUID: i56D8crtJluG5__5i6jWbPMts1VYPxbw
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

From: "Liam R. Howlett" <Liam.Howlett@Oracle.com>

The maple tree was already tracking VMAs in this function by an earlier
commit, but the rbtree iterator was being used to iterate the list.
Change the iterator to use a maple tree native iterator and switch to the
maple tree advanced API to avoid multiple walks of the tree during insert
operations.  Unexport the now-unused vma_store() function.

For performance reasons we bulk allocate the maple tree nodes.  The node
calculations are done internally to the tree and use the VMA count and
assume the worst-case node requirements.  The VM_DONT_COPY flag does not
allow for the most efficient copy method of the tree and so a bulk loading
algorithm is used.

Link: https://lkml.kernel.org/r/20220504010716.661115-16-Liam.Howlett@oracl=
e.com
Link: https://lkml.kernel.org/r/20220621204632.3370049-15-Liam.Howlett@orac=
le.com
Signed-off-by: Liam R. Howlett <Liam.Howlett@Oracle.com>
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: David Howells <dhowells@redhat.com>
Cc: SeongJae Park <sj@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
 include/linux/mm.h |  2 --
 kernel/fork.c      | 10 ++++++++--
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index dee609fe5c1f..60045508a518 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2613,8 +2613,6 @@ extern bool arch_has_descending_max_zone_pfns(void);
 /* nommu.c */
 extern atomic_long_t mmap_pages_allocated;
 extern int nommu_shrink_inode_mappings(struct inode *, size_t, size_t);
-/* mmap.c */
-void vma_mas_store(struct vm_area_struct *vma, struct ma_state *mas);
=20
 /* interval_tree.c */
 void vma_interval_tree_insert(struct vm_area_struct *node,
diff --git a/kernel/fork.c b/kernel/fork.c
index 1840da0732f6..f575a3bead0e 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -583,8 +583,9 @@ static __latent_entropy int dup_mmap(struct mm_struct *=
mm,
 	struct vm_area_struct *mpnt, *tmp, *prev, **pprev;
 	struct rb_node **rb_link, *rb_parent;
 	int retval;
-	unsigned long charge;
+	unsigned long charge =3D 0;
 	LIST_HEAD(uf);
+	MA_STATE(old_mas, &oldmm->mm_mt, 0, 0);
 	MA_STATE(mas, &mm->mm_mt, 0, 0);
=20
 	uprobe_start_dup_mmap();
@@ -620,7 +621,12 @@ static __latent_entropy int dup_mmap(struct mm_struct =
*mm,
 		goto out;
=20
 	prev =3D NULL;
-	for (mpnt =3D oldmm->mmap; mpnt; mpnt =3D mpnt->vm_next) {
+
+	retval =3D mas_expected_entries(&mas, oldmm->map_count);
+	if (retval)
+		goto out;
+
+	mas_for_each(&old_mas, mpnt, ULONG_MAX) {
 		struct file *file;
=20
 		if (mpnt->vm_flags & VM_DONTCOPY) {
--=20
2.35.1