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 C692AE77197 for ; Thu, 9 Jan 2025 05:33:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 566566B009B; Thu, 9 Jan 2025 00:33:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 515EA6B009C; Thu, 9 Jan 2025 00:33:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3DD6B6B009D; Thu, 9 Jan 2025 00:33:08 -0500 (EST) 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 215026B009B for ; Thu, 9 Jan 2025 00:33:08 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 91A521615D0 for ; Thu, 9 Jan 2025 05:33:07 +0000 (UTC) X-FDA: 82986794814.05.11F0D6E Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf24.hostedemail.com (Postfix) with ESMTP id C9721180008 for ; Thu, 9 Jan 2025 05:33:05 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf24.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=1736400786; a=rsa-sha256; cv=none; b=hpGP3ZbGhrvyjaIrGeKE2jfCULf0uLfwXJI8z5yk3BK0Khh/OesB80X0+528iaaAR9eGD7 vmSa6S2/gY4BTDU2nSHj09isWvMamNtxoTGkOuCSN1JUv2Zw0eSm8HkwIfJ8TVjvpumkpb zJE46qeij44fylPXjRAXUj9jqyNw3/w= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf24.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=1736400785; 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=YWAQrSEgw/ltNQR/Lxn1JR67mPjgTUIwHExGw+OPXvc=; b=LHgTiUJ+khpT9ly9L/OjNdVHLKVURUif/uC5FotsL+UZ1GzKBtpBY5OCRacxFTy/gi/U1o UqHJOqwMJ+X+u5LuygHnBksus1vCAdRwL3wYXMcOMiV3K+Jli7pJfJTvYZtLTXY/v8oThn d9f4ZfWOO19Ix+p3wGoFaOYg61NgRmM= 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 23D9A13D5; Wed, 8 Jan 2025 21:33:33 -0800 (PST) Received: from [10.162.43.52] (K4MQJ0H1H2.blr.arm.com [10.162.43.52]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 12EC53F59E; Wed, 8 Jan 2025 21:33:01 -0800 (PST) Message-ID: Date: Thu, 9 Jan 2025 11:02:58 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/3] selftests/mm: virtual_address_range: Dump to /dev/null To: David Hildenbrand , =?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 References: <20250107-virtual_address_range-tests-v1-0-3834a2fb47fe@linutronix.de> <20250107-virtual_address_range-tests-v1-3-3834a2fb47fe@linutronix.de> <2c5ab3af-2e58-449a-94f2-5cbcaa8b66f2@arm.com> <63481999-0665-4f40-a1bd-377a6ae69f90@redhat.com> Content-Language: en-US From: Dev Jain In-Reply-To: <63481999-0665-4f40-a1bd-377a6ae69f90@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: C9721180008 X-Stat-Signature: zxaino5uiqyinodrarbbrfwexz7cez9n X-Rspam-User: X-HE-Tag: 1736400785-365000 X-HE-Meta: U2FsdGVkX18L716VshEXlZH6e+t2wwff+yilvbDZk+sVHxiTMXgsvo08rbj7tyWvMFapRSrzKKom0eb6jqQnM7vCyAkT/tJcgu90L+NpPtSj/aIZDxDxRaGmpNiXZiOkwceXqtsGweomAoYzoCGGzPQ0Z0jTU+89l1DHW/irZDQo3/F79+4zsgQczu4kSZimwDUSkB0XtigpEXWE7jun7weMNwH+YQxWkoDlxPMi7i2GeKANzvIBQslk5nTOwMhjqwkgBBO/U+IowUWYDBaEJHZ13FzLdGN71YFQy0C3qlyTxrbrHuZ8wu2Gg/0TUNFx2Agm4lwbF5pdNkgCZCvEIr0MJNwj0Fig3FDYi7o/0XapHGL6qusO/ttLowsh3oMGFdpoba123TDLTLkIxFKIQQrNGDFxxQnOGjUQRdBQFj859YgTVZT8AnjzyUcxuyvh+dJLZ/L/KPrfvP7s8dEJxnqWuG+a5eBn+v942g5bmQq2t3H81KPGT6yD7LcKiAhwD54OIJXn2eK63/GA3qDqm/UKdm49PaXZ13bVbsI8YyaWpeUO9lsx3PUoTlZWq5UXdGfl4rfZxbYLQkXliD+0caqf8uEc8FGLKoS/hPMmiF48FpvwcHgmKx1hH6qMgcTMjUeeA0GhTy/w/fpZl8bdVhWbR1/3adJfxiTSrw8HdEZFftiYepbP63Ao70+iyqC8u9jnSnHl0FWc+Q4bxpum4CxXOYjMnkszTFvfUpjdteVoo0+yhUKMOzbKVe7J9UuBMLlGAPi2WkeDHkh8dnmbTrhiEjEUNRifBW1Zz4WqIGg7isVZCybWjmIbFJh2azWVl6/GH7FfWwEXW2yUIvOewGeMROzUuRR9ZdFBIH8E7wIrpudce3I8WfiVtK6m4Km5N9OcPM8KQTTBa7LLVb2v8MwKFBWzjzr8Zv3IJ9y43/w4XYc8OeUPmxZMtizFXgt2QQ3UNuMMwgPccHYbLL6 AEyRy7Ie FGPwYhnaxM1XB4wicaZwdY1fUD+AO41UlEVwcQm8lt4ZZ25h1Xf49L0HAoug+Yyo8lkg9fFGxu4PTdlFZQKwR2Hng39SnQYHwubLL67KaJigGlUsrKoX3leHSbHdLTlwP5XUtf2BJKqXCY9PdTnOW99+AsJ4lC8fA5SSx/ra20AvjyrHWDiPQsKsUJtXy4jIjvogYT3acTylLrY3Py6OrvTR8fQ== 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 08/01/25 7:00 pm, David Hildenbrand wrote: > On 08.01.25 07:09, Dev Jain wrote: >> >> 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. > > What exactly do we want to achieve with the write? Verify that the > output of /proc/self/map is reasonable and we can actually resolve a > fault / map a page? > > Why not access the memory directly+signal handler or using > /proc/self/mem, so you can avoid the temp file completely? > We want to determine whether an address belongs to our address space. The proper way to do that is to access the memory, get a segfault and jump to signal handler. I wanted to avoid this code churn, so chose to use write() so that I can validate the address without getting a segfault.