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 EB37EC3ABB2 for ; Wed, 28 May 2025 10:53:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 786BB6B0083; Wed, 28 May 2025 06:53:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 70FB76B0088; Wed, 28 May 2025 06:53:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5FF106B0089; Wed, 28 May 2025 06:53:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 41BC96B0083 for ; Wed, 28 May 2025 06:53:26 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E1E0D1408DB for ; Wed, 28 May 2025 10:53:25 +0000 (UTC) X-FDA: 83492005170.29.1C8671F Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf28.hostedemail.com (Postfix) with ESMTP id 3CAA6C0006 for ; Wed, 28 May 2025 10:53:24 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf28.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748429604; 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=fXmsr1V1M/8I+X7zegAoffsaB3EtR/U1/VlJ0SRBAvQ=; b=FO2NCwi4tSZL+KU0iRTTqk9CV73ZjmY5jLAt5XBId4bmQRqbFbiHy3WJuQJz62bXC02P6a jzGWEK0XlSPNrwPcRQleUB5QilpvqhX6nanCeoesjn+v3pTKG/fZkIWN8nMV6iw0rFsqdo osScAiJnAFNw5XYqTp7qSEIHiNIud1k= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf28.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748429604; a=rsa-sha256; cv=none; b=gVJAmv2YwrHM5GBmEHkmV0dxm/iLJnKhDYs3SLDBO7Avlyuhqu1c0L1wKl0SyMgaiGK26A w5alehcGivXO0/Wa5FF6pu+l3ELFuq04RODUn55FOxROtszYOdZZDLMNPwfyzlOQRNRXMP j+sIiObX6aZcjwFv73jXA8eopGOHn5k= 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 F33FA150C; Wed, 28 May 2025 03:53:06 -0700 (PDT) Received: from [10.57.94.142] (unknown [10.57.94.142]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C03483F5A1; Wed, 28 May 2025 03:53:21 -0700 (PDT) Message-ID: Date: Wed, 28 May 2025 11:53:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] selftests/mm: add simple VM_PFNMAP tests based on mmap'ing /dev/mem Content-Language: en-GB To: David Hildenbrand , linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Andrew Morton , Shuah Khan , Lorenzo Stoakes , Ingo Molnar , Peter Xu , Dev Jain , Aishwarya TCV References: <20250509153033.952746-1-david@redhat.com> <232960c2-81db-47ca-a337-38c4bce5f997@arm.com> <7cb7f23a-ce9e-4664-8083-deb73ed23da3@redhat.com> <3c15a093-7c19-4c2a-a571-56a5ed4b445f@redhat.com> From: Ryan Roberts In-Reply-To: <3c15a093-7c19-4c2a-a571-56a5ed4b445f@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: 3CAA6C0006 X-Rspamd-Server: rspam09 X-Stat-Signature: h1byy8xewwyy15hi1f3xy1e84rud1uyr X-HE-Tag: 1748429604-636500 X-HE-Meta: U2FsdGVkX1/tD3bNuDMsRX0A/uWqReLg9yP6ylUEbGFwZBzssID6UMzIRYC+bWchtjhklNNKjnbUG3pjpFuzTa1OZVH6fyAPzOL5vlJ8svymrViTEq7GwwyHkTraffiDRksLCu1nFt8IJvy/Iy128fYuNosLT8R/0aKX8s9MwaQbPgGmJ5immp50wE7S1AvFmFQoF8aMa4JVJY5O/QenhQqrumgymJNMzAZGtFpv57SawZ96Zl24HPwzInyp4v8Iii5eKzy1ND2/YvXSJN15MY2mrpamiSkgQKmliadxcCRPwdFGZC2Nd2VgaW/0jKvacBF31uQmgp8EM5HscjZVUXOMymz1Yrzy/F0OW5/PfUUU1sn400HgrW4tGUkYoWI5DFwwP36pQI+JBZfFXUIUnqr9qFJ14WYILmFSH61Q8ZeyaHAScDUXU+B8NmvLlUiZbKhTZLm2pJXdovTf8L2fU7gNKBHcUZejiOGRd5NWA7k+808SKLJo06ILUc2WkrjoeNL47yYV73YM4iru64LlNqiLGeoilbbyVMpXQLUpmDZ9FM4RodzqqCm7dQtMLXr3xMyMhltoqFmTqmzx//eU5+ps3Uf8wyC9XYKEzxETS1BftHCzh6BKGP3GIgYUUy8iwv5CSSFIaJb0+Y4fF/kHnPYRUCg1mHK+yvYApKD+KOlMtu3I0yyYUJDA6reGARj5/oMq1CFOl7m8WuAOZbDzjn0T0KlffH4Ojkiz9TdVgTMpuIbP/68norShuj17fVKjfm2A35uQHh9yWGSdRvfQX9aDXx/RKPGBKxBwa4QkXsOsY3AFp/QWC01vJpztLLN+g3y9rvyzPd3k0knAyM7CkMd25UvD3b+yHtSTG5kNBjNZsjpsMtvUsmBTaS83ozu6WhV8mayvfVPHGnbfQYv5t1y2671xGE14tdNOdoohU3wEN6X38IW1ir2UkAihRx7OSgUzZgvnAxSIg/scunl NDp/ukSk i9fcdBmle44PkC8k1ZqwT3kJE1dHR7IVGICvMShDXSnfzEYtJFkY3kWX/JH5U1SOZ+vacqjZ1+ZUFyksrKDlEVHNUSmSFdO7uf60hQ1Jc+h8VHzCfXxLr/pzWkaQQ7paYI56lMcZxEzzRALtI0WiHLwv1huBBHrPdtCUH01uKbazV/iglSnPf2/t06enhcj8+wjOh 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 28/05/2025 11:48, David Hildenbrand wrote: > On 28.05.25 12:44, David Hildenbrand wrote: >> On 28.05.25 12:34, Ryan Roberts wrote: >>> Hi David, >>> >>> >>> On 09/05/2025 16:30, David Hildenbrand wrote: >>>> Let's test some basic functionality using /dev/mem. These tests will >>>> implicitly cover some PAT (Page Attribute Handling) handling on x86. >>>> >>>> These tests will only run when /dev/mem access to the first two pages >>>> in physical address space is possible and allowed; otherwise, the tests >>>> are skipped. >>> >>> We are seeing really horrible RAS errors with this test when run on arm64 tx2 >>> machine. Based solely on reviewing the code, I think the problem is that tx2 >>> doesn't have anything at phys address 0, so test_read_access() is trying to put >>> trasactions out to a bad address on the bus. >>> >>> tx2 /proc/iomem: >>> >>> $ sudo cat /proc/iomem >>> 30000000-37ffffff : PCI ECAM >>> 38000000-3fffffff : PCI ECAM >>> 40000000-5fffffff : PCI Bus 0000:00 >>> ... >>> >>> Whereas my x86 box has some reserved memory: >>> >>> $ sudo cat /proc/iomem >>> 00000000-00000fff : Reserved >>> 00001000-0003dfff : System RAM >>> ... >>> >> >> A quick fix would be to make this test specific to x86 (the only one I >> tested on). We should always have the lower two pages IIRC (BIOS stuff etc). I'm not sure how far along this patch is? I'm guessing mm-stable? Perhaps you can do the quick fix, then I'd be happy to make this more robust for arm64 later? >> >>> I think perhaps the only safe way to handle this is to parse /proc/iomem for a >>> region of "System RAM" that is at least 2 pages then use that for your read >>> tests. This would also solve the hypothetical issue of reading something that >>> has read size effects. >> >> That sounds also plausible yes. I somehow remembered that mmap() would >> fail if "there is nothing". > > Ah, my memory comes back, we perform checks only with CONFIG_STRICT_DEVMEM. Ahh makes sense. I guess our config doesn't include this. I just checked the RAS error and it is for PA 0. So I'm confident that what I describe above is definitely what is happening.