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 E199DE7719E for ; Mon, 13 Jan 2025 09:09:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 516D06B007B; Mon, 13 Jan 2025 04:09:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4C61F6B0083; Mon, 13 Jan 2025 04:09:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B4666B0085; Mon, 13 Jan 2025 04:09:32 -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 1C09D6B007B for ; Mon, 13 Jan 2025 04:09:32 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B0C5381048 for ; Mon, 13 Jan 2025 09:09:31 +0000 (UTC) X-FDA: 83001855342.22.8289172 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf23.hostedemail.com (Postfix) with ESMTP id C082814000D for ; Mon, 13 Jan 2025 09:09:29 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=mcaohpNQ; dkim=pass header.d=linutronix.de header.s=2020e header.b=k+8qHVUq; spf=pass (imf23.hostedemail.com: domain of t-8ch@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=t-8ch@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736759370; 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=iaLJCE3hZZaKYg76kr4H+6YhZeYEIBWjz6gvokJ8d2w=; b=WpQjF42qRdme4GqKLo+3QGzyfezxJElSWREE6Jbr0BhvD+izT0m7+mr/MZ9NJIz952ICCr OZUgRple4T3oEKGNSR+dF3vUcBRohN1f8HPSZ7+Gg3yI1O43m7pYvRA1VkJTPA4Tmb6rnH tcyNRR6Bku5ggzOLJqHt6kq51zZmc4I= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736759370; a=rsa-sha256; cv=none; b=C8OWpEziE0TqO2eUYC/3kuuR5v6m9Vfw4EL40shvT5cFRTrWfHsJbjDHCjk5G1NCYSw0rM +X7AQZqMWabh/ZnUHjt5WqagSgRIkB55vdNhb4u4qNgqkuXIr+CrJOV9BtcWyg1QSZvZdz +w/Da06Mrzi2yIC9kwZQrg8Lf9KP7mc= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=mcaohpNQ; dkim=pass header.d=linutronix.de header.s=2020e header.b=k+8qHVUq; spf=pass (imf23.hostedemail.com: domain of t-8ch@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=t-8ch@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de Date: Mon, 13 Jan 2025 10:09:25 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1736759367; h=from:from: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=iaLJCE3hZZaKYg76kr4H+6YhZeYEIBWjz6gvokJ8d2w=; b=mcaohpNQiMTCqKmmAsznrkto+jkaQNMg/3nkJ+6jZwFcZHMMOApc4jrv+kZUrAPmG9hvsU bfH377Lks/ZZ3sBmXDF0UR1SY5XI9YE2aI5k/kEb6W4TYt1VbQ+37gSXi5msPhM4c5EfcN X3eIB85RO23IIcoaFQupU8hiYHfWe7jlmqaJgRLM/nmlDGUfrIcu+OF06ZQ1hVjzpUgVzm TluqBiWyfFTAVDotMghElkSQdcOBCuIbEdJLHt0160+MkyLIYG+SZ7AluSej2p39EbQ3iQ 6UPbfqLifwvb+pjjilzujLFjJakXLEt15qJIwurWWULwoj92fZeHM9nKRQx1RQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1736759367; h=from:from: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=iaLJCE3hZZaKYg76kr4H+6YhZeYEIBWjz6gvokJ8d2w=; b=k+8qHVUq/yui+wPfgv7TJls0yz4ZNoWIiI0adnkZkh3awxwDlnU8ITZCt9jh7Tcd+JEkUz uz5RWe1Ro5KsXKDA== From: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= To: David Hildenbrand Cc: Andrew Morton , Shuah Khan , Dev Jain , Thomas Gleixner , linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, kernel test robot Subject: Re: [PATCH v2 3/3] selftests/mm: virtual_address_range: Avoid reading VVAR mappings Message-ID: <20250113095211-bde77070-8be1-4393-898e-22eff532189b@linutronix.de> References: <20250110-virtual_address_range-tests-v2-0-262a2bf3c3d0@linutronix.de> <20250110-virtual_address_range-tests-v2-3-262a2bf3c3d0@linutronix.de> <9243dd8e-3f03-4ed5-bdcf-95c947c57849@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9243dd8e-3f03-4ed5-bdcf-95c947c57849@redhat.com> X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: C082814000D X-Stat-Signature: bqxog3ehf8u8569goswedaxkyyjdi9n3 X-Rspam-User: X-HE-Tag: 1736759369-992576 X-HE-Meta: U2FsdGVkX19Xs8/5Eb5R9aKRhsMZrmS1XgBgDn4FMPoE5D5XjZM9cJLaUy/H8u+kn03FpmzQnTX+FN7PztM0iTwETY6jQuaENdwVGg3xpzbWanE7rCszbJJoKA3aLAdR1LmHq++NiAuKqtiW/z25i3aHxptpPJQbx8t7/KvGLxK5kTFdNa02DSgi20Jg0kfqZVIuoFkmaHwKnki7DqaC69M+4Fwbdt6IZMrbhSBCgyBXzWBbUvwWcVbMGX48mzRHuhpL3fzXMN1rIFq9VUw92os6axX5mfHyoRQ9VJTHeF55mBlL5VW/afAMlNlHa5sV5hQB+qgy43Pk8xU6LXHCT5+KJKOEcrmjEnanHc+S+SkRKf0M0MKdeS39EZ8+MvrAhvqtfwj2gQKPxW1vTZJNhDtYgsGzWczqPdC8FdXBKPv/cLGuGZ285dekCyGP0Ui+WgJ2yJvYxvkioyTnDeLz9w6uSTr3hi/rNNZwe8dY55mxv2rqb7tvhxA1K8iO3SnMRRVkmbaP0hUAOI132EnoQ1Cd2IXHQ5T/DHvMXxgfhW5Hxn6z01dYoM1C6Wv8UtjYtUVKaLaFsu59YFxX/uVY0UI6UHi24YWV6a6+Vz3k4mVwggzq6lmIM7Jqe+aAGgo2yMad8jAh2BrQz29pcPpfavNeAde3E1P3pcy7u+TYEjD/lWOqXZG5AIkTIYh47DcDAjQIgFKBYCKHsatSrPPe9rT7JFB26ZC6oNqF2P6Kgorrt3UcSCHv1pW5uA/7skr3VKFiQZ8/CEcEvTYEqkMeCKenReCSoJo/fJTG54Iz2qzJJlvHq/rhTYJwSkJ+H4Y88fhg+LyqOXoN9bkw23wXeh+zov5Kg+ApEfdqt+k22xC6ACtxfZGao+8aix/hii/HnsaNf7lpeJ8unTiqFdk8nZ/4HRmlooFe0ET5l6GPclFRrhVSlnHc45tnd4GdFVY7Z2tJiJopOLyPhUiEoPy b9fdQWgr TF77kE3hGhepPm+JijXk4NFXw3tK7KJnTqJj4ETmE41iHrtHOHLrrtsK7IEohgx1kAjWg/VH2gxEiYako1pqoVXvQzJeiz4gBwTo5Q7AeKhpSi/CHiJ1LseuxohI+L0eWpk6qmdrEe1GT7lB/yhCTw5sT3ipxSWF5SKpT/EWHhn3MdueNglxl/pDkGLq+IFc0wcZEsVN/hDyP7sp38Gb9rJCZKjMvwk+tpuyKP/wlz7rel0uS6zDl73BGQxIYsLBST/zyJycIIuteQcbZmH24ZFXMnWBtWL+8D3AdySemGJMbjeprcbXpWyZ1849Z9aZGw30zgqGH69Kn0Dy/tT+n10jcXHjAOmNjxixtDlbXJ29JukGg8YUdd9/mq5StJU6/pS0VCic2A8R4NwC8qzIHhVwVa8OnbpYpTN0dsYx5DSKcScMQYfE6a/XV0UuTnQOspWlZQGRmWWsYDvgteRff1M4gFOBWpzveSysQTb5AaIlpY2/bN/mLDX9vRg== 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, Jan 10, 2025 at 04:41:03PM +0100, David Hildenbrand wrote: > On 10.01.25 14:05, Thomas Weißschuh wrote: > > The virtual_address_range selftest reads from the start of each mapping > > listed in /proc/self/maps. > > However not all mappings are valid to be arbitrarily accessed. > > For example the vvar data used for virtual clocks on x86 [vvar_vclock] > > can only be accessed if 1) the kernel configuration enables virtual > > clocks and 2) the hypervisor provided the data for it. > > Only the VDSO itself has the necessary information to know this. > > Since commit e93d2521b27f ("x86/vdso: Split virtual clock pages into dedicated mapping") > > the virtual clock data was split out into its own mapping, leading > > to EFAULT from read() during the validation. > > > > Skip the various vvar mappings in virtual_address_range to avoid the issue. > > > > Fixes: e93d2521b27f ("x86/vdso: Split virtual clock pages into dedicated mapping") > > Fixes: 010409649885 ("selftests/mm: confirm VA exhaustion without reliance on correctness of mmap()") > > Reported-by: kernel test robot > > Closes: https://lore.kernel.org/oe-lkp/202412271148.2656e485-lkp@intel.com > > Signed-off-by: Thomas Weißschuh > > --- > > tools/testing/selftests/mm/virtual_address_range.c | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/tools/testing/selftests/mm/virtual_address_range.c b/tools/testing/selftests/mm/virtual_address_range.c > > index 4fc1c21a5e218eaec4d059b75c31a21dd4e8a215..993990aba56fc986c42084ffa91973558aa07e87 100644 > > --- a/tools/testing/selftests/mm/virtual_address_range.c > > +++ b/tools/testing/selftests/mm/virtual_address_range.c > > @@ -152,6 +152,10 @@ static int validate_complete_va_space(void) > > if (prot[0] != 'r') > > continue; > > + /* Only the VDSO can know if a VVAR mapping is really readable */ > > + if (vma_name && !strncmp(vma_name, "[vvar", 5)) > > + continue; > > I'm wondering if there is a more generic way ... but likely not when staring > at /proc/self/maps. > > /proc/self/smaps would indicate this as > > VM_IO: "io" > VM_DONTDUMP: "dd" > VM_PFNMAP: "pf" > > Especially checking for VM_IO sounds reasonable ... Agreed. Can we instead rely on madvise(MADV_DOFORK) returning EINVAL iff VM_IO? That would remove the need for custom parsing and the dependency on CONFIG_PROC_PAGE_MONITOR. Thomas