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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 68FA0C433EF for ; Fri, 29 Apr 2022 15:15:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1377963AbiD2PTM (ORCPT ); Fri, 29 Apr 2022 11:19:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42850 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1378276AbiD2PTE (ORCPT ); Fri, 29 Apr 2022 11:19:04 -0400 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 108F4240A1 for ; Fri, 29 Apr 2022 08:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=PLXUVQiV7tikz3YNBMnVyAjxTBooCtamS/BcdAwgm1c=; b=YICZspGI9E6FIZ2AFbKUKz+xsP FS5Dji1YinHJh1pOrKjcscS3Hst7bhQa/f4W/7D3nsngsYMaZ8NdoDBSR2CQ7e7wjot+AmpaNiL98 vHLPr3wG9o1OWVzEqdsiegQMQz1SveLe7UUy1Q9y8QfvbNRFAFdbiBiAQkYtWgNXrZTsByc5t26Po Idgv6LpfC23p85e+5E6h+vZZduGPLxInEkVTXD/jVrNrQHh5xhqlqohQ5gt5BtweG8+paKpK+WWZK IZjr4YstZ6jcMZYYUmNx/FaqMPUnzT2oXBzYOtQi5YNErX5X5j+kAtoqxwqM/PtI4ksRS2ryuTvJ9 376nWAXQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:58440) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nkSLM-0004Ak-NE; Fri, 29 Apr 2022 16:15:40 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1nkSLK-00022a-RO; Fri, 29 Apr 2022 16:15:38 +0100 Date: Fri, 29 Apr 2022 16:15:38 +0100 From: "Russell King (Oracle)" To: Florian Fainelli Cc: linux-arm-kernel@lists.infradead.org, Geert Uytterhoeven , Nicolas Pitre , Catalin Marinas , open list , linus.walleij@linaro.org, Rob Herring , Ard Biesheuvel Subject: Re: [PATCH 1/2] ARM: Fix off by one in checking DMA zone size Message-ID: References: <20220324175417.1014562-1-f.fainelli@gmail.com> <20220324175417.1014562-2-f.fainelli@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220324175417.1014562-2-f.fainelli@gmail.com> Sender: Russell King (Oracle) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 24, 2022 at 10:54:16AM -0700, Florian Fainelli wrote: > The maximum DMA address is PAGE_OFFSET + arm_dma_zone_size - 1, fix this > by doing the appropriate subtraction. The question is... is MAX_DMA_ADDRESS inclusive or exclusive. The answer is rather indeterminant, unfortunately. drivers/net/wan/cosa.c: if (b + len >= MAX_DMA_ADDRESS) So, if the buffer address + buffer length is equal to MAX_DMA_ADDRESS, then the buffer is not DMA-able. To me this looks completely wrong. It's also completely wrong because 'b' is a "unsigned long" which means on 32-bit, this can wrap. drivers/parport/parport_pc.c: unsigned long start = (unsigned long) buf; unsigned long end = (unsigned long) buf + length - 1; if (end < MAX_DMA_ADDRESS) { So, "end" is the last byte of the buffer. If MAX_DMA_ADDRESS is the last byte of the virtual address space that supports DMA, then if the two are equal, we do not use DMA. This seems wrong to me, and points to it being an _exclusive_ value - it's the last byte plus one. there's a bunch of memblock allocation functions that use __pa(MAX_DMA_ADDRESS) as the "min_addr" and if this is a minimum address, then surely this means that it is also an exclusive value. So, I came to the conclusion that MAX_DMA_ADDRESS is supposed to be exclusive. In other words, where PAGE_OFFSET + sizeof(ram) if sizeof(ram) is the size in bytes of the RAM, limited to the maximum addressable virtual address that RAM can be mapped to. I don't see an inclusive value being correct, at least not for the cases I've looekd at. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! 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 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 6EDA7C433F5 for ; Fri, 29 Apr 2022 15:16: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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=qa2cqqaFFjAn2SvX1mY0GZUZTr06oG5ikQ5RccRnnTM=; b=30TBGdedVWWAfq MR2Asdu++vZJsGMEZ8cgdm8JYDU4X6OEuD28JSmgdlUYmmGvMjdkRmNuXM2fwzXM0VWTiZDD2i8+V NaWOTbWdp0tLImNJ6ZXm8PwLhzGktMIC2oHH1UIlUuNk+I0b/H95CbnRVzH//rZv5LnNhkyiVqicO FaXQDiOIrpHXeyN5RLpYf1zHBC9k8nQEN92kbL53CnsxKjPwcKqyjdn/W4S7APPnVYePMS3BV2D1O 1lqeF6/STidUd8yPlAMeXIuXtZ3iApEtCsquUIRtRUOryp7v4BICW9vKxIeQHXbHSaOXq5e7zPoaF c7B2VlMj6sIb3tyXgZ4g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nkSLT-00BjSo-02; Fri, 29 Apr 2022 15:15:47 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nkSLP-00BjS8-Tv for linux-arm-kernel@lists.infradead.org; Fri, 29 Apr 2022 15:15:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=PLXUVQiV7tikz3YNBMnVyAjxTBooCtamS/BcdAwgm1c=; b=YICZspGI9E6FIZ2AFbKUKz+xsP FS5Dji1YinHJh1pOrKjcscS3Hst7bhQa/f4W/7D3nsngsYMaZ8NdoDBSR2CQ7e7wjot+AmpaNiL98 vHLPr3wG9o1OWVzEqdsiegQMQz1SveLe7UUy1Q9y8QfvbNRFAFdbiBiAQkYtWgNXrZTsByc5t26Po Idgv6LpfC23p85e+5E6h+vZZduGPLxInEkVTXD/jVrNrQHh5xhqlqohQ5gt5BtweG8+paKpK+WWZK IZjr4YstZ6jcMZYYUmNx/FaqMPUnzT2oXBzYOtQi5YNErX5X5j+kAtoqxwqM/PtI4ksRS2ryuTvJ9 376nWAXQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:58440) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nkSLM-0004Ak-NE; Fri, 29 Apr 2022 16:15:40 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1nkSLK-00022a-RO; Fri, 29 Apr 2022 16:15:38 +0100 Date: Fri, 29 Apr 2022 16:15:38 +0100 From: "Russell King (Oracle)" To: Florian Fainelli Cc: linux-arm-kernel@lists.infradead.org, Geert Uytterhoeven , Nicolas Pitre , Catalin Marinas , open list , linus.walleij@linaro.org, Rob Herring , Ard Biesheuvel Subject: Re: [PATCH 1/2] ARM: Fix off by one in checking DMA zone size Message-ID: References: <20220324175417.1014562-1-f.fainelli@gmail.com> <20220324175417.1014562-2-f.fainelli@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220324175417.1014562-2-f.fainelli@gmail.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220429_081544_006312_571001AF X-CRM114-Status: GOOD ( 14.69 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Mar 24, 2022 at 10:54:16AM -0700, Florian Fainelli wrote: > The maximum DMA address is PAGE_OFFSET + arm_dma_zone_size - 1, fix this > by doing the appropriate subtraction. The question is... is MAX_DMA_ADDRESS inclusive or exclusive. The answer is rather indeterminant, unfortunately. drivers/net/wan/cosa.c: if (b + len >= MAX_DMA_ADDRESS) So, if the buffer address + buffer length is equal to MAX_DMA_ADDRESS, then the buffer is not DMA-able. To me this looks completely wrong. It's also completely wrong because 'b' is a "unsigned long" which means on 32-bit, this can wrap. drivers/parport/parport_pc.c: unsigned long start = (unsigned long) buf; unsigned long end = (unsigned long) buf + length - 1; if (end < MAX_DMA_ADDRESS) { So, "end" is the last byte of the buffer. If MAX_DMA_ADDRESS is the last byte of the virtual address space that supports DMA, then if the two are equal, we do not use DMA. This seems wrong to me, and points to it being an _exclusive_ value - it's the last byte plus one. there's a bunch of memblock allocation functions that use __pa(MAX_DMA_ADDRESS) as the "min_addr" and if this is a minimum address, then surely this means that it is also an exclusive value. So, I came to the conclusion that MAX_DMA_ADDRESS is supposed to be exclusive. In other words, where PAGE_OFFSET + sizeof(ram) if sizeof(ram) is the size in bytes of the RAM, limited to the maximum addressable virtual address that RAM can be mapped to. I don't see an inclusive value being correct, at least not for the cases I've looekd at. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel