Re: [PATCH v2 13/13] arch, mm: make releasing of memory to page allocator more explicit

[Michael Schmitz <schmitzmic@gmail.com>]

Hi Geert,

On 14/03/25 04:51, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Thu, 13 Mar 2025 at 16:35, Mike Rapoport <rppt@kernel.org> wrote:
>> On Thu, Mar 13, 2025 at 04:19:10PM +0100, Geert Uytterhoeven wrote:
>>> On Thu, 13 Mar 2025 at 14:53, Mike Rapoport <rppt@kernel.org> wrote:
>>>> From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
>>>>
>>>> The point where the memory is released from memblock to the buddy allocator
>>>> is hidden inside arch-specific mem_init()s and the call to
>>>> memblock_free_all() is needlessly duplicated in every artiste cure and
>>>> after introduction of arch_mm_preinit() hook, mem_init() implementation on
>>>> many architecture only contains the call to memblock_free_all().
>>>>
>>>> Pull memblock_free_all() call into mm_core_init() and drop mem_init() on
>>>> relevant architectures to make it more explicit where the free memory is
>>>> released from memblock to the buddy allocator and to reduce code
>>>> duplication in architecture specific code.
>>>>
>>>> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>     # x86
>>>> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
>>>>   arch/m68k/mm/init.c          |  2 --
>>> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # m68k
>> Thanks :)
>>
>> While working on this I was wondering if init_pointer_tables() can be moved
>> from mem_init() to motorola::paging_init(). It seems to me that it can, but
>> I wasn't sure enough so I left it there for now.
> Oh, that would be nice, as it would allow us to get rid of the ugly
> #ifdef, and (in the context of this series) of our own mem_init().
> It looked promising at first, but crashed later (on ARAnyM):
>
> VFS: Mounted root (ext3 filesystem) readonly on device 8:1.
> devtmpfs: mounted
> Unable to handle kernel access at virtual address (ptrval)
> Oops: 00000000
> Modules linked in:
> PC: [<0001273b>] xdnrm_dn+0xf/0x10
> SR: 2208  SP: (ptrval)  a2: 01030000
> d0: 00000097    d1: ffffffff    d2: 00000001    d3: 00563000
> d4: 0055f924    d5: 00421b56    a0: 0102e000    a1: 0102e000
> Process swapper (pid: 1, task=(ptrval))
> Frame format=7 eff addr=00ffee01 ssw=0545 faddr=00ffee01

What's at that address? The 14 MB ST-RAM ought to end at 0xe00000 (which 
would have been left unmapped if FastRAM is in use). MMIO area starts at 
0xff0000 but base addresses there are 0xff8xxx, 0xffaxxx or 0xfffxxx 
from what I've found.

Cheers,

     Michael

> wb 1 stat/addr/data: 0000 00000000 00000000
> wb 2 stat/addr/data: 0000 00000000 00000000
> wb 3 stat/addr/data: 0000 00ffee01 00000000
> push data: 00000000 00000000 00000000 00000000
> Stack from 0102ffb6:
>          00000042 4e9a005f 4bd80042 4e720000 a5240000 00000000 00000000 00000000
>          00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>          00002000 00000000
> Call Trace: [<00002000>] _start+0x0/0x6
>
> Code: ac08 9000 07ec e800 0800 0267 0408 d000 <07ec> ee01 43ff 1808
> ee00 04ff 2108 ae00 07ff 1908 ae00 02ff 2420 5fe9 ee00 02ff
> Disabling lock debugging due to kernel taint
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> ---[ end Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x0000000b ]---
>
> Gr{oetje,eeting}s,
>
>                          Geert
>