RGBCube/serenity
1
Fork 0
mirror of https://github.com/RGBCube/serenity synced 2025-05-31 10:38:11 +00:00
Code Issues Activity Actions

Kernel: Unblock SignalBlocker if a signal was just unmarked as pending

Browse source 
When updating the signal mask, there is a small frame where we might set
up the receiving process for handing the signal and therefore remove
that signal from the list of pending signals before SignalBlocker has a
chance to block. In turn, this might cause SignalBlocker to never notice
that the signal arrives and it will never unblock once blocked.

Track the currently handled signal separately and include it when
determining if SignalBlocker should be unblocking.
This commit is contained in:
Tim Schumacher 2022-06-30 13:36:03 +02:00 • committed by Brian Gianforcaro
parent cd189999d1
commit edbffb3c7a
4 changed files with 13 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

10
Kernel/ThreadBlockers.cpp
View file

@ -474,7 +474,15 @@ bool Thread::SignalBlocker::check_pending_signals(bool from_add_blocker)
if (m_did_unblock)
return false;
auto matching_pending_signal = bit_scan_forward(thread().pending_signals() & m_pending_set);
auto pending_signals = thread().pending_signals() & m_pending_set;
// Also unblock if we have just "handled" that signal and are in the procecss
// of running their signal handler (i.e. we just unmarked the signal as pending).
if (thread().m_currently_handled_signal)
pending_signals |= (1 << (thread().m_currently_handled_signal - 1)) & m_pending_set;
auto matching_pending_signal = bit_scan_forward(pending_signals);
if (matching_pending_signal == 0)
return false;