RGBCube/serenity
1
Fork 0
mirror of https://github.com/RGBCube/serenity synced 2025-07-25 15:37:46 +00:00
Code Issues Activity Actions

Kernel: Fix race condition waiting for IPI while other CPU requested halt

Browse source 
It's possible that we broadcast an IPI message right at the same time
another processor requests a halt. Rather than spinning forever waiting
for that message to be handled, check if we should halt while waiting.
This commit is contained in:
Tom 2020-10-25 20:07:48 -06:00 • committed by Andreas Kling
parent fe615e601a
commit b8ad4932a9
1 changed files with 6 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

6
Kernel/Arch/i386/CPU.cpp
View file

@ -1870,6 +1870,12 @@ void Processor::smp_broadcast_message(ProcessorMessage& msg, bool async)
// to the pool. Otherwise, the last processor to complete it will return it // to the pool. Otherwise, the last processor to complete it will return it
while (atomic_load(&msg.refs, AK::MemoryOrder::memory_order_consume) != 0) { while (atomic_load(&msg.refs, AK::MemoryOrder::memory_order_consume) != 0) {
// TODO: pause for a bit? // TODO: pause for a bit?
// We need to check here if another processor may have requested
// us to halt before this message could be delivered. Otherwise
// we're just spinning the CPU because msg.refs will never drop to 0.
if (cur_proc.m_halt_requested)
halt_this();
} }
smp_cleanup_message(msg); smp_cleanup_message(msg);