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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 09 Nov 2017 03:32:07 +0200
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Jacopo Mondi <jacopo+renesas@...ndi.org>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Rich Felker <dalias@...c.org>,
        Linux-sh list <linux-sh@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] sh: migor: Reserve memory block for CEU

Hi Geert,

On Wednesday, 8 November 2017 20:31:22 EET Geert Uytterhoeven wrote:
> On Wed, Nov 8, 2017 at 7:05 PM, Jacopo Mondi wrote:
> > A memory region for CEU video buffer has to be reserved during machine
> > initialization.
> > 
> > Originally, it was allocated through DMA API helpers and stored in the
> > second IORESOURCE_MEM entry, to be later remapped by the CEU driver with
> > a call to 'dma_declare_coherent_memory()'
> > 
> > As Linux does not allow anymore to remap system RAM regions with
> > 'memremap' function, sh_mobile_ceu driver fails when trying to remap the
> > memory area:
> > 
> > WARN_ONCE(1, "memremap attempted on ram %pa size: %#lx\n",
> > 
> >           &offset, (unsigned long) size)
> > 
> > from 'memremap()' function in kernel/memremap.c
> > 
> > To avoid hitting that WARN_ONCE() and have memory successfully remapped,
> > reserve a region using '.mv_mem_reserve' member of SH's 'struct
> > sh_machine_vector' to make sure memory is reserved early enough, and
> > removed from the available system RAM.
> > 
> > This is similar to what happens on ARM architecture with
> > 'arm_memblock_steal()' function.
> > 
> > Suggested-by: Laurent Pinchart <laurent.pinchart@...asonboard.com>
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@...ndi.org>
> 
> I assume this failure isnot limited to CEU on Migo-R, but applies to
> the other 24 callers of platform_resource_setup_memory(), too?
> 
> Can platform_resource_setup_memory() be fixed instead, or is that difficult
> due to the need to reserve the memory very early in the boot process?

That's exactly the problem, memory needs to be reserved early at boot, earlier 
than the current call sites of platform_resource_setup_memory().

The real fix in my opinion would be to use CMA, but implementing CMA for SH is 
out of scope of Jacopo's work on the CEU driver. And that would still require 
patching all the 24 callers of platform_resource_setup_memory() anyway.

-- 
Regards,

Laurent Pinchart

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ