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 CA796C54E71 for ; Fri, 22 Mar 2024 05:13:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EFADE6B007B; Fri, 22 Mar 2024 01:13:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EA93F6B0082; Fri, 22 Mar 2024 01:13:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DBE846B0083; Fri, 22 Mar 2024 01:13:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id CDAC56B007B for ; Fri, 22 Mar 2024 01:13:02 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 3636C4085F for ; Fri, 22 Mar 2024 05:13:02 +0000 (UTC) X-FDA: 81923505804.30.1C8BCE8 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf12.hostedemail.com (Postfix) with ESMTP id 25A0440009 for ; Fri, 22 Mar 2024 05:12:59 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf12.hostedemail.com: domain of dev.jain@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=dev.jain@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711084380; 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; bh=1Bl5Iw51ojtHBmKZKjANtqzb2nf3JX4q/UtmRaOrPIY=; b=hehMz1bxvw7292M5L+b72+PgaJIwcp1cNLQavlbFQFnEiRZdsc+dU6gMLfPaaaQAEBTZfR VcTsdEDe32I9EO+YmY+a18+AKJbp+DdlpF0bdWFGZa1uOmLG7g5EtA5qzOKbm6V41gm5yW iPLx4P30Q4xwc9mr+y2Li413pMeimaw= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf12.hostedemail.com: domain of dev.jain@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=dev.jain@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711084380; a=rsa-sha256; cv=none; b=e+xxcyqmPdfqT4INQ1ZUXSPogab5e73nOSV1GxiFyu1miEMBEyVEp+k/zzY2PO5je1tAw9 GCxQMYYTBnveeZ25EUmPWFMqg6SHc05Y1g6nWiVQsNl3zX8DrbPBKUQqS0+nMYmDBZ4hV1 KgXKOtkX6d19ljRpdcqxuScPipkEpUk= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EF4C71007; Thu, 21 Mar 2024 22:13:26 -0700 (PDT) Received: from [10.162.40.23] (e116581.arm.com [10.162.40.23]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CABEE3F762; Thu, 21 Mar 2024 22:12:50 -0700 (PDT) Message-ID: Date: Fri, 22 Mar 2024 10:42:47 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] selftests/mm: Confirm VA exhaustion without reliance on correctness of mmap() Content-Language: en-US To: Andrew Morton Cc: shuah@kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, Anshuman.Khandual@arm.com References: <20240321103522.516097-1-dev.jain@arm.com> <20240321145146.a3ce8a1e247371e33a437978@linux-foundation.org> From: Dev Jain In-Reply-To: <20240321145146.a3ce8a1e247371e33a437978@linux-foundation.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 25A0440009 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: iebsrhj9i4mcsocrpdc1fpujaj9y1z39 X-HE-Tag: 1711084379-699618 X-HE-Meta: U2FsdGVkX18r6j293X6b2v729Bt88q6VxlgpzIdkc0F9oCrWBDTkLRz1RIRCSyoYAir4q7Ssf5n1bpYbt/SWrheS4zfxEdgDVUOaCSkdSWEI3przRSvz5GIIVD13mOJ+hsflAR4CXkNhWE5/k7yJ/BFFqpQAS4aDpjvtqyYwk/tMa6aPvyOwj9RXjul+OqCMcQz+PuUB8XTSMBIMitaHvYNwQu7xDYRCXbR25KETeXwfdapzf8IiJqQXa5JE7m6sOSjzlGqbszHs8zF3VLKkg3Ca9aUHMXzg7WQAGZP0N2bYxAK4N3HzxImakHmirv5yEoRE0XSVoITDlW9od3zjR4gr5yMKjisGR+FGMf4ladXpepebhWeZ4Eh38Avgg7szQiZud53AAkEO91cC1YIKcmVadmR4pUi4lJDcdHs0wIMfE0Bi6pbOazF6FRKSHMgnhfqJ0Bo73bYa+2SsdYBUgI/UHGlCPkCyIglaz/ynrXcDCQigx8ngSgldUqc6p4bYKxoQ64F8DqNtj1CkSklDEPAV4XOzIXxArWDHz/e5DklkKoPG/NYptCYp6Q5uvf+zxhJkSAkhgyZYMzxbcd61e3u/dW/H9yLmNPKFi4RlsBg7lC6gjTkMz4TwpM6q81xm28ujR4roGnVAtYhEIuXDvLHSprCVvlyE1WseX4fYOTdWKyHu1bBagcQVvCsbANC4O5f21lAWRlnl2ZCmhqaevVlfUH1yE88RS3KacjxL4lcGWI5RgPPvGZhGOQcq9WcL7+mwpoNyZxsWZfk7x7Ubqud6teMZIJYnRH761PjDgA+ubnV+u85Xpbqizus+7C26Q4AEiC8U/rCCNVfxTa8Je36QXMBLvktyv6SS4pIPqHIb/1F5SY+9wgiLQ6+zurCysympbvM/GVATT0iG1zzBQAnT0HTM6uYcnbWeW1pbcgppbTXGcZH9k0amHDV1zhqvQMbfq/fOhS4wGna+Hd0 NQjoK5/z WxbdGQ8k/NO0Ldgbo59aWbtlBOXQpkYvnET9lJh7LiK01cYySdSvKlL58Pc7EzYWkBfvwmLAPjvJmvWo1DSf6kMeuoSiryxlucXCGkCoT+vy3Gtj3xq+wuiAs5zMfO9HjxCYDJlg41wuu60y7B7nPumt7HqSvuQoVG6wEneH+/PK5jbFqTHcjty1GCp2Pxlbh6XQWzl0EGVfMKdbgJrL1aguBOE4cAy0L2n8s 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 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 write() >> calls from /proc/self/maps to a dump file, confirming that a free chunk is >> indeed not available. > What's wrong with the current approach? While populating the lower VA space, mmap() fails because we have exhausted the space. Then, in validate_lower_address_hint(), because mmap() fails, we confirm that we have indeed exhausted the space. There is a circular logic involved here. Assume that there is a bug in mmap(), also assume that it exists independent of whether you pass a hint address or not; that for some reason it is not able to find a 1GB chunk. My idea is to assert the exhaustion against some other method. Also, in the following line in validate_complete_va_space():         if (start_addr - prev_end_addr >= SZ_1GB) I made a small error, I forgot to use MAP_CHUNK_SIZE instead of SZ_1GB.