linux-kernel - Re: [PATCH 1/1] ARM: dma: fix dma_max

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 18 Aug 2016 15:24:59 +0100
From:	Russell King - ARM Linux <linux@...linux.org.uk>
To:	Roger Quadros <rogerq@...com>
Cc:	ssantosh@...nel.org, grygorii.strashko@...com,
	linux-arm-kernel@...ts.infradead.org, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>,
	Catalin Marinas <catalin.marinas@....com>,
	Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH 1/1] ARM: dma: fix dma_max_pfn()

On Wed, Aug 17, 2016 at 03:05:17PM +0300, Roger Quadros wrote:
> Since commit 6ce0d2001692 ("ARM: dma: Use dma_pfn_offset for dma address translation"),
> dma_to_pfn() already returns the PFN with the physical memory start offset
> so we don't need to add it again.
> 
> This fixes USB mass storage lock-up problem on systems that can't do DMA
> over the entire physical memory range (e.g.) Keystone 2 systems with 4GB RAM
> can only do DMA over the first 2GB. [K2E-EVM].
> 
> What happens there is that without this patch SCSI layer sets a wrong
> bounce buffer limit in scsi_calculate_bounce_limit() for the USB mass
> storage device. dma_max_pfn() evaluates to 0x8fffff and bounce_limit
> is set to 0x8fffff000 whereas maximum DMA'ble physical memory on Keystone 2
> is 0x87fffffff. This results in non DMA'ble pages being given to the
> USB controller and hence the lock-up.
> 
> NOTE: in the above case, USB-SCSI-device's dma_pfn_offset was showing as 0.
> This should have really been 0x780000 as on K2e, LOWMEM_START is 0x80000000
> and HIGHMEM_START is 0x800000000. DMA zone is 2GB so dma_max_pfn should be
> 0x87ffff. The incorrect dma_pfn_offset for the USB storage device is because
> USB devices are not correctly inheriting the dma_pfn_offset from the
> USB host controller. This will be fixed by a separate patch.

I'd like to hear from Santosh, as the author of the original change.
The original commit doesn't mention which platform it was intended for
or what the problem was, which would've been helpful.

> 
> Fixes: 6ce0d2001692 ("ARM: dma: Use dma_pfn_offset for dma address translation")
> Cc: stable@...r.kernel.org
> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Cc: Russell King <linux@....linux.org.uk>
> Cc: Arnd Bergmann <arnd@...db.de>
> Cc: Olof Johansson <olof@...om.net>
> Cc: Catalin Marinas <catalin.marinas@....com>
> Cc: Linus Walleij <linus.walleij@...aro.org>
> Reported-by: Grygorii Strashko <grygorii.strashko@...com>
> Signed-off-by: Roger Quadros <rogerq@...com>
> ---
>  arch/arm/include/asm/dma-mapping.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
> index d009f79..bf02dbd 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -111,7 +111,7 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
>  /* The ARM override for dma_max_pfn() */
>  static inline unsigned long dma_max_pfn(struct device *dev)
>  {
> -	return PHYS_PFN_OFFSET + dma_to_pfn(dev, *dev->dma_mask);
> +	return dma_to_pfn(dev, *dev->dma_mask);
>  }
>  #define dma_max_pfn(dev) dma_max_pfn(dev)
>  
> -- 
> 2.7.4
> 

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.