On Thu,  4 Jun 2026 17:32:16 +0100
Anatoly Burakov <[email protected]> wrote:

> Currently, when rte_mp_request_async() is called and no peer processes
> are connected (nb_sent == 0), the user callback is never invoked.
> 
> The original implementation used a dedicated background thread and
> pthread_cond_signal() to wake it after queuing the dummy request. When
> that thread was replaced with per-message alarms, no alarm was set for
> the dummy request, silently breaking the nb_sent == 0 path.
> 
> This was not noticed because async requests are used while handling
> secondary process requests, where peers are typically already present.
> 
> Fix it by setting a 1us alarm on the dummy request, so the callback path
> immediately triggers and processes it.
> 
> Fixes: daf9bfca717e ("ipc: remove thread for async requests")
> Cc: [email protected]
> 
> Signed-off-by: Anatoly Burakov <[email protected]>
> ---
>  lib/eal/common/eal_common_proc.c | 18 ++++++++++++++++--
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/eal/common/eal_common_proc.c 
> b/lib/eal/common/eal_common_proc.c
> index 799c6e81b0..5cc15a0f78 100644
> --- a/lib/eal/common/eal_common_proc.c
> +++ b/lib/eal/common/eal_common_proc.c
> @@ -1187,11 +1187,21 @@ rte_mp_request_async(struct rte_mp_msg *req, const 
> struct timespec *ts,
>       if (rte_eal_process_type() == RTE_PROC_SECONDARY) {
>               ret = mp_request_async(eal_mp_socket_path(), copy, param, ts);
>  
> -             /* if we didn't send anything, put dummy request on the queue */
> +             /* if we didn't send anything, put dummy request on the queue
> +              * and set a minimum-delay alarm so the callback fires 
> immediately.
> +              */
>               if (ret == 0 && reply->nb_sent == 0) {
>                       TAILQ_INSERT_TAIL(&pending_requests.requests, dummy,
>                                       next);
>                       dummy_used = true;
> +
> +                     if (rte_eal_alarm_set(1, async_reply_handle, dummy) < 
> 0) {
> +                             EAL_LOG(ERR, "Fail to set alarm for dummy 
> request");
> +                             /* roll back the changes */
> +                             TAILQ_REMOVE(&pending_requests.requests, dummy, 
> next);
> +                             dummy_used = false;
> +                             ret = -1;
> +                     }
>               }
>  
>               pthread_mutex_unlock(&pending_requests.lock);
> @@ -1232,10 +1242,14 @@ rte_mp_request_async(struct rte_mp_msg *req, const 
> struct timespec *ts,
>               } else if (mp_request_async(path, copy, param, ts))
>                       ret = -1;
>       }
> -     /* if we didn't send anything, put dummy request on the queue */
> +     /* if we didn't send anything, put dummy request on the queue
> +      * and set a minimum-delay alarm so the callback fires immediately.
> +      */
>       if (ret == 0 && reply->nb_sent == 0) {
>               TAILQ_INSERT_HEAD(&pending_requests.requests, dummy, next);
>               dummy_used = true;
> +             if (rte_eal_alarm_set(1, async_reply_handle, dummy) < 0)
> +                     EAL_LOG(ERR, "Fail to set alarm for dummy request");
>       }
>  
>       /* finally, unlock the queue */


AI spotted potential issue:

The bug in 2/5: in the primary-process path, if rte_eal_alarm_set() fails for 
the dummy request, the code only logs it.
The dummy stays on the queue with no alarm, the function returns 0 (success),
the callback never fires, and dummy/copy/param leak.

The secondary path right above it handles this correctly (rolls back, returns 
-1).
Fix is to make the primary path do the same. This corner is never fixed by the 
later patches.

Reply via email to