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: <20191209075413.GA4137@rapoport-lnx>
Date:   Mon, 9 Dec 2019 09:54:15 +0200
From:   Mike Rapoport <rppt@...nel.org>
To:     Michael Ellerman <mpe@...erman.id.au>
Cc:     linux-kernel@...r.kernel.org, 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

On Mon, Dec 09, 2019 at 04:43:17PM +1100, Michael Ellerman wrote:
> 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") ?

swiotlb buffer is initialized before zones are actually used, so probably
not :)
 
> 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

-- 
Sincerely yours,
Mike.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ