From: Saeed Mahameed <saeed@kernel.org>
To: Leon Romanovsky <leon@kernel.org>
Cc: Jason Gunthorpe <jgg@nvidia.com>,
Patrisious Haddad <phaddad@nvidia.com>,
Jakub Kicinski <kuba@kernel.org>,
linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
Paolo Abeni <pabeni@redhat.com>,
Saeed Mahameed <saeedm@nvidia.com>,
Yishai Hadas <yishaih@nvidia.com>
Subject: Re: [PATCH mlx5-next 1/3] net/mlx5: Nullify eq->dbg and qp->dbg pointers post destruction
Date: Tue, 5 Apr 2022 12:48:45 -0700 [thread overview]
Message-ID: <20220405194845.c443x4gf522c2kgv@sx1> (raw)
In-Reply-To: <032d54e1ed92d0f288b385d6343a5b6e109daabe.1649139915.git.leonro@nvidia.com>
On 05 Apr 11:12, Leon Romanovsky wrote:
>From: Patrisious Haddad <phaddad@nvidia.com>
>
>Prior to this patch in the case that destroy_unmap_eq()
>failed and was called again, it triggered an additional call of
Where is it being failed and called again ? this shouldn't even be an
option, we try to keep mlx5 symmetrical, constructors and destructors are
supposed to be called only once in their respective positions.
the callers must be fixed to avoid re-entry, or change destructors to clear
up all resources even on failures, no matter what do not invent a reentry
protocols to mlx5 destructors.
>mlx5_debug_eq_remove() which causes a kernel crash, since
>eq->dbg was not nullified in previous call.
>
[...]
> int mlx5_debug_cq_add(struct mlx5_core_dev *dev, struct mlx5_core_cq *cq)
>diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eq.c b/drivers/net/ethernet/mellanox/mlx5/core/eq.c
>index 229728c80233..3c61f355cdac 100644
>--- a/drivers/net/ethernet/mellanox/mlx5/core/eq.c
>+++ b/drivers/net/ethernet/mellanox/mlx5/core/eq.c
>@@ -386,16 +386,20 @@ void mlx5_eq_disable(struct mlx5_core_dev *dev, struct mlx5_eq *eq,
> }
> EXPORT_SYMBOL(mlx5_eq_disable);
>
>-static int destroy_unmap_eq(struct mlx5_core_dev *dev, struct mlx5_eq *eq)
>+static int destroy_unmap_eq(struct mlx5_core_dev *dev, struct mlx5_eq *eq,
>+ bool reentry)
> {
> int err;
>
> mlx5_debug_eq_remove(dev, eq);
>
> err = mlx5_cmd_destroy_eq(dev, eq->eqn);
>- if (err)
>+ if (err) {
> mlx5_core_warn(dev, "failed to destroy a previously created eq: eqn %d\n",
> eq->eqn);
>+ if (reentry)
>+ return err;
>+ }
>
> mlx5_frag_buf_free(dev, &eq->frag_buf);
> return err;
>@@ -481,7 +485,7 @@ static int destroy_async_eq(struct mlx5_core_dev *dev, struct mlx5_eq *eq)
> int err;
>
> mutex_lock(&eq_table->lock);
>- err = destroy_unmap_eq(dev, eq);
>+ err = destroy_unmap_eq(dev, eq, false);
> mutex_unlock(&eq_table->lock);
> return err;
> }
>@@ -748,12 +752,15 @@ EXPORT_SYMBOL(mlx5_eq_create_generic);
>
> int mlx5_eq_destroy_generic(struct mlx5_core_dev *dev, struct mlx5_eq *eq)
> {
>+ struct mlx5_eq_table *eq_table = dev->priv.eq_table;
> int err;
>
> if (IS_ERR(eq))
> return -EINVAL;
>
>- err = destroy_async_eq(dev, eq);
>+ mutex_lock(&eq_table->lock);
Here you are inventing the re-entry.
Please drop this and fix properly. And avoid boolean parameters to mlx5 core
functions as much as possible, let's keep mlx5_core simple.
>+ err = destroy_unmap_eq(dev, eq, true);
>+ mutex_unlock(&eq_table->lock);
> if (err)
> goto out;
>
>@@ -851,7 +858,7 @@ static void destroy_comp_eqs(struct mlx5_core_dev *dev)
> list_for_each_entry_safe(eq, n, &table->comp_eqs_list, list) {
> list_del(&eq->list);
> mlx5_eq_disable(dev, &eq->core, &eq->irq_nb);
>- if (destroy_unmap_eq(dev, &eq->core))
>+ if (destroy_unmap_eq(dev, &eq->core, false))
> mlx5_core_warn(dev, "failed to destroy comp EQ 0x%x\n",
> eq->core.eqn);
> tasklet_disable(&eq->tasklet_ctx.task);
>@@ -915,7 +922,7 @@ static int create_comp_eqs(struct mlx5_core_dev *dev)
> goto clean_eq;
> err = mlx5_eq_enable(dev, &eq->core, &eq->irq_nb);
> if (err) {
>- destroy_unmap_eq(dev, &eq->core);
>+ destroy_unmap_eq(dev, &eq->core, false);
> goto clean_eq;
> }
>
>--
>2.35.1
>
next prev parent reply other threads:[~2022-04-05 20:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-05 8:12 [PATCH rdma-next 0/3] Handle FW failures to destroy QP/RQ objects Leon Romanovsky
2022-04-05 8:12 ` [PATCH mlx5-next 1/3] net/mlx5: Nullify eq->dbg and qp->dbg pointers post destruction Leon Romanovsky
2022-04-05 19:48 ` Saeed Mahameed [this message]
2022-04-06 7:55 ` Leon Romanovsky
2022-04-08 19:30 ` Saeed Mahameed
2022-04-10 7:58 ` Leon Romanovsky
2022-04-05 8:12 ` [PATCH rdma-next 2/3] RDMA/mlx5: Handling dct common resource destruction upon firmware failure Leon Romanovsky
2022-04-05 8:12 ` [PATCH rdma-next 3/3] RDMA/mlx5: Return the firmware result upon destroying QP/RQ Leon Romanovsky
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=20220405194845.c443x4gf522c2kgv@sx1 \
--to=saeed@kernel.org \
--cc=jgg@nvidia.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=phaddad@nvidia.com \
--cc=saeedm@nvidia.com \
--cc=yishaih@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox