From: Ronan Desplanques Date: Tue, 11 Jul 2023 15:57:14 +0000 (+0200) Subject: ada: Fix race condition in protected entry call X-Git-Tag: basepoints/gcc-15~7295 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=5bd09a25b342f980f0596c9e354c54a4c635ec65;p=thirdparty%2Fgcc.git ada: Fix race condition in protected entry call This patch only affects the single-entry implementation of protected objects. Before this patch, there was a race condition where a task that called an entry could put itself to sleep right after another task had executed the entry as a proxy and signalled the not-yet-waiting first task, which caused the first task to enter a deadlock. Note that this race condition has been identified and fixed before for the implementations of the run-time that live under hie/. This patch reworks the locking sequence so that it is closer to the one that's used in the multiple-entry implementation of protected objects. The code for the multiple-entry implementation is spread across multiple subprograms. To draw a parallel with the section this patch modifies, one can read the following subprograms: - System.Tasking.Protected_Objects.Operations.Protected_Entry_Call - System.Tasking.Entry_Calls.Wait_For_Completion - System.Tasking.Entry_Calls.Check_Pending_Actions_For_Entry_Call This patch also adds a comment that explicitly states the locking constraint that must hold in the affected section. gcc/ada/ * libgnarl/s-tposen.adb: Fix race condition. Add comment to justify the locking timing. --- diff --git a/gcc/ada/libgnarl/s-tposen.adb b/gcc/ada/libgnarl/s-tposen.adb index 9dff66192954..a7447b9e2afd 100644 --- a/gcc/ada/libgnarl/s-tposen.adb +++ b/gcc/ada/libgnarl/s-tposen.adb @@ -345,11 +345,17 @@ package body System.Tasking.Protected_Objects.Single_Entry is pragma Assert (Entry_Call.State /= Cancelled); + -- Note that we need to acquire Self_Id's lock before checking the value + -- of Entry_Call.State, even though the latter is specified as atomic + -- with a pragma. If we didn't, another task could execute the entry on + -- our behalf right between the check of Entry_Call.State and the call + -- to Wait_For_Completion, and that would cause a deadlock. + + STPO.Write_Lock (Self_Id); if Entry_Call.State /= Done then - STPO.Write_Lock (Self_Id); Wait_For_Completion (Entry_Call'Access); - STPO.Unlock (Self_Id); end if; + STPO.Unlock (Self_Id); Check_Exception (Self_Id, Entry_Call'Access); end Protected_Single_Entry_Call;