From: Simon Horman <horms@kernel.org>
To: Prathamesh Deshpande <prathameshdeshpande7@gmail.com>
Cc: Saeed Mahameed <saeedm@nvidia.com>,
Leon Romanovsky <leon@kernel.org>,
Tariq Toukan <tariqt@nvidia.com>, Mark Bloch <mbloch@nvidia.com>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Carolina Jubran <cjubran@nvidia.com>,
Boris Pismenny <borisp@nvidia.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v1] net/mlx5e: Fix eswitch mode block underflow on IPsec acquire SA
Date: Fri, 15 May 2026 17:56:41 +0100 [thread overview]
Message-ID: <20260515165641.GF227382@horms.kernel.org> (raw)
In-Reply-To: <20260510225903.13184-1-prathameshdeshpande7@gmail.com>
On Sun, May 10, 2026 at 11:59:00PM +0100, Prathamesh Deshpande wrote:
> mlx5e_xfrm_add_state() handles acquire-flow temporary SAs by allocating
> software state and skipping hardware offload setup.
>
> That path jumps to the common success label before taking the eswitch mode
> block. After tunnel-mode validation was moved earlier, the common success
> label unconditionally calls mlx5_eswitch_unblock_mode(). For acquire SAs,
> this decrements esw->offloads.num_block_mode without a matching increment.
>
> Return directly after installing the acquire SA offload handle, so only the
> paths that successfully called mlx5_eswitch_block_mode() call the matching
> unblock.
>
> Fixes: 22239eb258bc ("net/mlx5e: Prevent tunnel reformat when tunnel mode not allowed")
> Signed-off-by: Prathamesh Deshpande <prathameshdeshpande7@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
prev parent reply other threads:[~2026-05-15 16:56 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-10 22:59 [PATCH net v1] net/mlx5e: Fix eswitch mode block underflow on IPsec acquire SA Prathamesh Deshpande
2026-05-15 16:56 ` Simon Horman [this message]
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=20260515165641.GF227382@horms.kernel.org \
--to=horms@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=borisp@nvidia.com \
--cc=cjubran@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mbloch@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=prathameshdeshpande7@gmail.com \
--cc=saeedm@nvidia.com \
--cc=tariqt@nvidia.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.