summaryrefslogtreecommitdiff
path: root/src/tools/irm/irm_ipcp_connect.c
diff options
context:
space:
mode:
authorDimitri Staessens <dimitri@ouroboros.rocks>2024-02-24 12:35:22 +0100
committerSander Vrijders <sander@ouroboros.rocks>2024-02-26 08:59:15 +0100
commitb5888ad746fd03d483196a2cb3711bb0fe63d82d (patch)
tree5de0df7212b7f6d0050431ec92b59f42aa48a3b3 /src/tools/irm/irm_ipcp_connect.c
parentdc56c2211424567d9a249f3630505d92f026428e (diff)
downloadouroboros-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/tools/irm/irm_ipcp_connect.c')
0 files changed, 0 insertions, 0 deletions