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 C0318CF258E for ; Sun, 13 Oct 2024 22:36:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CA4FA6B0082; Sun, 13 Oct 2024 18:36:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C2E206B0083; Sun, 13 Oct 2024 18:36:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ACE986B0085; Sun, 13 Oct 2024 18:36:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8BCA76B0082 for ; Sun, 13 Oct 2024 18:36:09 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D6A831C51CD for ; Sun, 13 Oct 2024 22:36:00 +0000 (UTC) X-FDA: 82670038248.19.5FFC45E Received: from mout.web.de (mout.web.de [212.227.17.11]) by imf13.hostedemail.com (Postfix) with ESMTP id E9CAE20008 for ; Sun, 13 Oct 2024 22:36:00 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=web.de header.s=s29768273 header.b=qbTzr8za; dmarc=pass (policy=quarantine) header.from=web.de; spf=pass (imf13.hostedemail.com: domain of spasswolf@web.de designates 212.227.17.11 as permitted sender) smtp.mailfrom=spasswolf@web.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728858863; a=rsa-sha256; cv=none; b=n3IfAStgqRla3KyOGY0TQIXGbF0JGKMUA+iXj1aGEg8eODKRCC+heKB1OxiRfM2oKWVkHA wns+myPM1QTBv3Xe7DLY8a/s1tL+XcxBCU0OmAaEie7RpxRzJIBQWQ4uYm0IVK27EiaO04 qCjhAu1lxPsn0hFe/0H9Og8tBNxPrdI= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=web.de header.s=s29768273 header.b=qbTzr8za; dmarc=pass (policy=quarantine) header.from=web.de; spf=pass (imf13.hostedemail.com: domain of spasswolf@web.de designates 212.227.17.11 as permitted sender) smtp.mailfrom=spasswolf@web.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728858863; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=aCw1oeSw8vSXVmoCunY1TVWsQxtjHFr3wh/NLJTUJag=; b=dhYYigXeZM/Z8MU/it1Z9DVC+Vk+JbobI7j3TBIjVnFrqVW8eFslo0RJFkO8667WmjWmTw V87NBJ+7e8gZkWrlsI0bCzA9vTIVmuRDGwSHqhjmQuefr/d/tqhGaUlUUmKDo3ahIxE/pF LsutK4eVuduuVyf4XiTzjDV8KUnUuCg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=web.de; s=s29768273; t=1728858964; x=1729463764; i=spasswolf@web.de; bh=aCw1oeSw8vSXVmoCunY1TVWsQxtjHFr3wh/NLJTUJag=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:Message-ID:In-Reply-To: References:MIME-Version:Content-Transfer-Encoding:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=qbTzr8zajSx1qrBlhxOQaq8a+ttJ31wT+DyOB/WhPiT5nZIJeuAt7LAQxvkrZsQs 2/1mSqYTgpQg8JvuTtQLmw+zsciSOP2h7EzUUAV7/mkUE2lWZSGfMCA14dhw3/ar1 cM9h8PPdetnzigRVEz1ZN/HIsoO+HiJzzGR6wIF8bFavEXknPgoW3F7pQUcqJoThP NrTvNZtAHp4hbbiMKSL3WfO9N6G4TwmdzlUpEW0kEKqTIbUfZXe9rlqcWhK6LHoXb 8yGFCGdff/5bMrnTW1LCVeJBzWMDRY+atHcoCavwRI1daNdiJ9qdq14J3OSQLIuG6 dJHg3mWE/FqYWQ2fWg== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Received: from localhost.localdomain ([84.119.92.193]) by smtp.web.de (mrweb106 [213.165.67.124]) with ESMTPSA (Nemesis) id 1N45xz-1u05Y23Ycz-012VC3; Mon, 14 Oct 2024 00:36:03 +0200 From: Bert Karwatzki To: Lorenzo Stoakes Cc: Bert Karwatzki , "Liam R . Howlett" , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v8 14/21] mm/mmap: Avoid zeroing vma tree in mmap_region() Date: Mon, 14 Oct 2024 00:35:59 +0200 Message-ID: <20241013223601.3823-1-spasswolf@web.de> X-Mailer: git-send-email 2.45.2 In-Reply-To: 2394412b-3037-4867-b16e-f155740d062c@lucifer.local References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:oeMJEhKzrJsasXR6f69El1Xi2vIV63h9KHEIkU+jCc6RQZyZdDE GYMgWEYq0LKPmbmeTATny5/IRV6LpIZissNZ5b4Tg90U54EYVfZ8avPOJO5oCH1uq+n1fq/ eNj/isjcPAHjZKIZ36v7ChngQFa1vo+XvFlwl5MyG5BfBFlTyyEwRzDy6q13ozaEZUDkBXc mYbJYpSmtYSq9s6q2ByNw== UI-OutboundReport: notjunk:1;M01:P0:6HqD0nUwwxQ=;96cZdo5uH9Aug1ItOI7oT9ISc7E unzrB9Q39ACym07tq1L6ZCGNPOUgNJWnQQr82ypjP4drK84EkIDbp0slXJ5lgoM/sGdeXKjTc nljzvlrlFNstzO/dZ9x/4IzlDB7+5VYa1eblMHOFA35/FRe8lLBAAtgMwyijR4iqT3T48to0Z WrifDao4P97DClTKNhj7tcofIZPs4fK6ezia6RPtf3bQ2j639OQdwYQChFDfqxaCLo4aVnnVk vBfzG6i/bQVLWECzLG0dwloELo9OW7XjBUF5KxuMtA0IdBd7HNqge/wGyHiNUPvUgD9DX5O+2 eLHmiSOuMOPsZUwk/ze5NPlk/p6VzhGZHBQFYIQjT3OeS6raydTw3W8UxjZZvWM0y1j09TYpR 6jakVkIsw4EUsTmM5RaMjmet13+Pmt97ffHEGEkTE5SeIob5IQd1vBqH6bUPWZWXtXuArmPre auRFPiRVe7HQXDWUXCxFdJpUeEu26HiXalltK5zpA+oFNIqeNN1aNYNikNIqifaxtxVahDa91 y6HXkNWqP1TK9wDANKD2fe+8vxQqPBbegEob//UWI/NDK0Fw6qq9ZPICncLOZuqX1Zd8Y8jPo 0hEPHpJRCNMMTajPXU76LsERdbNDqQDH8dVka74GcPNeln5cvkr4G/trHQ15aGuDPTgE1a9id aWn0F3F9FM8xrHirNJigExv2BUpi6sCjoVqOLGromdD/oZAUOqIYZGsKFuT5SmjZPxXBTVEyC cP1FfL/2+knAPMAj6LhoO7N/g2e/rmpttnUexDWF7/cx7iy+TbI2zRk3gZLHxeSVjQUoBhATs OdF94OTixX/rhcNXZPiZylbQ== X-Rspamd-Queue-Id: E9CAE20008 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 1zu1jxnog3nkiazf916otw4edjz5i1gp X-HE-Tag: 1728858960-312935 X-HE-Meta: U2FsdGVkX18mivnNZ9N1u1C+F576zVkEKoZMmZ4msKdHW7bMLm+XgIm/tJE2316V8Hz1s8lM5rlIFUHOAXwaQk3RW4ei6h3FUay4w+m83QvvAoYDaz93enV58LrgVmBXgWGqe8yItpGMq4Lqq0xEOOMhJBnL0sHxRBXnoNU5bHZBAwTo5Bj2NMOu43oL+hsAYtL2nWXsFLS0JTYxAyfxAC9LH2c1uH2wu/n7qXr48voaFbyMUXePgwakMNNf7MZej1fBsmeCdgiQJjnEfvvvozlp5l46YAlWgZmqd2FrNXhtoAf6cDA7azwzZjWMxBkzAyNFzCZVhgQWztUDSotD5Z++L2/LaVE+M+XtC3Ay0Ufecohx5Tydfawve+l06+dhfDn/cAsXQPrBW5TLukYV+cgK/JBnbiWkKWsJykbQaHeJv1Mo++Sq5/7Pip1QVs8iP5swTrVCv2KIL/eLHBCKHxJsEAjClIHJ/ZgDHPnBnWW91ton9AsFnuaKZGtlQkpgd05WJAMF61Bo/5c8fBUP+Jawcjt2KVdNCVYWt8MXFfE0Gxz2ZckdbsplP5GToIn9JnSvLB/bGEKlXhZS0sgfSFkQfAPqbnzg3+2BU4A8ciESzZTpu8i4XaGmlLKO8UtTZQ1CUXmRbXANAakZI4u8ZxgitZkI/e26MXSOUAlstaf2mivUTFy/V1jPwx+az4Bpqsr3eFi9IlS1SNe5EQdu31vUqsoxqAOyhb5D7WEmuyCs73jtN0QGkMMXls9OQRSEbwtmz1yrURyd3gKYmDYx5jKDiRYSK4M1ljG1n9QbD9mxStf9xVuJRWxpwkspVi5UYFIUzXcbDhiL5ndu/eTeo/gdrTn+5PcTvJnzIju/P54Ev0AIxaxiZboe64NgwFiBXpAiSx4kIcTOiT2hUdEoTc7lwabmiA1uNMUFKhe5gxTZ8kJmifL+FdartQGbsH+9Rv3V6jwxEHTpTU48uuo 5EpS5xAu SSGDY832PZZZ/cQHjKZ1mVGsw6z7KctYvbNkSlFFwrhjqV7Ym4SQj1Uehr/SqNVd0JbffXK9eASm5aZdkvV7OxEGcfLEaecUcZxFd2CddraMepjqbOrxNbPHEaVx8XvOPU3S8N/9XS0zr/Pul8b5Z2L9Y2Mgo4EjAbsjvgVAzXt/gnSudeu01bAXYftnfdta8A8f652fhDigNCJWXv2+j54/uLK5GCAbneFkKMPOepDE+94Fj9nqk+duyx6at6WJaURngxApFeInclTVmR9Dm+pkSlaYVlxnElA0B1v9wp7ufKm+WXDKiJ8yMTe7kNmOELTL3 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: I created a program which can trigger the bug on newer kernel (after the "Avoid zeroing vma tree in mmap_region()" patch and before the fix). My original goal was to trigger the bug on older kernels, but that does not work, yet. Bert Karwatzki #define _GNU_SOURCE #include #include #include #include #include #include int main() { int ret, prot; void *addr, *tmp =3D NULL; // Create a lot of consecutive mappings to create a sufficiently deep map= le tree for (int i =3D 0; i < 224; i++) { // We're creating mappings with different PROT_ to // avoid the vmas getting merged. if (i % 2) prot =3D PROT_READ; else prot =3D PROT_WRITE; // These mappings are all at very low addresses in the virtual address = space so // they are mapped before the text and data sections of the executable = and // the library and stack mappings tmp =3D mmap(tmp + 0x100000, 0x100000, prot, MAP_PRIVATE|MAP_ANONYMOUS,= -1, 0); } // // The maple node we're targetting has the range 0x7800000-0x86fffff (and= 15 entries of size 0x100000 each) // // Here is the layout of the tree before the spanning store: // // [0 - ffffffffffffffff] // / \ // / \ // [0-86fffff] [8700000-ffffffffffffffff] // / | \ / | // / | \ / | // ... [6900000- [7800000- [8700000- ... // 77fffff] 86fffff] 87fffff] // // Do we always need a spanning_store AND a merge? Yes, and we must be ca= refull that we do not merge // with the first vma of the next node. // // This gives a spanning_store because the newly created mapping can be m= erge with // with the last mapping (0x7700000-0x77fffff) in the previous node as bo= th have PROT_WRITE. // No corruption here! Why? This merges with the next node, too! (0x87000= 00-0x87fffff is PROT_WRITE, too) //addr =3D mmap((void *) 0x7800000, 0x1000000 - 0x100000, PROT_WRITE, MAP= _FIXED|MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); // This give a spanning_store, but no merge as the PROT_ flags do not fit= , no maple tree corruption here! //addr =3D mmap((void *) 0x7700000, 0x1000000, PROT_NONE, MAP_FIXED|MAP_P= RIVATE|MAP_ANONYMOUS, -1, 0); // this give a spanning store, but no merge, no corruption here! //addr =3D mmap((void *) 0x7700000, 0x1000000, PROT_WRITE, MAP_FIXED|MAP_= PRIVATE|MAP_ANONYMOUS, -1, 0); // This last example give the maple tree corruption and the validate_mm()= error: // The mapping from 0x7600000 to 0x7700000 has PROT_READ, so this gives t= he needed merge addr =3D mmap((void *) 0x7700000, 0x1000000, PROT_READ, MAP_FIXED|MAP_PRI= VATE|MAP_ANONYMOUS, -1, 0); // Just for waiting (to examine the mappings in /proc/PID/maps) for (;;) { } return 0; }