All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: David Marchand <david.marchand@redhat.com>
Cc: Anatoly Burakov <anatoly.burakov@intel.com>, <dev@dpdk.org>,
	Jianfeng Tan <jianfeng.tan@intel.com>
Subject: Re: [PATCH v7 4/6] eal: fix async IPC memory leaks on partial failure
Date: Wed, 1 Jul 2026 10:53:11 +0100	[thread overview]
Message-ID: <akTjhwjOhhPPZeK2@bricha3-mobl1.ger.corp.intel.com> (raw)
In-Reply-To: <CAJFAV8wmRsznO6S6gz0cmnhAs+QHW1k=7oFo3DhR9--A-Myo5Q@mail.gmail.com>

On Wed, Jul 01, 2026 at 11:47:05AM +0200, David Marchand wrote:
> On Fri, 26 Jun 2026 at 12:34, Anatoly Burakov <anatoly.burakov@intel.com> wrote:
> >
> > When rte_mp_request_async() fails to send requests to all peers,
> > copy and param can lose ownership and leak.
> >
> > However, we cannot simply free them unconditionally, as "partial failure"
> > means some requests were already queued and thus still reference `copy` and
> > `param`, so freeing them directly on the error path can cause
> > use-after-free when those requests are later handled by the async timeout.
> >
> > Fix this by rolling back queued requests from the current batch, and reset
> > nb_sent to 0. Freeing the requests is now safe even if some requests were
> > sent, as any responses or timeouts will not find the request ID in the
> > queue and will safely exit without doing anything.
> >
> > Coverity issue: 501503
> >
> > Fixes: f05e26051c15 ("eal: add IPC asynchronous request")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> > ---
> >  lib/eal/common/eal_common_proc.c | 31 +++++++++++++++++++++++++++++++
> >  1 file changed, 31 insertions(+)
> >
> > diff --git a/lib/eal/common/eal_common_proc.c b/lib/eal/common/eal_common_proc.c
> > index 991bf215a3..0cffc7a127 100644
> > --- a/lib/eal/common/eal_common_proc.c
> > +++ b/lib/eal/common/eal_common_proc.c
> > @@ -1245,6 +1245,32 @@ rte_mp_request_async(struct rte_mp_msg *req, const struct timespec *ts,
> >                 } else if (mp_request_async(path, copy, param, ts))
> >                         ret = -1;
> >         }
> > +
> > +       /*
> > +        * On partial failure, roll back all queued requests. We hold the lock
> > +        * so no one else touches the queue. All requests in this batch share
> > +        * the same param pointer. Stale alarms will fire and harmlessly find
> > +        * nothing via ID-based lookup.
> > +        */
> > +       if (ret != 0 && reply->nb_sent > 0) {
> > +               struct pending_request *r, *next;
> > +
> > +               for (r = TAILQ_FIRST(&pending_requests.requests);
> > +                               r != NULL; r = next) {
> > +                       next = TAILQ_NEXT(r, next);
> > +                       if (r->type == REQUEST_TYPE_ASYNC &&
> > +                                       r->async.param == param) {
> > +                               TAILQ_REMOVE(&pending_requests.requests,
> > +                                               r, next);
> > +                               free(r->reply);
> > +                               /* r->request == copy, freed below after the loop */
> > +                               free(r);
> > +                       }
> > +               }
> > +               /* requests on the queue were removed so keep things consistent */
> > +               reply->nb_sent = 0;
> > +       }
> > +
> 
> Please, don't reimplement the safe macro.
> 
> I plan to update this with:
> 
> @@ -1252,15 +1252,11 @@ rte_mp_request_async(struct rte_mp_msg *req,
> const struct timespec *ts,
>          * nothing via ID-based lookup.
>          */
>         if (ret != 0 && reply->nb_sent > 0) {
> -               struct pending_request *r, *next;
> -
> -               for (r = TAILQ_FIRST(&pending_requests.requests);
> -                               r != NULL; r = next) {
> -                       next = TAILQ_NEXT(r, next);
> -                       if (r->type == REQUEST_TYPE_ASYNC &&
> -                                       r->async.param == param) {
> -                               TAILQ_REMOVE(&pending_requests.requests,
> -                                               r, next);
> +               struct pending_request *r, *tmp;
> +
> +               RTE_TAILQ_FOREACH_SAFE(r, &pending_requests.requests,
> next, tmp) {
> +                       if (r->type == REQUEST_TYPE_ASYNC &&
> r->async.param == param) {
> +
> TAILQ_REMOVE(&pending_requests.requests, r, next);
>                                 free(r->reply);
>                                 /* r->request == copy, freed below
> after the loop */
>                                 free(r);
> 
> Objection?
> If not, I'll update while applying.
> 
+1 to this suggestion from me.

  reply	other threads:[~2026-07-01  9:53 UTC|newest]

Thread overview: 53+ 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
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
2026-06-09  8:04     ` Burakov, Anatoly
2026-06-09 14:32       ` Stephen Hemminger
2026-06-08 13:13 ` [PATCH v5 1/5] eal: fix wrong log message in async IPC request Anatoly Burakov
2026-06-08 13:13   ` [PATCH v5 2/5] eal: fix async IPC callback not fired when no peers Anatoly Burakov
2026-06-08 13:13   ` [PATCH v5 3/5] eal: fix memory leak in async IPC secondary path Anatoly Burakov
2026-06-08 13:13   ` [PATCH v5 4/5] eal: fix async IPC resource leaks on partial failure Anatoly Burakov
2026-06-08 13:13   ` [PATCH v5 5/5] eal: avoid deadlock in async IPC alarm callback Anatoly Burakov
2026-06-25 14:01 ` [PATCH v6 0/6] IPC fixes Anatoly Burakov
2026-06-25 14:01   ` [PATCH v6 1/6] eal: fix wrong log message in async IPC request Anatoly Burakov
2026-06-25 14:01   ` [PATCH v6 2/6] eal: use request ID instead of pointers Anatoly Burakov
2026-06-25 14:01   ` [PATCH v6 3/6] eal: avoid deadlock in async IPC alarm callback Anatoly Burakov
2026-06-25 14:01   ` [PATCH v6 4/6] eal: fix async IPC memory leaks on partial failure Anatoly Burakov
2026-06-25 14:01   ` [PATCH v6 5/6] eal: fix memory leak in async IPC secondary path Anatoly Burakov
2026-06-25 14:01   ` [PATCH v6 6/6] eal: fix async IPC callback not fired when no peers Anatoly Burakov
2026-06-26 10:33 ` [PATCH v7 0/6] IPC fixes Anatoly Burakov
2026-06-26 10:33   ` [PATCH v7 1/6] eal: fix wrong log message in async IPC request Anatoly Burakov
2026-06-26 10:33   ` [PATCH v7 2/6] eal: use request ID instead of pointers Anatoly Burakov
2026-06-26 15:08     ` Stephen Hemminger
2026-06-26 10:33   ` [PATCH v7 3/6] eal: avoid deadlock in async IPC alarm callback Anatoly Burakov
2026-06-26 10:33   ` [PATCH v7 4/6] eal: fix async IPC memory leaks on partial failure Anatoly Burakov
2026-07-01  9:47     ` David Marchand
2026-07-01  9:53       ` Bruce Richardson [this message]
2026-06-26 10:34   ` [PATCH v7 5/6] eal: fix memory leak in async IPC secondary path Anatoly Burakov
2026-06-26 10:34   ` [PATCH v7 6/6] eal: fix async IPC callback not fired when no peers Anatoly Burakov
2026-07-01 10:09   ` [PATCH v7 0/6] IPC fixes David Marchand

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=akTjhwjOhhPPZeK2@bricha3-mobl1.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=david.marchand@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.