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 B3FC2C54E71 for ; Fri, 22 Mar 2024 19:19:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 233306B0085; Fri, 22 Mar 2024 15:19:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E3616B0087; Fri, 22 Mar 2024 15:19:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0AB696B0088; Fri, 22 Mar 2024 15:19:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id ECC3E6B0085 for ; Fri, 22 Mar 2024 15:19:17 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 5800E1A0493 for ; Fri, 22 Mar 2024 19:19:17 +0000 (UTC) X-FDA: 81925638354.08.A8E3FA3 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf23.hostedemail.com (Postfix) with ESMTP id D4940140012 for ; Fri, 22 Mar 2024 19:19:14 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=g4iiwuWL; dmarc=none; spf=pass (imf23.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711135155; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=YvVGwdIENmNvc+fSSjJevZd89jG5ncO+/fYdRY2m3oU=; b=fJS1QFmP55TOaJZ38HwBdCOXju9E4m4leWL0JJTaHgRXiMM3oazsSw/w9BeElzuxIA/p2Q Los9WFVVOfkHqTMYh/53oAEHiBeKtYg1toaIqvySn4GsBNeLFX5/ddWUDMgLdyqRLwXnKw AI3QmapRc+lMYOi2aikEa5YioLWFWSY= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=g4iiwuWL; dmarc=none; spf=pass (imf23.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711135155; a=rsa-sha256; cv=none; b=1fswbCpFEVhEo1mULoFgoNIvRP8CAyMeF/TaAaMTKOAY6CAEfWIWmDjZCcxX3elxRLEcKL eVLpzN16NlknigwWShzrY8UMT2JuLK7RtDj2Q30sXB2Gkn16nF+K45v57bs3p7vMPIR0qq 73EcxxCQ1SfnYyrxFF4dKxfor3gVnsI= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id CF61661492; Fri, 22 Mar 2024 19:19:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 46402C43390; Fri, 22 Mar 2024 19:19:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1711135153; bh=UG0sBGKvrAEfQYFFsmXHb+05v3Y/kIQQfgrsER2wBIs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=g4iiwuWLrGSjXEtWYWuaR5z8kdipiKfD/181Dnwfo23bc19dVMarrZMhO3XiNbnCw Xd387VjPuHN2tdpcmDxrzhir90mPqHX/fPx2UuVB0LY3xhTCOQwf2p5L9vUgnK9wIh entr4Pvh6UALQgn42mLEO0GU9gR6yhezMYWXAxQk= Date: Fri, 22 Mar 2024 12:19:12 -0700 From: Andrew Morton To: Dev Jain Cc: shuah@kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, Anshuman.Khandual@arm.com Subject: Re: [PATCH] selftests/mm: Confirm VA exhaustion without reliance on correctness of mmap() Message-Id: <20240322121912.3bc9e58cfda1b7c92aac9c4f@linux-foundation.org> In-Reply-To: References: <20240321103522.516097-1-dev.jain@arm.com> <20240321145146.a3ce8a1e247371e33a437978@linux-foundation.org> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: D4940140012 X-Stat-Signature: 1wbt18sa1ttededorahoiormz4syj3jw X-HE-Tag: 1711135154-439311 X-HE-Meta: U2FsdGVkX197YF6ohTzLLkw7jTUGOub+08cY2BvKUmYb1itLrTAFHXqqwU4uwY6muFVlfjWq28Ow9yVcjfvmjT5aEWSrNENk6tL7V5rHLfVihSKylhcwZ8oc0U8X5slDvcA6LeNdh7b9Xtga636sqHnRA/PyHkKuxwMEYtBZjuLlvvmtYRN5VdNvw8EgMYiWwbx2UeAY4OWHHHpdWkP5DhsAMfivs0l3jvP1vuR69SBYeacMiYq81hZNdev/efUTNL8PeyhgrnsoHWVCowuZ509HHm87BvSC+gPqxrIAoj2oTeG/Ty51gAczs4Q1+0xnI7e9TsdtUw5xTgiQuwuloXGGGcF7JOHnQQxCAAejr4nVcZYLtlzHNptlsjfNvoLHUA9z/hi/H4P8OqNsIbo5e/6UAPjqxlYpDphhDT46BUsClloaLX56YEmcb8JgmIAfTa0AfRf08j/7ziVFNYNzP63qPIzyJnThd//zTXYTKzTEJBLb9UWSgRFJh4vdUNq2aQthlVJoMrMQmZYsxwY3DuEUSehOIEGpew+4WqiTJo/wNoynhWrKl3H87fWxqOHKsigE1J08o/4EXmcU5BcPO2P75o9crMi2JYvdJBTg3t3IsevVZxZeYsvFbvKlhtKC3ddlabFXOro9gmVou8AKtdzFO8uqOgOA3ztRwPw1wc1poz8F1XCNZXRix7V2AUtkp8l/NFSw4M1YPb8IMiZlLufEoP7Rqhj099BJmrsxReaddZFstWnMWHSItNThbOjg31/exfVC+Y/i4VDVJfKGL6NB5WNiIbwASzhWzsqoHR6NRaflGDdHsjt49jbEpiW6Zd/HFKiD4rHTtstEBLUHgZKI6C+nSV5icEu029UbpMF7IuMUydFdJkQmdPSsoUWPrikUewziGc+IzZ3oRonYlVuJrENzmrTTNDUgbdckWng= 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 Fri, 22 Mar 2024 10:42:47 +0530 Dev Jain wrote: >=20 > On 3/22/24 03:21, Andrew Morton wrote: > > On Thu, 21 Mar 2024 16:05:22 +0530 Dev Jain wrote: > > > >> Currently, VA exhaustion is being checked by passing a hint to mmap() = and > >> expecting it to fail. This patch makes a stricter test by successful w= rite() > >> calls from /proc/self/maps to a dump file, confirming that a free chun= k is > >> indeed not available. > > What's wrong with the current approach? > While populating the lower VA space, mmap() fails because we have=20 > exhausted the space. >=20 > Then, in validate_lower_address_hint(), because mmap() fails, we confirm= =20 > that we have >=20 > indeed exhausted the space. There is a circular logic involved here. >=20 > Assume that there is a bug in mmap(), also assume that it exists=20 > independent of whether >=20 > you pass a hint address or not; that for some reason it is not able to=20 > find a 1GB chunk. >=20 > My idea is to assert the exhaustion against some other method. Thanks. I added the above to the changelog. >=20 > Also, in the following line in validate_complete_va_space(): >=20 > =A0=A0=A0 =A0=A0=A0 if (start_addr - prev_end_addr >=3D SZ_1GB) >=20 > I made a small error, I forgot to use MAP_CHUNK_SIZE instead of SZ_1GB. And the preceding comment might need an edit. Please send an updated patch?