linux-kernel - Re: [PATCH] powerpc: ensure that swiotlb buffer is allocated from low memory

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]

Message-ID: <87h82aqcju.fsf@mpe.ellerman.id.au>
Date:   Mon, 09 Dec 2019 16:43:17 +1100
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Mike Rapoport <rppt@...nel.org>, linux-kernel@...r.kernel.org
Cc:     linuxppc-dev@...ts.ozlabs.org, linux-arch@...r.kernel.org,
        linux-mm@...ck.org, iommu@...ts.linux-foundation.org,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Christian Zigotzky <chzigotzky@...osoft.de>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Christoph Hellwig <hch@....de>,
        Darren Stevens <darren@...vens-zone.net>,
        mad skateman <madskateman@...il.com>,
        Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
        Paul Mackerras <paulus@...ba.org>,
        Robin Murphy <robin.murphy@....com>,
        Rob Herring <robh+dt@...nel.org>
Subject: Re: [PATCH] powerpc: ensure that swiotlb buffer is allocated from low memory

Mike Rapoport <rppt@...nel.org> writes:
> From: Mike Rapoport <rppt@...ux.ibm.com>
>
> Some powerpc platforms (e.g. 85xx) limit DMA-able memory way below 4G. If a
> system has more physical memory than this limit, the swiotlb buffer is not
> addressable because it is allocated from memblock using top-down mode.
>
> Force memblock to bottom-up mode before calling swiotlb_init() to ensure
> that the swiotlb buffer is DMA-able.
>
> Link: https://lkml.kernel.org/r/F1EBB706-73DF-430E-9020-C214EC8ED5DA@xenosoft.de

This wasn't bisected, but I thought it was a regression. Do we know what
commit caused it?

Was it 25078dc1f74b ("powerpc: use mm zones more sensibly") ?

Or was that a red herring?

cheers

> Reported-by: Christian Zigotzky <chzigotzky@...osoft.de>
> Signed-off-by: Mike Rapoport <rppt@...ux.ibm.com>
> Cc: Benjamin Herrenschmidt <benh@...nel.crashing.org>
> Cc: Christoph Hellwig <hch@....de>
> Cc: Darren Stevens <darren@...vens-zone.net>
> Cc: mad skateman <madskateman@...il.com>
> Cc: Michael Ellerman <mpe@...erman.id.au>
> Cc: Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
> Cc: Paul Mackerras <paulus@...ba.org>
> Cc: Robin Murphy <robin.murphy@....com>
> Cc: Rob Herring <robh+dt@...nel.org>
> ---
>  arch/powerpc/mm/mem.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index be941d382c8d..14c2c53e3f9e 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -260,6 +260,14 @@ void __init mem_init(void)
>  	BUILD_BUG_ON(MMU_PAGE_COUNT > 16);
>  
>  #ifdef CONFIG_SWIOTLB
> +	/*
> +	 * Some platforms (e.g. 85xx) limit DMA-able memory way below
> +	 * 4G. We force memblock to bottom-up mode to ensure that the
> +	 * memory allocated in swiotlb_init() is DMA-able.
> +	 * As it's the last memblock allocation, no need to reset it
> +	 * back to to-down.
> +	 */
> +	memblock_set_bottom_up(true);
>  	swiotlb_init(0);
>  #endif
>  
> -- 
> 2.24.0