linux-kernel - [RFC] 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-next>] [day] [month] [year] [list]

Date:   Tue, 19 Dec 2017 23:14:00 +0300
From:   Serge Semin <fancer.lancer@...il.com>
To:     ralf@...ux-mips.org, paul.burton@...tec.com, rabinv@...s.com,
        matt.redfearn@...tec.com, james.hogan@...tec.com,
        alexander.sverdlin@...ia.com, marcin.nowakowski@...tec.com,
        f.fainelli@...il.com, kumba@...too.org
Cc:     Sergey.Semin@...latforms.ru, fancer.lancer@...il.com,
        linux-mips@...ux-mips.org, linux-kernel@...r.kernel.org
Subject: [RFC] MIPS memblock: Remove bootmem code and switch to NO_BOOTMEM

Hello folks,

Almost a year ago I sent a patchset to the Linux MIPS community. The main target of the patchset
was to get rid from the old bootmem allocator usage at the MIPS architecture. Additionally I had
a problem with CMA usage on my MIPS machine due to some struct page-related issue. Moving to the
memblock allocator fixed the problem and gave us benefits like smaller memory consumption,
powerful memblock API to be used within the arch code.

Sorry for the delay. I promised to get back to this work within two months since my last post, but
there are more over five months passed. Now when some free time finally available at my schedule
I am ready to go on with this patchset and finally finish it up. After a short glance at the old
code I suppose there should be some refactoring made. Particularly:
- completely get rid from the boot_mem_map[] array usage. After the memblock code utilization
  is added, the boot_mem_map array will be excessive.
- unpin memblock/bootmem unrelated changes to a separate series so the patchset wouldn't be
  that big.
- take into account all the comments the community users posted on my initial patchset.

Still there are several questions, I need to have answered before the development is started.

Question to the community in general. Are you still interested in this work to be done and the
patchset to be submitted for review?

@ralf@...ux-mips.org. Last time you moved the patchset to the RFC status for some reason. I asked
you twice to send to me your comments about the patches, but obviously you didn't have time for
this, then you might have just forgotten. Could you please confirm whether you are interested in
these alterations and will be ready to review them?

@marcin.nowakowski@...tec.com. Could you confirm if you are still interested in the patchset and
ready to update the Loongson64 platform code so one would be compatible with it?

@kumba@...too.org. Will you still be able to update the SGI IP27 code so one would work on top
of the patches?

@alexander.sverdlin@...ia.com. Do you still possess the Octeon MIPS64 platform to test the patchset?

Thanks folks for you willingness to help

Regards,
-Sergey