Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp5399408pxv; Wed, 28 Jul 2021 09:48:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwDTnqFuKl7xcELoO8rw76xErPYnZ3xfvYcYgAzEURzefPr1oHUFF6Wf39GWXn86Ifnzhq/ X-Received: by 2002:a17:906:c304:: with SMTP id s4mr397771ejz.346.1627490918318; Wed, 28 Jul 2021 09:48:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627490918; cv=none; d=google.com; s=arc-20160816; b=X/3OTv9cfP9azirEghGEGs3H1VukPhhIbOEbXBOudfeGajvFGOuwGjrBK3jdshrmX0 LiYAMyZLs6hl443XkNzHBuL8BsJRTcUsoz+pUKYXoKSP794vqaPLTPqlg9Aq8q7Lk0Bm dHIaauIkiliYvAeQVKBt/2FFfMg814Sj8mkQac+0lnfo7D3tuFTMdcCnUVDxFElgECiL MnuSiEMQsBfDYP5l9QcfryhHr6OSjWFmN1DScLBU2JQA5mpGj1/BGNucPYOfykZgCVOR fE82W6fA+qXjFavoeq58N5vEbrzwIE5N3ZUJh/nReejIxZyhn55KZCHpEydaXhLQBn1s Ezkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from :dkim-signature; bh=cu87lLWCb/og9yKEYQ/1elWEpVqvoxE21CQJJHueP+0=; b=BwKxcJ/eRezBcI/5v3YKcvMiXupWOc1norYMfWXA/1qx65k4PRZiaclPzBrBo/wXLK hHcZuWFaaMyE74AJm59RA5384eneuOKmK0YxzzIqEd8/uSOKJaK6KnHj+vuPn31Cj0oa R1JDnxMh8NZBapKasviiVF32fXHgSOiFhgv9CF/99/1FkoOaL8xtsh7Z9GV1MfOvhPxc CKEV9+2HDP2H2/sE9rZKg8Y50ZpyZpAg/zFC/b3hHt4XydHlce1etKcYm1TonuhWmob0 G9CdmQhjTs3qeG3p8df4x3FFwGEgpouLxqbtR+UmIkZ3m1otnXdmRd9pr86hnpUZoGVn wQFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=FHIXga3o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dy10si146123edb.218.2021.07.28.09.48.15; Wed, 28 Jul 2021 09:48:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=FHIXga3o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229900AbhG1QoW (ORCPT + 99 others); Wed, 28 Jul 2021 12:44:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42498 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229591AbhG1QoW (ORCPT ); Wed, 28 Jul 2021 12:44:22 -0400 Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 91682C061757 for ; Wed, 28 Jul 2021 09:44:19 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id m13so5094698lfg.13 for ; Wed, 28 Jul 2021 09:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=cu87lLWCb/og9yKEYQ/1elWEpVqvoxE21CQJJHueP+0=; b=FHIXga3odQp+zLXPGxkus6RYPXim/grUE/TJUokmc2WyCK6a9FTBP6ANBqTc19IM4D qRrjKSrS7fnqS9IjugtabnFK9IBGowRnoJ1Krjt5e6+S1I+zuUkNzQkWz+UFLfHt0XdO Oo47DUwjG5pwEgtsL9zkctyobUhqFY3T/dKCn7pU9kxH9k7N0i4HqJ5QEQhTX1z2RgHm Fmu3uu2Tc9Y+bkumIVTFgivn9mzbhd4rEvIS8/6oC6V2bWT1Kjc0GrZFOsLFeRlku+dk tv6KX3rx449HOH8Z+CEg6hUgFFt+UWsiqLP2PbJbe/dqK1rqLURMuL9s6Cr+lhLyw9Fi LqDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=cu87lLWCb/og9yKEYQ/1elWEpVqvoxE21CQJJHueP+0=; b=SwV6ChfZ7PzYxOhoCYGlIlbkDcS5Cb7jg1Cyh84OBMKFmL/dyRZ+DaOCXfgz1CwYdR 3G1qkI3JXxfNCN5xodbkMy2pwiGFVqmu/HZou+cBPYVVaGIr5x20IDZ6aFogGPyw0cz1 ts6szswVX+SRlSZtPpKaYqOFUP4DyUB1I8BUmcN4+z3QMcooY8+cbp/MkA4mkTNmxLmA lyxYUEtx2Dfuj6untJ9ueMBRBhIxgjj5KUcMeqfvOpsJqsWBC3kDeV1k+5+ptQlp//WK 53QMAQUXhxvtfzJNb/P78YgbSPyv8RioI55veP7USAwa6FtXN5iiBG8IIhX9JKFbMuyR WlPQ== X-Gm-Message-State: AOAM530pNv5t+3Zij3WB5XYOqwYq/sCI5q1rf+b8UJMLJjVErXH7T4wO I932hrxWBZ/kjDQA1Z774iU= X-Received: by 2002:a19:ac01:: with SMTP id g1mr368833lfc.301.1627490657980; Wed, 28 Jul 2021 09:44:17 -0700 (PDT) Received: from otyshchenko.router ([212.22.223.21]) by smtp.gmail.com with ESMTPSA id r200sm45673lff.208.2021.07.28.09.44.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jul 2021 09:44:17 -0700 (PDT) From: Oleksandr Tyshchenko To: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Cc: Oleksandr Tyshchenko , Catalin Marinas , Will Deacon , Andrey Konovalov , Ard Biesheuvel , Vincenzo Frascino , Joey Gouly , Sami Tolvanen , Mark Rutland , Juergen Gross , Julien Grall , Wei Chen , Stefano Stabellini Subject: [RFC PATCH 1/2] arm64: mm: Make virt_addr_valid to check for pfn_valid again Date: Wed, 28 Jul 2021 19:44:15 +0300 Message-Id: <1627490656-1267-1-git-send-email-olekstysh@gmail.com> X-Mailer: git-send-email 2.7.4 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Oleksandr Tyshchenko The problem is that Arm's implementation of virt_addr_valid() leads to memblock_is_map_memory() check, which will fail for ZONE_DEVICE based addresses. But, the pfn_valid() check in turn is able to cope with ZONE_DEVICE based memory. You can find a good explanation of that problem at: https://lore.kernel.org/lkml/1614921898-4099-2-git-send-email-anshuman.khandual@arm.com Signed-off-by: Oleksandr Tyshchenko --- I am not quite sure whether it is a "correct" place and the change itself, I just partially restored a behaviour before: https://lore.kernel.org/lkml/20210511100550.28178-4-rppt@kernel.org So, the target of this patch is to get a feedback how to resolve this properly if, of course, this really needs to be resolved (I might miss important bits here). It is worth mentioning that patch doesn't fix the current code base (if I am not mistaken, no one calls virt_addr_valid() on Arm64 for ZONE_DEVICE based addresses at the moment, so it seems that nothing is broken), the fix is intended for the subsequent patch in this series that will try to enable Xen's "unpopulated-alloc" usage on Arm (it was enabled on x86 so far). Please see: [RFC PATCH 2/2] xen/unpopulated-alloc: Query hypervisor to provide unallocated space The subsequent patch will enable the code where virt_addr_valid() is used in drivers/xen/unpopulated-alloc.c:fill_list() to check that a virtual address returned by memremap_pages() is valid. --- arch/arm64/include/asm/memory.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h index 824a365..1a35a44 100644 --- a/arch/arm64/include/asm/memory.h +++ b/arch/arm64/include/asm/memory.h @@ -351,7 +351,7 @@ static inline void *phys_to_virt(phys_addr_t x) #define virt_addr_valid(addr) ({ \ __typeof__(addr) __addr = __tag_reset(addr); \ - __is_lm_address(__addr) && pfn_is_map_memory(virt_to_pfn(__addr)); \ + __is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr)); \ }) void dump_mem_limit(void); -- 2.7.4