[#215] Enhance DEFERRED_EXIT_HANDLING_CHECK macro to handle not just deferred signals that terminate the process but also those that suspend the process (Ctrl-Z) #216
In the v63004/gtm8791 subtest, it was noticed that a Ctrl-Z was not handled
(i.e. the process was not suspended) when the test ran on slower systems.
Turns out it was because when the LKE> prompt was being displayed, interrupts
are deferred in the process and if a Ctrl-Z is done at that time, we set
the global variable "suspend_status" to DEFER_SUSPEND to record this fact
and continue but once the interrupts are enabled, we only do checks of deferred
exit handling signals, not of the suspend signal. This means the Ctrl-Z is
effectively ignored. At least until the next rel_crit/rel_lock happens in this
process since that is when the "suspend_status" global is checked again. This
is unfriendly so the DEFERRED_EXIT_HANDLING_CHECK macro (which is invoked every
time we come out of an interrupt deferred zone) is renamed as
DEFERRED_SIGNAL_HANDLING_CHECK and Ctrl-Z deferral is also checked as part of
this macro.
In the v63004/gtm8791 subtest, it was noticed that a Ctrl-Z was not handled (i.e. the process was not suspended) when the test ran on slower systems. Turns out it was because when the LKE> prompt was being displayed, interrupts are deferred in the process and if a Ctrl-Z is done at that time, we set the global variable "suspend_status" to DEFER_SUSPEND to record this fact and continue but once the interrupts are enabled, we only do checks of deferred exit handling signals, not of the suspend signal. This means the Ctrl-Z is effectively ignored. At least until the next rel_crit/rel_lock happens in this process since that is when the "suspend_status" global is checked again. This is unfriendly so the DEFERRED_EXIT_HANDLING_CHECK macro (which is invoked every time we come out of an interrupt deferred zone) is renamed as DEFERRED_SIGNAL_HANDLING_CHECK and Ctrl-Z deferral is also checked as part of this macro.