All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: <dev@dpdk.org>, Jianfeng Tan <jianfeng.tan@intel.com>
Subject: Re: [PATCH v4 5/5] eal: avoid deadlock in async IPC alarm callback
Date: Tue, 9 Jun 2026 07:32:25 -0700	[thread overview]
Message-ID: <20260609073225.28e10934@phoenix.local> (raw)
In-Reply-To: <9f0b651c-13dd-44a1-bf72-860202f8cd99@intel.com>

On Tue, 9 Jun 2026 10:04:22 +0200
"Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:

> On 6/5/2026 4:29 PM, Anatoly Burakov wrote:
> > async_reply_handle_thread_unsafe() can run while holding
> > pending_requests.lock and currently calls rte_eal_alarm_cancel().
> > 
> > rte_eal_alarm_cancel() may spin-wait for an executing callback, which can
> > deadlock if that callback is blocked on the same lock.
> > 
> > Remove callback-side alarm cancellation. It is safe to do so, because any
> > callback triggered without a pending request becomes a noop.
> > 
> > Fixes: daf9bfca717e ("ipc: remove thread for async requests")
> > Cc: stable@dpdk.org
> > 
> > Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> > ---  
> 
> Okay, the AI review seems to keep flagging issues that are technically 
> true in the patches, but are intentional and do get better once the 
> complete patchset is applied.
> 
> Looks like I need to merge some of the patches or rethink the order in 
> which the fixes are applied to avoid these issues.

The automated AI review has limited scope; it never looks at patch set in total,
and doesn't have tools to read source. That is why for complex things I tend
to start a new session and give it everything. Does much better job then.

  reply	other threads:[~2026-06-09 14:32 UTC|newest]

Thread overview: 35+ 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 [this message]
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

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=20260609073225.28e10934@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 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.