Skip to content

memory: add slab allocator#57

Merged
d4ilyrun merged 8 commits intomasterfrom
xxx-slab-allocator
Dec 25, 2025
Merged

memory: add slab allocator#57
d4ilyrun merged 8 commits intomasterfrom
xxx-slab-allocator

Conversation

@d4ilyrun
Copy link
Owner

No description provided.

This file was pushed by mistake, remove it.
The current process's is NULL until we initialize the kernel process
in process_init_kernel_process(). Things get messy and memory is
corrupted if a NULL reference exception happens while in this state.

When the page fault exception is triggred by a valid lazy allocation,
the address space used should be &kernel_address_space and not that
of the currently running process.

Make sure that an address space is defined, and panic if not the case.
This function can be used to manually associate a virtual address
segment with backing physical pages. This should be used when requiring
these pages before performing lazy allocation.
This function is responsible for initializing the whole memory subsystem
instead of letting the kernel_main() function do everything explicitely.

This makes it more obvious what's done in the main function.
We were passing the address of the tree node to the kfree() function
instead of the tar node. This worked fine until now since the former
is embedded inside the latter, but does not work anymore since the
switch to a slab allocator.

Freeing the correct address instead fixes the following error:

kmem_cache_free:419: failed to find bufctl for c09f6700 (align: 16, obj: c09f6700)
Call stack:
  #0  0xc010e337 in <kmem_cache_free+330>
  #1  0xc011173e in <kfree+136>
  #2  0xc010342d in <tar_node_free+57>
  #3  0xc010348e in <tar_node_from_header+92>
  #4  0xc01037c5 in <tar_init_tree+471>
  #5  0xc0103dbb in <tar_new+408>
  #6  0xc0101fc7 in <vfs_mount_at+83>
  #7  0xc010204c in <vfs_mount_root+57>
  #8  0xc010120d in <kernel_mount_initfs+130>
  #9  0xc0101477 in <kernel_main+530>
  #10  0xc011571b in <higher_half+31>
===
The kernel_process_initial_thread (TID 0) is statically allocated
and not kmalloc'd like all other threads in the kernel. This means
that we cannot call kfree() on it as we usually would.

We should be able to release this memory as well as other structures
that are only required during the setup process, but this is another
matter.

Do not free the initial kernel thread in thread_free(). This fixes
the following error:

[process] terminating thread 0 (kstartup)
[vm] freeing unaligned virtual address: c0954990 (skipping)
kfree:49: !(page->flags & PAGE_SLAB)
Call stack:
  #0  0xc0111693 in <kfree+104>
  #1  0xc0105c86 in <thread_free+186>
  #2  0xc0105ccb in <thread_switch+28>
  #3  0xc0104a07 in <schedule_locked+280>
  #4  0xc0104a4d in <schedule+34>
  #5  0xc0118925 in <irq_timer_handler+111>
  #6  0xc0115de7 in <default_interrupt_handler+387>
  #7  0xc0115ec7 in <__common_handler+7>
  #8  0xc01032cb in <tar_read+146>
  #9  0xc0103bff in <tar_file_read+195>
  #10  0xc010c0ba in <map_file+248>
  #11  0xc0107e83 in <execfmt_execute+148>
  #12  0xc0105ed0 in <__process_execute_in_userland+65>
  #13  0xc01172b1 in <arch_thread_entrypoint+233>
===
@d4ilyrun d4ilyrun merged commit 3ddec71 into master Dec 25, 2025
2 checks passed
@d4ilyrun d4ilyrun deleted the xxx-slab-allocator branch December 25, 2025 18:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant