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:     Sven Schnelle <svens@linux.ibm.com>
CC:     "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>,
        "damon @ lists . linux . dev" <damon@lists.linux.dev>,
        SeongJae Park <sj@kernel.org>,
        David Hildenbrand <david@redhat.com>,
        "hca@linux.ibm.com" <hca@linux.ibm.com>,
        "alexander.gordeev@linux.ibm.com" <alexander.gordeev@linux.ibm.com>,
        "linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>
Subject: Re: [PATCH v10 13/69] mm/mmap: use maple tree for
 unmapped_area{_topdown}
Thread-Topic: [PATCH v10 13/69] mm/mmap: use maple tree for
 unmapped_area{_topdown}
Thread-Index: AQHYhbALqTBpFGf5+k+LdWHoM0UZLa2F6jZlgAAJPoA=
Date:   Tue, 19 Jul 2022 14:54:21 +0000
Message-ID: <20220719145415.dvtpwfykfmddi4sx@revolver>
References: <20220621204632.3370049-1-Liam.Howlett@oracle.com>
 <20220621204632.3370049-14-Liam.Howlett@oracle.com>
 <yt9dy1wpi3pi.fsf@linux.ibm.com>
In-Reply-To: <yt9dy1wpi3pi.fsf@linux.ibm.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?tQteXfpTC4zsLKU0BsStJRjfmLNlfPDF0ISWpzUOSqTHRjlIVlKXwLYDp4IG?=
 =?us-ascii?Q?ItP+wsrsc46B0kmnj5sVQYncWP9GQqyNFyOoBKvMuAAFdP+pNR5N/1L8qhEF?=
 =?us-ascii?Q?LqRTqgrd1SHcAgxQCN7nF7aO/bbkPvrOi/frYWf0FlFRPYfk7SdWMgaKKbiU?=
 =?us-ascii?Q?9xAHYIGzB5oeAwGzjZxTSr8DvH/jsgF7bh3RXjYv31i7/iTRm/XBGTfB+Iyl?=
 =?us-ascii?Q?GawGtEwAG0QMVJCtqnhsk8Z+RwL6SRnoVkr6GGPefc/FLGY7cEif1wAy2nTt?=
 =?us-ascii?Q?IcL4etmArH0SnHW18Zh0R8OUMG5nEoFYIrbLSGl0lgllY7BCO9JISB3DlgL+?=
 =?us-ascii?Q?69+XtQ9v/Y1OoiXZC4hdMaAfbSI7i3Ih9AIhvbcY/LE143CY+ANs8QfLv8c2?=
 =?us-ascii?Q?hHsxxioFd6lt+8xkqnZu+le0dpxSvqapfLIUvEZ5wbBgvR+UvFfFT6vvCBZq?=
 =?us-ascii?Q?5BIilKdP36H7Xh5NsFug3sTSxHJYe08tUf9BGc8WHnBVjfQu3MzTuJI/HGPX?=
 =?us-ascii?Q?A75108YMf9d2Vit+H/LwLdFMnwWMe1G4nWCboWEWrePFlbYaZSbXxWlRaRU6?=
 =?us-ascii?Q?Fvh5kQW53GUHjGpXKhSgiGnME2gWnlk55+N280qpiYvZSwKqOARwtw0xyVM1?=
 =?us-ascii?Q?cBoLozEq2k1FlyJ5Z/VSDOMv7Mwr/BO4sRrujhKXqrxqhiYwhlbn2pUchMiK?=
 =?us-ascii?Q?cxQJX/CpF4iqnSrxAqnbx0JOeA0aN5DOdEmZfTszC2g72IKbBSvTN8wpdwxm?=
 =?us-ascii?Q?aOdRz/8ECvMKKNPH+fBqjOCVVXl1K9JZ+Novhtp3EjBI1DQYSQRl6kDDgSwy?=
 =?us-ascii?Q?4DMLC0AS2T0iK8dVfijuL2DN9Z5iH1rgnetb4cJi8krDe94NSDMl9ly5c1bV?=
 =?us-ascii?Q?XLgonRK2BJVUXWPBHW3WMz1Mt/NWHNdeR0Nu3IF+yoN28Y/fEg8aR43DWm82?=
 =?us-ascii?Q?MpAfMq8x5K1/X5w8NSu6UaBhCDcberhqywLue6/zzzE1sE75Vzm6B+Te9mf6?=
 =?us-ascii?Q?AOgpbffy4MUqyBQaZ4koDP/F9TcUNtupPRuOPrjdNOP8wbpx0Pph41PhR/1H?=
 =?us-ascii?Q?8ViMmuvJEF1jwqb7RtQdoiHF7gJu/F8hKUipHMihrnB7Jrs62wX4l9mEuHTj?=
 =?us-ascii?Q?WPzuLZhwTq5jGqjJmXgn9G7tRmWFUEgJfCVVkyiM+ZrXGx+d6U++jEozvE1t?=
 =?us-ascii?Q?7YxiSp8W92bgZOjZ++vfpR+k4NUMoupTNF4LHhd7xnITnchwIMzK7mzgjKq/?=
 =?us-ascii?Q?AqyZebcFL3K7hdmBwuJZlh6a/yyu7fRi9WsfvfZ0FdVjbgyf2yV++f50WdOi?=
 =?us-ascii?Q?/DCnf0haqXus5B5HPgYSeZj4Svf7uyilajOFBtwDjME4bDnom9IXAggIh3ru?=
 =?us-ascii?Q?s5SUXUZe1RoWqWvEYgh5EZNNwRdwQUOCrw/AWWLmaU3tQ8zJqQGMrqvHAUWu?=
 =?us-ascii?Q?iTIiOIhw0Y/gJVHEZB08fqPCtdy53IJtQFhdr9bPK3W3AYgdAc6BPq8cmwOv?=
 =?us-ascii?Q?mnYBXF3ocrJyYEBzf1QIvTEDfQXY0eQLhwjfgwO7Yj+8avszxQCJtYHKqVHa?=
 =?us-ascii?Q?4hcIkvzxIDsA9WoaNjRo9URRsMBu1xtKxlmQdqusbsOYWTvO6oziS3VrxgYk?=
 =?us-ascii?Q?RA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7170F88643253B4DB059FD6F1DC57D5E@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR10MB3011.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d65f380e-d62c-417e-679c-08da699690a4
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2022 14:54:21.8738
 (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: QzVOVh4t1AJ1TeKAplGs6seZmbWrCYSMNcCaDHdze2CX6kupJw/f9UdkOoCQeroou/dLt4KRRGSJq/8jHQe1MA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR10MB2473
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-19_03,2022-07-19_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 malwarescore=0
 mlxscore=0 phishscore=0 mlxlogscore=929 suspectscore=0 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000
 definitions=main-2207190062
X-Proofpoint-GUID: ECd7s82GWHndxdKGCFq5qj_AxJQ1qNNB
X-Proofpoint-ORIG-GUID: ECd7s82GWHndxdKGCFq5qj_AxJQ1qNNB
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

* Sven Schnelle <svens@linux.ibm.com> [220719 10:21]:
> Hi Liam,
>=20
> Liam Howlett <liam.howlett@oracle.com> writes:
>=20
> > From: "Liam R. Howlett" <Liam.Howlett@Oracle.com>
> >
> > The maple tree code was added to find the unmapped area in a previous
> > commit and was checked against what the rbtree returned, but the actual
> > result was never used.  Start using the maple tree implementation and
> > remove the rbtree code.
> >
> > Add kernel documentation comment for these functions.
> >
> > Link: https://lkml.kernel.org/r/20220504010716.661115-15-Liam.Howlett@o=
racle.com
> > Signed-off-by: Liam R. Howlett <Liam.Howlett@Oracle.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: David Howells <dhowells@redhat.com>
> > Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> > Cc: SeongJae Park <sj@kernel.org>
> > Cc: Vlastimil Babka <vbabka@suse.cz>
> > Cc: Will Deacon <will@kernel.org>
> > Cc: Davidlohr Bueso <dave@stgolabs.net>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > ---
> >  mm/mmap.c | 253 +++++++-----------------------------------------------
> >  1 file changed, 32 insertions(+), 221 deletions(-)
>=20
> With next-20220718 git bisect pointed me to this commit because the
> following code fails in compat mode (31 bit addressing) on s390:
>=20
> #include <unistd.h>
> #include <stdlib.h>
> #include <sys/mman.h>
> #include <stdio.h>
>=20
> #define __2GB__         0x80000000
> #define VMA_SIZE        0x10000000
> #define VMA_COUNT       (__2GB__ / VMA_SIZE)
>=20
> /*
>  * Repeated mapping below 2GB until all memory is exhausted
>  */
> int main(void)
> {
>         void *p;
>         unsigned int i;
>=20
>         for (i =3D 0; i < VMA_COUNT; i++) {
>             p =3D mmap(NULL, VMA_SIZE, PROT_READ,MAP_ANONYMOUS | MAP_PRIV=
ATE, -1, 0);
>             printf("%d: %08x - %08x\n", i, (int)p, (int)p + VMA_SIZE);
>             if (p =3D=3D MAP_FAILED)
>                   break;
>             if (p > (void *)__2GB__) {
>                   return 1;
>             }
>         }
>         if ((i =3D=3D 0) || (i >=3D VMA_COUNT))
>                return 2;
>         return 0;
> }
>=20
> With linux/master:
> # ./mmap_compat_anon
> 0: 67a00000 - 77a00000
> 1: 57a00000 - 67a00000
> 2: 47a00000 - 57a00000
> 3: 37a00000 - 47a00000
> 4: 27a00000 - 37a00000
> 5: 17a00000 - 27a00000
> 6: 07a00000 - 17a00000
> 7: ffffffff - 0fffffff
>=20
> With next-20220718 (and older, we're seeing this for a while, but i
> didn't notice due to vacation and other priorities):
>=20
> # ./mmap_compat_anon
> 0: 67600000 - 77600000
> 1: 57600000 - 67600000
> 2: 47600000 - 57600000
> 3: 37600000 - 47600000
> 4: 27600000 - 37600000
> 5: 17600000 - 27600000
> 6: 07600000 - 17600000
> 7: 40000000 - 50000000
>=20
> So the first output is correct - mmap succeeds until there's no space
> left, where it returns MAP_FAILED. In the lower (failing) one, mmap
> instead returns an address that is already in use.
>=20

I'll have a look.

Thanks,
Liam=