From: Stephen Hemminger <stephen@networkplumber.org>
To: Anatoly Burakov <anatoly.burakov@intel.com>
Cc: dev@dpdk.org, Jianfeng Tan <jianfeng.tan@intel.com>
Subject: Re: [PATCH v3 2/5] eal: fix async IPC callback not fired when no peers
Date: Fri, 5 Jun 2026 11:15:43 -0700 [thread overview]
Message-ID: <20260605111543.6bbafe27@phoenix.local> (raw)
In-Reply-To: <843e56829da93b5d7c917e61118acd525196dc7d.1780590727.git.anatoly.burakov@intel.com>
On Thu, 4 Jun 2026 17:32:16 +0100
Anatoly Burakov <anatoly.burakov@intel.com> 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: stable@dpdk.org
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> ---
> 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.
next prev parent reply other threads:[~2026-06-05 18:15 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-19 16:07 [PATCH v1 1/5] eal: fix wrong log message in async IPC request Anatoly Burakov
2026-03-19 16:07 ` [PATCH v1 2/5] eal: fix async IPC callback not fired when no peers Anatoly Burakov
2026-03-19 16:07 ` [PATCH v1 3/5] eal: fix memory leak in async IPC secondary path Anatoly Burakov
2026-03-19 16:07 ` [PATCH v1 4/5] eal: fix async IPC resource leaks on partial failure Anatoly Burakov
2026-05-28 14:24 ` Thomas Monjalon
2026-05-29 15:10 ` Burakov, Anatoly
2026-03-19 16:07 ` [PATCH v1 5/5] eal: avoid deadlock in async IPC alarm callback Anatoly Burakov
2026-05-29 15:26 ` [PATCH v2 1/5] eal: fix wrong log message in async IPC request Anatoly Burakov
2026-05-29 15:26 ` [PATCH v2 2/5] eal: fix async IPC callback not fired when no peers Anatoly Burakov
2026-06-01 12:21 ` Thomas Monjalon
2026-06-01 12:40 ` Thomas Monjalon
2026-06-04 16:21 ` Burakov, Anatoly
2026-05-29 15:26 ` [PATCH v2 3/5] eal: fix memory leak in async IPC secondary path Anatoly Burakov
2026-05-29 15:26 ` [PATCH v2 4/5] eal: fix async IPC resource leaks on partial failure Anatoly Burakov
2026-06-01 12:16 ` Thomas Monjalon
2026-06-03 8:28 ` Burakov, Anatoly
2026-05-29 15:26 ` [PATCH v2 5/5] eal: avoid deadlock in async IPC alarm callback Anatoly Burakov
2026-06-04 16:32 ` [PATCH v3 1/5] eal: fix wrong log message in async IPC request Anatoly Burakov
2026-06-04 16:32 ` [PATCH v3 2/5] eal: fix async IPC callback not fired when no peers Anatoly Burakov
2026-06-05 18:15 ` Stephen Hemminger [this message]
2026-06-04 16:32 ` [PATCH v3 3/5] eal: fix memory leak in async IPC secondary path Anatoly Burakov
2026-06-04 16:32 ` [PATCH v3 4/5] eal: fix async IPC resource leaks on partial failure Anatoly Burakov
2026-06-04 16:32 ` [PATCH v3 5/5] eal: avoid deadlock in async IPC alarm callback Anatoly Burakov
2026-06-05 14:29 ` [PATCH v4 1/5] eal: fix wrong log message in async IPC request Anatoly Burakov
2026-06-05 14:29 ` [PATCH v4 2/5] eal: fix async IPC callback not fired when no peers Anatoly Burakov
2026-06-05 14:29 ` [PATCH v4 3/5] eal: fix memory leak in async IPC secondary path Anatoly Burakov
2026-06-05 14:29 ` [PATCH v4 4/5] eal: fix async IPC resource leaks on partial failure Anatoly Burakov
2026-06-05 14:29 ` [PATCH v4 5/5] eal: avoid deadlock in async IPC alarm callback Anatoly Burakov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260605111543.6bbafe27@phoenix.local \
--to=stephen@networkplumber.org \
--cc=anatoly.burakov@intel.com \
--cc=dev@dpdk.org \
--cc=jianfeng.tan@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox