linux-kernel - Re: [PATCH 00/21] MIPS memblock: Remove bootmem code and 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]

Message-ID: <20170522102643.GA17763@mobilestation>
Date:   Mon, 22 May 2017 13:26:43 +0300
From:   Serge Semin <fancer.lancer@...il.com>
To:     Marcin Nowakowski <marcin.nowakowski@...tec.com>
Cc:     ralf@...ux-mips.org, paul.burton@...tec.com, rabinv@...s.com,
        matt.redfearn@...tec.com, james.hogan@...tec.com,
        alexander.sverdlin@...ia.com, robh+dt@...nel.org,
        frowand.list@...il.com, Sergey.Semin@...latforms.ru,
        linux-mips@...ux-mips.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/21] MIPS memblock: Remove bootmem code and switch to
 NO_BOOTMEM

On Mon, May 22, 2017 at 11:48:36AM +0200, Marcin Nowakowski <marcin.nowakowski@...tec.com> wrote:

Hello Marcin,

> Hi Serge,
> 
> On 19.12.2016 03:07, Serge Semin wrote:
> >Most of the modern platforms supported by linux kernel have already
> >been cleaned up of old bootmem allocator by moving to nobootmem
> >interface wrapping up the memblock. This patchset is the first
> >attempt to do the similar improvement for MIPS for UMA systems
> >only.
> >
> >Even though the porting was performed as much careful as possible
> >there still might be problem with support of some platforms,
> >especially Loonson3 or SGI IP27, which perform early memory manager
> >initialization by their self.
> >
> >The patchset is split so individual patch being consistent in
> >functional and buildable ways. But the MIPS early memory manager
> >will work correctly only either with or without the whole set being
> >applied. For the same reason a reviewer should not pay much attention
> >to methods bootmem_init(), arch_mem_init(), paging_init() and
> >mem_init() until they are fully refactored.
> >
> >The patchset is applied on top of kernel v4.9.
> 
> Have you progressed any further with these patches?
> They would definitely be useful to include for MIPS arch, so can you let us
> know if you are planning to send any updated version?
> 
> thanks,
> Marcin

Sorry for such a long delay with response. I have been really busy
during last three months. Alas I'll still be busy for next 1-2
months as well. You know how it usually works with urgent projects.
One needs to do this thing, then that thing, and at some point I just
forgot about this thread.

Regarding the patchset. I'm still pretty much eager to make it being
part of kernel MIPS arch. But there was a problem I outlined
in the patchset header message, which I can't fix by myself.
Particulary It's connected with Loonson3 or SGI IP27 code alteration,
so to make it free of ancient boot_mem_map dependencies (see the
patchset header message). Without a help from someone, who has
Loonson64 and SGI IP27 hardware and strong desire to make it free of
old bootmem allocator, it is useless to make any progress from my
side. That's why Ralf moved this email-thread into RFC actually.
Anyway If either you or someone else has got such hardware and is
interested in the cooperation, I'll be more than happy to push
my efforts forward with this patchset contribution. But only after
I got a bit less busy with my work. As I said it will happen within
next 1-2 months. So do you have the hardware and desire to be part
of this?

Regards,
-Sergey