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 6F25CE77188 for ; Wed, 8 Jan 2025 06:09:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C95546B0082; Wed, 8 Jan 2025 01:09:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C1E7E6B0083; Wed, 8 Jan 2025 01:09:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A97B16B0088; Wed, 8 Jan 2025 01:09:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 883C86B0082 for ; Wed, 8 Jan 2025 01:09:50 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id EF9B9140F14 for ; Wed, 8 Jan 2025 06:09:49 +0000 (UTC) X-FDA: 82983258498.12.9C1B00E Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf17.hostedemail.com (Postfix) with ESMTP id 10B9740008 for ; Wed, 8 Jan 2025 06:09:47 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf17.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=1736316588; a=rsa-sha256; cv=none; b=ZlSr5IshwtxqSXGqs2DMcPxCU/w7N7kIVCMT8u/1nR9YkzNzNmJ+FcWxb4okMOYivOZNdo txg+bOKMBV/ccOQX/1KMvN6n8ngsBeUsQGPDFzMMtZa9b0NCilJwotR3HcNdfRieXRQPep J11JDLaq4gyyb3oW2abQAhEF7xft5W8= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf17.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=1736316588; 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: in-reply-to:in-reply-to:references:references; bh=mIZqvkr8hbKC/XPCyX0sCnaTsgkqhse7OmhYdSDrxa4=; b=P2ZafxioXE3qpRvVaw2bHEseZdzxFPF/0QAUc26L8nQVHGXp0Dx+myfFEi31Zp2A0eNbM2 dycOtiLbnXj5rss8Oh2lf2cUfQoD0C9B1hVdJoxJNpE9t58XM0u1tKJX5TY/p7G7nm/DZT TyfnWeqAax29guY98S44IS9FBT42ryk= 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 40D6313D5; Tue, 7 Jan 2025 22:10:15 -0800 (PST) Received: from [10.162.43.18] (K4MQJ0H1H2.blr.arm.com [10.162.43.18]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0EF403F66E; Tue, 7 Jan 2025 22:09:43 -0800 (PST) Content-Type: multipart/alternative; boundary="------------z40S1RqfraYO2k2AfG7d8tRO" Message-ID: <2c5ab3af-2e58-449a-94f2-5cbcaa8b66f2@arm.com> Date: Wed, 8 Jan 2025 11:39:40 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/3] selftests/mm: virtual_address_range: Dump to /dev/null To: =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= , Andrew Morton , Shuah Khan , Thomas Gleixner Cc: linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, Ryan Roberts , David Hildenbrand References: <20250107-virtual_address_range-tests-v1-0-3834a2fb47fe@linutronix.de> <20250107-virtual_address_range-tests-v1-3-3834a2fb47fe@linutronix.de> Content-Language: en-US From: Dev Jain In-Reply-To: <20250107-virtual_address_range-tests-v1-3-3834a2fb47fe@linutronix.de> X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 10B9740008 X-Stat-Signature: eyk3zibttxm8jqiy45h78ee8ygi7fau4 X-HE-Tag: 1736316587-520228 X-HE-Meta: U2FsdGVkX193RYNF+i7NXJY3a3uQLrSXQePqm4SWW3LW2YdQKzwacbe3rL6e8avChUyMSe9H1F8fNPfrpWsjRo+RaWAYUNq9pkzQm2qjruKd0DtZLqMLTFOWPN8iNXHVzAA+4RNUWkLq43g7RFF55mA+zQGqJc8JObWBNmJkbIX8iE0WnclGDC1DZDa5rZT1Al6JtF7auyNZL/G2q0MKwJrH8PqCwYUnmGEzx4TDJCdy0NAQlnx+OBmfgvJiXu8/b1Xi1qDx8JPBxntKVoZ5pMXuNGjbr/0bZjzJ1/2CzqMSzzR99mDhBq27JlRc+JaQDs2fghTlztyXOMRklUWr1Fb8iXPrtI4M5z7T5khvAOfvkU1+KwSW1a4g8YPmGNTK1ED/eCG8SViJlHNPr1GQ1XGzWFUgEil/09wfN9kclvR2vd7ikQ47WOLzsvjn63Rp0FHiqxFdfsZ5o7YfZ+1Vw2sI7DqJUZSeTvCQM5SPqSwKfqbaB6lM7wTIsVoFMtQFX5Eb55luzEwYoTXkN/oN5iptJ7d9jytoPpWN2qruYSJlr4xk4dHY4NJWJu8sr0zYMhenNTT7a/7GHr6soetdze/YmGGzwSwTgZ5L1WcMnrUHa3ECR6HJ86mxOLIS9QSYAT5wZALHrnJEi2I1GaHpr/TkA6l2W+UYPRYVbej5zkna4KS3eqmk0FInRyfTAH4WonkXI69xDxc6iQW+hntYm5jEpUHVpymsyJvvl7gpQx051MljHBm6AlZxAcaD1/OKPgdMxBAyNDdlW3cPPb7VCBhJ/lbnCy+TCxSHF4OzulwBuAHoh6pLt2MzMVM4JReHnnUJeOAnwADZ665uF1XlumxqRryePRA4gABwgIit12PYiFFpKq0hLbTB3yp8ViC2vNqj6GrpO8XV69uOiCk5dO5UJCSSH9uHOSOaBP2tqR7iOsTaMgJLtRtErVAwx5DlphQc7eZwTq9aIee2Tza PSo4GFSb nPFkuQDUBW9ze5lmR5yrrxEKy47QXz/K1Oucd30eaoEgbndKiZ2/BBUzN+H7l8QmYj3gTqsI0kYxCU56eim9ukSqWN2XXMdNMolnRJSCkNXgnmfHkTmQzqj5vOPZ17RCjrKrFpuVLuTt4QCRzj/5t0bFRoThjGRhhNVo3FwNHn/Nm3O00fOl9X31jejCKr7TmA2S6i6oS0bp8I9/IAiyG0G5t7naR7I8tHgGwwE3Qb49Vf1H66jpYVtUTepzxlGKNCf1GstGHDqWUKsHE0bSqGbT98zeYaqD4NB6VCYyTQqWLXv9DRH+Bfr9JHluu6kxC9dPyj0kYiwwrrDkNxVsls0aYsJDO0uxEL7DCodUZHr86Igd67R26zO/9M3unRqe3YNwL 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: This is a multi-part message in MIME format. --------------z40S1RqfraYO2k2AfG7d8tRO Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 07/01/25 8:44 pm, Thomas Weißschuh wrote: > During the execution of validate_complete_va_space() a lot of memory is > on the VM subsystem. When running on a low memory subsystem an OOM may > be triggered, when writing to the dump file as the filesystem may also > require memory. > > On my test system with 1100MiB physical memory: > > Tasks state (memory values in pages): > [ pid ] uid tgid total_vm rss rss_anon rss_file rss_shmem pgtables_bytes swapents oom_score_adj name > [ 57] 0 57 34359215953 695 256 0 439 1064390656 0 0 virtual_address > > Out of memory: Killed process 57 (virtual_address) total-vm:137436863812kB, anon-rss:1024kB, file-rss:0kB, shmem-rss:1756kB, UID:0 pgtables:1039444kB oom_score_adj:0 > > fault_in_iov_iter_readable+0x4a/0xd0 > generic_perform_write+0x9c/0x280 > shmem_file_write_iter+0x86/0x90 > vfs_write+0x29c/0x480 > ksys_write+0x6c/0xe0 > do_syscall_64+0x9e/0x1a0 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > > Write the dumped data into /dev/null instead which does not require > additional memory during write(), making the code simpler as a > side-effect. > > Signed-off-by: Thomas Weißschuh > --- > tools/testing/selftests/mm/virtual_address_range.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/tools/testing/selftests/mm/virtual_address_range.c b/tools/testing/selftests/mm/virtual_address_range.c > index 484f82c7b7c871f82a7d9ec6d6c649f2ab1eb0cd..4042fd878acd702d23da2c3293292de33bd48143 100644 > --- a/tools/testing/selftests/mm/virtual_address_range.c > +++ b/tools/testing/selftests/mm/virtual_address_range.c > @@ -103,10 +103,9 @@ static int validate_complete_va_space(void) > FILE *file; > int fd; > > - fd = open("va_dump", O_CREAT | O_WRONLY, 0600); > - unlink("va_dump"); > + fd = open("/dev/null", O_WRONLY); > if (fd < 0) { > - ksft_test_result_skip("cannot create or open dump file\n"); > + ksft_test_result_skip("cannot create or open /dev/null\n"); > ksft_finished(); > } > > @@ -152,7 +151,6 @@ static int validate_complete_va_space(void) > while (start_addr + hop < end_addr) { > if (write(fd, (void *)(start_addr + hop), 1) != 1) > return 1; > - lseek(fd, 0, SEEK_SET); > > hop += MAP_CHUNK_SIZE; > } > The reason I had not used /dev/null was that write() was succeeding to /dev/null even from an address not in my VA space. I was puzzled about this behaviour of /dev/null and I chose to ignore it and just use a real file. To test this behaviour, run the following program: #include #include #include #include #include intmain() { intfd; fd = open("va_dump", O_CREAT| O_WRONLY, 0600); unlink("va_dump"); // fd = open("/dev/null", O_WRONLY); intret = munmap((void*)(1UL<< 30), 100); if(!ret) printf("munmap succeeded\n"); intres = write(fd, (void*)(1UL<< 30), 1); if(res == 1) printf("write succeeded\n"); return0; } The write will fail as expected, but if you comment out the va_dump lines and use /dev/null, the write will succeed. --------------z40S1RqfraYO2k2AfG7d8tRO Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 07/01/25 8:44 pm, Thomas Weißschuh wrote:
During the execution of validate_complete_va_space() a lot of memory is
on the VM subsystem. When running on a low memory subsystem an OOM may
be triggered, when writing to the dump file as the filesystem may also
require memory.

On my test system with 1100MiB physical memory:

	Tasks state (memory values in pages):
	[  pid  ]   uid  tgid total_vm      rss rss_anon rss_file rss_shmem pgtables_bytes swapents oom_score_adj name
	[     57]     0    57 34359215953      695      256        0       439 1064390656        0             0 virtual_address

	Out of memory: Killed process 57 (virtual_address) total-vm:137436863812kB, anon-rss:1024kB, file-rss:0kB, shmem-rss:1756kB, UID:0 pgtables:1039444kB oom_score_adj:0
	<snip>
	fault_in_iov_iter_readable+0x4a/0xd0
	generic_perform_write+0x9c/0x280
	shmem_file_write_iter+0x86/0x90
	vfs_write+0x29c/0x480
	ksys_write+0x6c/0xe0
	do_syscall_64+0x9e/0x1a0
	entry_SYSCALL_64_after_hwframe+0x77/0x7f

Write the dumped data into /dev/null instead which does not require
additional memory during write(), making the code simpler as a
side-effect.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 tools/testing/selftests/mm/virtual_address_range.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/mm/virtual_address_range.c b/tools/testing/selftests/mm/virtual_address_range.c
index 484f82c7b7c871f82a7d9ec6d6c649f2ab1eb0cd..4042fd878acd702d23da2c3293292de33bd48143 100644
--- a/tools/testing/selftests/mm/virtual_address_range.c
+++ b/tools/testing/selftests/mm/virtual_address_range.c
@@ -103,10 +103,9 @@ static int validate_complete_va_space(void)
 	FILE *file;
 	int fd;
 
-	fd = open("va_dump", O_CREAT | O_WRONLY, 0600);
-	unlink("va_dump");
+	fd = open("/dev/null", O_WRONLY);
 	if (fd < 0) {
-		ksft_test_result_skip("cannot create or open dump file\n");
+		ksft_test_result_skip("cannot create or open /dev/null\n");
 		ksft_finished();
 	}
 
@@ -152,7 +151,6 @@ static int validate_complete_va_space(void)
 		while (start_addr + hop < end_addr) {
 			if (write(fd, (void *)(start_addr + hop), 1) != 1)
 				return 1;
-			lseek(fd, 0, SEEK_SET);
 
 			hop += MAP_CHUNK_SIZE;
 		}



The reason I had not used /dev/null was that write() was succeeding to /dev/null
even from an address not in my VA space. I was puzzled about this behaviour of
/dev/null and I chose to ignore it and just use a real file.

To test this behaviour, run the following program:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/mman.h>
int main()
{
int fd;
fd = open("va_dump", O_CREAT | O_WRONLY, 0600);
unlink("va_dump");
// fd = open("/dev/null", O_WRONLY);
int ret = munmap((void *)(1UL << 30), 100);
if (!ret)
printf("munmap succeeded\n");
int res = write(fd, (void *)(1UL << 30), 1);
if (res == 1)
printf("write succeeded\n");
return 0;
}
The write will fail as expected, but if you comment out the va_dump
lines and use /dev/null, the write will succeed.
--------------z40S1RqfraYO2k2AfG7d8tRO--