-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] PMM Deadlock #343
Comments
Analysis (take with grain of salt, am not experienced with kernels) If ktf runs in parallel on multiple cores there is another potential deadlock scenario: Potential Solutions?
I can make a pull request for either solution. Since I have no experience in kernel development I'd appreciate some feedback on whether these are viable solutions before making the pull requests. |
The analysis reasoning is correct I think. The PMM implementation tries to take care of this already (see the usage of Line 37 in e1658d8
Hence, the second approach of making sure there is always available frame for the frames array is the way to go. |
The reservation looks good to me. The problem seems to be with mapping the newly acquired frame to use it as a frames array. This mapping might require another call to
Intuitively I'd try to solve both these issues using re-entrant locks but they don't exist yet in ktf and bring their own load of complexity... |
Alright, new suggestion :D Paging wants to avoid pmm 4k frame refill (and array allocation) so it gets its own |
Describe the bug
There is a bug in the PMM where it locks-up (deadlock?). It happens when the allocator runs out of 4k frames and splits a higher-order frame. Maybe no 4k page was reserved for the new signling page?
To Reproduce
test_kernel_task_func2
demonstrates the issue (Unittest That Stress-Tests the VMM and PMM #341 )KT2_ROUNDS
to 1 andKT2_CHUNKS
to 1000 to allocate enough 4k frames such that they get depletedsrand
seed to one where you repeatedly observe the deadlockExpected behavior
The testcase just passes. Throwing more memory at the issue, by increasing
.qemu_config:QEMU_RAM
, has seemingly no impact.Props to Sandro Rüegge (@sparchatus) for helping me debugging this.
The text was updated successfully, but these errors were encountered: