Received-SPF: pass (google.com: domain of linux-kernel+bounces-127018-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
From: Oleksandr Natalenko <oleksandr@natalenko.name>
To: linux-mm@kvack.org, Vlastimil Babka <vbabka@suse.cz>
Cc: linux-kernel@vger.kernel.org, patches@lists.linux.dev,
 Vlastimil Babka <vbabka@suse.cz>, stable@vger.kenrel.org,
 Lorenzo Stoakes <lstoakes@gmail.com>,
 "Liam R . Howlett" <Liam.Howlett@oracle.com>
Subject: Re: [PATCH] mm, mmap: remove vma_merge()
Date: Mon, 01 Apr 2024 22:08:31 +0200
Message-ID: <2335177.ElGaqSPkdT@natalenko.name>
In-Reply-To: <20240401192623.18575-2-vbabka@suse.cz>
References: <20240401192623.18575-2-vbabka@suse.cz>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart4896029.GXAFRqVoOG";
 micalg="pgp-sha256"; protocol="application/pgp-signature"

--nextPart4896029.GXAFRqVoOG
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; protected-headers="v1"
From: Oleksandr Natalenko <oleksandr@natalenko.name>
To: linux-mm@kvack.org, Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [PATCH] mm, mmap: remove vma_merge()
Date: Mon, 01 Apr 2024 22:08:31 +0200
Message-ID: <2335177.ElGaqSPkdT@natalenko.name>
In-Reply-To: <20240401192623.18575-2-vbabka@suse.cz>
References: <20240401192623.18575-2-vbabka@suse.cz>
MIME-Version: 1.0

Hello.

On pond=C4=9Bl=C3=AD 1. dubna 2024 21:26:24, CEST Vlastimil Babka wrote:
> With SLAB gone I was looking for what I could delete next, and then it
> dawned on me - it should be vma_merge(). It's simply an unmaintainable
> mess.
>=20
> The code is extremely hard to follow. There has been a number of recent
> attempts to made it more readable, by Liam, Lorenzo and myself. Almost
> every time this only resulted in subtle embarassing bugs [1] [2] [3] [4]
> [5]. For many of the bugs the only reliable testcase we have is the rpm
> process running in the Open Build Service. Which is worrying, as that
> clearly makes vma_merge() a potential supply chain attack vector for
> planting backdoors.
>=20
> Thus simply remove vma_merge() and all the related code, and adjust all
> callers to take the path as if merging was attempted and failed.
> The only downside is that there might now be more vmas and maple tree
> nodes due to no merging. To extensively validate that, I've booted the
> kernel with virtme-ng before and after the change and checked slabinfo
> for the number of active objects:
>=20
> before:
> maple_node          1159
> vm_area_struct      1538
>=20
> after:
> maple_node          1113
> vm_area_struct      1861
>=20
> Yeah there's more vma's but interestingly, less maple tree nodes. I
> believe it's worth it. The larger number of smaller vmas could even help
> with better parallelism thanks to per-vma locking. So the conclusion is
> obvious - we should have never tried merging vmas in the first place,
> hence the tags on this patch.
>=20
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/co=
mmit/?id=3Dd014cd7c1c35
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/co=
mmit/?id=3D4c6759967826
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/co=
mmit/?id=3D7e7757876f25
> [4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/co=
mmit/?id=3D1419430c8abb
> [5] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/co=
mmit/?id=3Dfc0c8f9089c2
>=20
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: <stable@vger.kenrel.org> # CVE mandatory
> Cc: Lorenzo Stoakes <lstoakes@gmail.com>
> Cc: Liam R. Howlett <Liam.Howlett@oracle.com>
> Singed-off-by-one: Vlastimil Babka <vbabka@suse.cz>

Nyacked-by: Oleksandr Natalenko <oleksandr@natalenko.name>

TYVM!

> ---
>  mm/internal.h |   7 -
>  mm/mmap.c     | 368 +++-----------------------------------------------
>  mm/mremap.c   |  60 --------
>  3 files changed, 17 insertions(+), 418 deletions(-)

/* SNIP */

=2D-=20
Oleksandr Natalenko (post-factum)
--nextPart4896029.GXAFRqVoOG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEZUOOw5ESFLHZZtOKil/iNcg8M0sFAmYLFD8ACgkQil/iNcg8
M0vAbg/6A8Krc8bk+nqpqjPO0IDAhn5xp+Cdh/sua9KVU7ddNCpZdgsHRUz91tU5
GOQQmTWjpZU55lTS72r7LCE6KvU/UYOAnIVbwD1Iy5xLAKd6261tmMhAxQlCqJ6E
7m/4jys/Kzex9tl6ulKsZHbgURoAfo+7WBuSSCwLJpFvxNMQMoKdIrHj/bbC6G7C
ylDz+pd1w7FM/3Lc/Le7xAMbG+EA+U3jcif0kprjXiq7njq8g4RalahModA4LI4E
NcehS9hGeueZrmaP2nKHhGryR/o1nc328tC1RzlF2Aby+oP9FxihUfYNf497oqew
VzOZqMeMzDV8Vl6oyQe8WqOp6z2Ht2588BnecgpHkckkUs99wltQr5XvYKSYVf51
WZUCXNSgB7XyUAJpgG+L/FBDvaMJCKeDhOesscm8SStVs7FEZQYXVf+Bf6SlK5sB
0ybZMW3vEdBd0tMfoic+Wr4FTgFwJcONeOkHTqjnp7t/tAzmNfh8qSW+LlNZ4ji5
T4uX+mkEYpNuMxq9/4t34nohaG+LgArjTwcFr1gfzBe1HasO6dGw/dUAM2rqrLlN
p7w8lNygK5FyVZUH9sXMoa+5HOxbcLjA9wAEP31ISwA+O688D4qL7gGWq6uzucba
kZPF9HYPD323SZhDZ+Z3UOuEbDDBHpSwuXplQjJYwokrTHGDelU=
=aH3Z
-----END PGP SIGNATURE-----

--nextPart4896029.GXAFRqVoOG--