From patchwork Mon Mar 21 03:46:23 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Florian Fainelli X-Patchwork-Id: 12786769 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AF03DC433F5 for ; Mon, 21 Mar 2022 03:47:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Subject:From:To:MIME-Version:Date:Message-ID: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=M4SDHfFTKkE2cwp2GGtKqiW2Ffb4iUijvNAtSS99ICI=; b=BcBUB6jeTpmdOe 7OrZoNJCC8fvdlSmkDCS1sqmCuUUxG6SZJ0lMREGAA1cu6G5Z7l7mJifPv8Ht2h379LDwnO/e0ujO NIOhuahPk+gvsz0VIs9EtIq8yg6c2ZOgauUslK0bKz8Bd0P4eND58FRB23kRXYLxnnhrGqEpQE39k 2yMlP3sHuZ/qvB+0SRagNl2WRn4Q8xC9qr9BWFDTO2S7o+PynexXLXlAy7kyv5dRUetL8loItnEvF 7OP9oAHbiCjRnbOTNaUZBpjby14EHGB0K9CBy0anb9DyT2NypVGrMkygf/wi1O5CHJSLs1iXr4MU6 2zg3SvICkHBcd/H3y3EQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nW904-006P8g-MF; Mon, 21 Mar 2022 03:46:32 +0000 Received: from mail-pg1-x531.google.com ([2607:f8b0:4864:20::531]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nW901-006P8O-Cv for linux-arm-kernel@lists.infradead.org; Mon, 21 Mar 2022 03:46:30 +0000 Received: by mail-pg1-x531.google.com with SMTP id o23so9428224pgk.13 for ; Sun, 20 Mar 2022 20:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to:from :subject:content-transfer-encoding; bh=XB86LSvbUcjCdcYa/JaUbtm7Z1ArxjB1Ow9r+Sn3Is4=; b=TLV1NbJ9vG2B4qNJrlq3m/zeD86MlSO7JcXd485xaTiqjx5nX5jYXZSX57b1sM4afK cPcApm9ZBmurZabgmCrsxbilEJjc11lth8SbhujTA5mGu7l8pzWoYb4Fo20OlBt71zvL 4zJnJUEhag+BunLfG56S9lnBZ78/Mq6Z0R1u3InO1ZCKmFpdbi+PVXYEVta71YYxJHtc 05btwyutMrQBDr6qFz3eB7fBVHPEzc3l3uNE+/rUc6r++GbcH27Y0nqNAmUwNzeN0/a1 I2vYlei6q5xxXeYBE8tjzpi+mCcpr9Sz4x8m1FgM2GehCYGod9pX+sgRd26fyjGK6IMz Uxmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:from:subject:content-transfer-encoding; bh=XB86LSvbUcjCdcYa/JaUbtm7Z1ArxjB1Ow9r+Sn3Is4=; b=6j9iMDuuA2jFFn19u400GPAAlL+aFeSuflxagBEYn5xqSPP2Ll65cm/zj7+nUwTX2H pHPjgNAn2n18ID5HN4C6YhlMKul1L0MentRgNU6SpCAUL2KycQzLJonifwW7HIuL1u9r YD4ZIhyCxvl8Xc+J6oGtNyFkKrq2ihwdeZCoznHeo4yyoQ8o/iQZuZsoq8DDuIm+U8MY 0P8SvrwT701y8pF3NYZPFBpxJgSb4CFdo6eGkXhzz9BZC9oa/RpxQqNsau8QVTG9TLhO y9OxKVCJDDRl/YdPKmM4dxYr+3oQ6CPmOyZX6pD5vK1gVq9+KJS7pt/hGTAI+gYjw6fo OYbA== X-Gm-Message-State: AOAM533InjaN5jpRdAIIjd+WRe/zRj9+6JPJUjx3FUlhRlQvRVwYdjsX 4m6HVLChmMKy+xylULZUeiazdUxnxPL9GA== X-Google-Smtp-Source: ABdhPJzPdipQxa9fPBHzcPMtHRs7O3m+Iierf9Ehum96oYcDXw+H0R3RzJ4psZPnvv+NkSYscBgPzA== X-Received: by 2002:a05:6a00:194e:b0:4fa:a7e7:a9d1 with SMTP id s14-20020a056a00194e00b004faa7e7a9d1mr1013674pfk.44.1647834385332; Sun, 20 Mar 2022 20:46:25 -0700 (PDT) Received: from ?IPV6:2600:8802:b00:4a48:973:820a:d36c:f7ee? ([2600:8802:b00:4a48:973:820a:d36c:f7ee]) by smtp.gmail.com with ESMTPSA id p11-20020a17090a4f0b00b001c6e4898a36sm5025521pjh.28.2022.03.20.20.46.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 20 Mar 2022 20:46:24 -0700 (PDT) Message-ID: <41c9bb67-3f80-510f-9904-a568a865b0ea@gmail.com> Date: Sun, 20 Mar 2022 20:46:23 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: linux-arm-kernel , Russell King , Nicolas Pitre , "linus.walleij" From: Florian Fainelli Subject: MAX_DMA_ADDRESS overflow with non-zero arm_dma_zone_size and VMSPLIT_3G X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220320_204629_490295_9CE57452 X-CRM114-Status: UNSURE ( 9.55 ) X-CRM114-Notice: Please train this message. X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi all, While debugging numerous KASAN splats with CONFIG_DEBUG_VIRTUAL on ARM 32-bit with a Raspberry Pi 4B 4GB, it finally clicked that the problem is with the use of __virt_to_phys(MAX_DMA_ADDRESS). Since that platform has CONFIG_ZONE_DMA enabled, we end-up with: #define MAX_DMA_ADDRESS ({ \ extern phys_addr_t arm_dma_zone_size; \ arm_dma_zone_size && arm_dma_zone_size < (0x10000000 - PAGE_OFFSET) ? \ (PAGE_OFFSET + arm_dma_zone_size) : 0xffffffffUL; }) and with arch/arm/mach-bcm/bcm2711.c defining a dma_zone_size of SZ_1G and PAGE_OFFSET = 0xC000_0000 we end up with MAX_DMA_ADDRES of 0x1_0000_0000 which overflows the virtual address size that is represented with an unsigned long. All of the virt_to_phys() and related functions either take a pointer size argument (const volatile void *) or an unsigned long argument and these are virtual addresses so unable to go over 32-bit anyway. Since MAX_DMA_ADDRESS is intended to be "This is the maximum virtual address which can be DMA'd from.", should we make sure that we clamp it below 32-bit in case it overflows? The splats can be silenced with this too: return false; but this does not permit differentiating a 0 virtual address from MAX_DMA_ADDRESS having overflowed. Thanks! diff --git a/arch/arm/mm/physaddr.c b/arch/arm/mm/physaddr.c index cf75819e4c13..abf071c7c6e9 100644 --- a/arch/arm/mm/physaddr.c +++ b/arch/arm/mm/physaddr.c @@ -29,7 +29,7 @@ static inline bool __virt_addr_valid(unsigned long x) * actual physical address. Enough code relies on __pa(MAX_DMA_ADDRESS) * that we just need to work around it and always return true. */ - if (x == MAX_DMA_ADDRESS) + if (x == (unsigned long)MAX_DMA_ADDRESS) return true;