Open sdww0 opened 1 month ago
I think lock
should be replaced with lock_irq_disabled
.
I think
lock
should be replaced withlock_irq_disabled
.
This should be irrelevant because the IRQs are disabled at the beginning of the alloc
function.
I guess that this reported issue is caused by a known limitation.
Our partner CertiK has found, as part of their effort to audit the memory subsystem of ostd
, a chicken-egg problem between the heap allocator and page allocator: when the heap allocator has no available pages, it will call the rescue method, which in turns call page_allocator.alloc()
to acquire more pages. But inside the page_allocator.alloc
method, it may need to allocate new objects again. If this happens, the heap allocator will have to be locked again. But the heap allocator is already locked!
They have proposed two strategies to fix this:
BTreeSet<>
nodes within the frame allocator. This allocator should not
depend on the main heap or frame allocator.BTreeSet<>
nodes. This approach ensures that node
allocations do not trigger additional heap or frame allocations.@Tangzh33 Could you take the job of fixing this chicken-egg problem between the heap allocator and page allocator?
Thanks for bringing this up! I'll consider addressing aforementioned problems in the context of issue#1044.
Describe the bug
The program was stuck when I tried to run
iperf3
. After setting the log level to debug, I found it stuck at the heap allocator. Using thegdb_server
, I was able to find that the program was stuck at the timer. More information can be found in theScreenshots
section.To Reproduce
/benchmark/bin
./iperf3 -s -B 10.0.2.15 -p 8080
Expected behavior
Screenshots
Debug log when the program was stuck:
Call Stack:
Environment
Additional context
If changing the
to
then the race condition will be disappeared.
Logs