diff options
author | Dimitri Staessens <dimitri@ouroboros.rocks> | 2024-02-24 12:35:22 +0100 |
---|---|---|
committer | Sander Vrijders <sander@ouroboros.rocks> | 2024-02-26 08:59:15 +0100 |
commit | b5888ad746fd03d483196a2cb3711bb0fe63d82d (patch) | |
tree | 5de0df7212b7f6d0050431ec92b59f42aa48a3b3 /src/lib/tests/crc32_test.c | |
parent | dc56c2211424567d9a249f3630505d92f026428e (diff) | |
download | ouroboros-b5888ad746fd03d483196a2cb3711bb0fe63d82d.tar.gz ouroboros-b5888ad746fd03d483196a2cb3711bb0fe63d82d.zip |
ipcpd: Mitigate race in wait_req_arr and wait_resp
The wait_flow_req_arr and wait_flow_resp functions are there to ensure
the responses of the IRMd to flow allocation requests arrive in the
correct order. These functions use a mutex: alloc_lock.
After these functions return, the IPCP will switch to it's own
(usually read-write) lock. In the local IPCP, this leaves room for a
race where the state of the flow is accessed in alloc_resp before it
is updated in wait_flow_req_arr. This race is only visible in the
local IPCP, as the other IPCP have to send information between these
calls, but it is theoretically possible when using any IPCP for local
IPC. In the ipcpd-local, it happens ~0.01% to ~0.03% of flow allocations.
This mitigates the problem in the ipcpd-local by adding a 1ms wait to
the flow allocation if this race is detected.
Signed-off-by: Dimitri Staessens <dimitri@ouroboros.rocks>
Signed-off-by: Sander Vrijders <sander@ouroboros.rocks>
Diffstat (limited to 'src/lib/tests/crc32_test.c')
0 files changed, 0 insertions, 0 deletions