linux-kernel - Re: [PATCH v2 00/21] Refine memblock API

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, 03 Oct 2019 15:17:36 +0200
From:   Lucas Stach <l.stach@...gutronix.de>
To:     Mike Rapoport <rppt@...ux.ibm.com>,
        Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Adam Ford <aford173@...il.com>, Fabio Estevam <festevam@...il.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Christoph Hellwig <hch@....de>,
        The etnaviv authors <etnaviv@...ts.freedesktop.org>,
        arm-soc <linux-arm-kernel@...ts.infradead.org>,
        Linux Memory Management List <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v2 00/21] Refine memblock API

Am Donnerstag, den 03.10.2019, 14:30 +0300 schrieb Mike Rapoport:
> On Thu, Oct 03, 2019 at 09:49:14AM +0100, Russell King - ARM Linux admin wrote:
> > On Thu, Oct 03, 2019 at 08:34:52AM +0300, Mike Rapoport wrote:
> > > (trimmed the CC)
> > > 
> > > On Wed, Oct 02, 2019 at 06:14:11AM -0500, Adam Ford wrote:
> > > > On Wed, Oct 2, 2019 at 2:36 AM Mike Rapoport <rppt@...ux.ibm.com> wrote:
> > > > 
> > > > Before the patch:
> > > > 
> > > > # cat /sys/kernel/debug/memblock/memory
> > > >    0: 0x10000000..0x8fffffff
> > > > # cat /sys/kernel/debug/memblock/reserved
> > > >    0: 0x10004000..0x10007fff
> > > >   34: 0x2fffff88..0x3fffffff
> > > > 
> > > > 
> > > > After the patch:
> > > > # cat /sys/kernel/debug/memblock/memory
> > > >    0: 0x10000000..0x8fffffff
> > > > # cat /sys/kernel/debug/memblock/reserved
> > > >    0: 0x10004000..0x10007fff
> > > >   36: 0x80000000..0x8fffffff
> > > 
> > > I'm still not convinced that the memblock refactoring didn't uncovered an
> > > issue in etnaviv driver.
> > > 
> > > Why moving the CMA area from 0x80000000 to 0x30000000 makes it fail?
> > 
> > I think you have that the wrong way round.
> 
> I'm relying on Adam's reports of working and non-working versions.
> According to that etnaviv works when CMA area is at 0x80000000 and does not
> work when it is at 0x30000000.
> 
> He also sent logs a few days ago [1], they also confirm that.
> 
> [1] https://lore.kernel.org/linux-mm/CAHCN7xJEvS2Si=M+BYtz+kY0M4NxmqDjiX9Nwq6_3GGBh3yg=w@mail.gmail.com/

To clarify: Etnaviv needs to know where the CMA area is in order to
move a aperture window to cover the CMA area so the command buffers
allocated in contig memory can be mapped through this aperture. Now the
issue is that there is currently there is no good API for a driver to
know where the CMA area is located, so we are trying to infer this from
dma_get_required_mask. Unfortunately this can overshoot the real DRAM
area by a bit, so combined with the fixed 2GB size of the GPU aperture
this means we are no longer able to map the command buffers through the
required aperture if the CMA area moves too far down in the physical
memory.

It's really a bad interaction between etnaviv and CMA area placement,
due to insufficient APIs to communicate some crucial information. There
is nothing in the etnaviv driver or the hardware which requires the CMA
area to be at a certain place, we just need to know where it is located
exactly. So my try at fixing this [1] was by adding a API to get the
required information, but the first attempt was shot down and I hadn't
had time to follow up on this yet.

Regards,
Lucas

[1] https://patchwork.kernel.org/patch/10966767/