linux-kernel - Re: [PATCH] sh: switch to NO

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:   Fri, 11 May 2018 11:55:03 -0400
From:   Rich Felker <dalias@...c.org>
To:     Rob Herring <robh@...nel.org>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        SH-Linux <linux-sh@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>
Subject: Re: [PATCH] sh: switch to NO_BOOTMEM

On Fri, May 11, 2018 at 10:37:42AM -0500, Rob Herring wrote:
> On Fri, May 11, 2018 at 10:02 AM, Rich Felker <dalias@...c.org> wrote:
> > On Fri, May 11, 2018 at 08:45:59AM -0500, Rob Herring wrote:
> >> Commit 0fa1c579349f ("of/fdt: use memblock_virt_alloc for early alloc")
> >> inadvertently switched the DT unflattening allocations from memblock to
> >> bootmem which doesn't work because the unflattening happens before
> >> bootmem is initialized. Swapping the order of bootmem init and
> >> unflattening could also fix this, but removing bootmem is desired. So
> >> enable NO_BOOTMEM on SH like other architectures have done.
> >>
> >> Fixes: 0fa1c579349f ("of/fdt: use memblock_virt_alloc for early alloc")
> >> Reported-by: Rich Felker <dalias@...c.org>
> >> Cc: Yoshinori Sato <ysato@...rs.sourceforge.jp>
> >> Signed-off-by: Rob Herring <robh@...nel.org>
> >> ---
> >> This is compile tested only, but similar to microblaze and h8300
> >> conversions. The additional complexity for SH is NUMA support (which to
> >> me looks like an abuse of NUMA support to map a small amount of
> >> on-chip? RAM to NUMA nodes).
> >
> > Thanks! I was just reading the corresponding microblaze commit, and
> > think this approach makes sense. I'll test it now with both DT and
> > non-DT sh systems and let you know if it works. If it's good would you
> > like me to send it upstream via arch/sh? I already have 2
> > regression-fix patches to submit in a pull request asap.
> 
> Yes, please do.

OK. So far looks good. J2 works again (DT-based) and I'm now doing a
new build to test under qemu (r2d board) for non-DT sh.

Rich