Linux Documentation
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: illusion.wang@nebula-matrix.com
Cc: dimon.zhao@nebula-matrix.com, alvin.wang@nebula-matrix.com,
	sam.chen@nebula-matrix.com, netdev@vger.kernel.org,
	andrew+netdev@lunn.ch, corbet@lwn.net, kuba@kernel.org,
	horms@kernel.org, linux-doc@vger.kernel.org, pabeni@redhat.com,
	vadim.fedorenko@linux.dev, lukas.bulwahn@redhat.com,
	edumazet@google.com, enelsonmoore@gmail.com,
	skhan@linuxfoundation.org, hkallweit1@gmail.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v20 net-next 06/10] net/nebula-matrix: add intr resource implementation
Date: Thu,  2 Jul 2026 11:42:53 +0200	[thread overview]
Message-ID: <20260702094253.111384-1-pabeni@redhat.com> (raw)
In-Reply-To: <20260630010718.4346-7-illusion.wang@nebula-matrix.com>

From: AI Reviewer <ai@example.com>

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev/
---
net/nebula-matrix: add intr resource implementation

This patch adds the nbl_interrupt module for management of driver-private
MSI-X indices. It adds hw_ops callbacks to program the function MSI-X mapping
registers, configure MSI-X info, and enable mailbox interrupts.

> diff --git a/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_interrupt.c b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_interrupt.c
> new file mode 100644
> index 0000000000000..53a657aef9ca0
> --- /dev/null
> +++ b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_interrupt.c
> @@ -0,0 +1,267 @@
[ ... ]
> +/*
> + * This function tears down the MSI-X mapping for a function by clearing the
> + * interrupt bitmaps, disabling MSI-X via HW callbacks, and resetting the
> + * bookkeeping state. The DMA buffer and interrupts[] array are intentionally
> + * left allocated for potential reuse on reset/hot-add paths. Caller must
> + * ensure this is only invoked when the HW cannot issue in-flight DMA to
> + * the region (IRQs already freed or not yet configured).
> + */
> +int nbl_res_intr_destroy_msix_map(struct nbl_resource_mgt *res_mgt,
> +				  u16 func_id)
> +{
[ ... ]
> +	/* use ctrl dev bdf */
> +	hw_ops->configure_msix_map(res_mgt->hw_ops_tbl->priv, func_id, false, 0,
> +				   0, 0, 0);
> +
> +	intr_mgt->func_intr_res[func_id].interrupts = NULL;
> +	intr_mgt->func_intr_res[func_id].num_interrupts = 0;
> +	intr_mgt->func_intr_res[func_id].msix_map_table.base_addr = NULL;
> +	intr_mgt->func_intr_res[func_id].msix_map_table.size = 0;
> +	hw_ops->flush_write(res_mgt->hw_ops_tbl->priv);
> +
> +	return 0;
> +}

[Severity: High]
Does this code leak the devm-managed resources? The comment mentions that
the DMA buffer and interrupts array are left allocated for potential reuse,
but the pointers are set to NULL here. This causes the pointers to be lost
so they cannot be reused or explicitly freed later.

Because nbl_res_intr_configure_msix_map() unconditionally allocates new devres
memory on every call, won't this cause the devres list to accumulate leaked
allocations (dmam_alloc_coherent and devm_kcalloc) each time the device is
reset or a VF is reconfigured?

[ ... ]
> +int nbl_res_intr_configure_msix_map(struct nbl_resource_mgt *res_mgt,
> +				    u16 func_id, u16 num_net_msix,
> +				    u16 num_others_msix,
> +				    bool net_msix_mask_en)
> +{
[ ... ]
> +	nbl_res_intr_destroy_msix_map(res_mgt, func_id);
> +
> +	msix_map_table = &intr_mgt->func_intr_res[func_id].msix_map_table;
> +	WARN_ON(msix_map_table->base_addr);
> +	msix_map_table->size =
> +		sizeof(struct nbl_msix_map) * NBL_MSIX_MAP_TABLE_MAX_ENTRIES;
> +	/* HW indexes the MSI-X map table with a fixed stride of 1024 entries,
> +	 * so we must allocate the full table even if fewer vectors are used.
> +	 */
> +	msix_map_table->base_addr = dmam_alloc_coherent(dev,
> +							msix_map_table->size,
> +							&msix_map_table->dma,
> +							GFP_KERNEL);
> +	if (!msix_map_table->base_addr) {
> +		dev_err(dev, "Allocate DMA memory for function msix map table failed\n");
> +		msix_map_table->size = 0;
> +		return -ENOMEM;
> +	}
> +
> +	interrupts = devm_kcalloc(dev, requested, sizeof(interrupts[0]),
> +				  GFP_KERNEL);
> +	if (!interrupts) {
> +		ret = -ENOMEM;
> +		goto alloc_interrupts_err;
> +	}

[Severity: High]
If devm_kcalloc() fails, the goto alloc_interrupts_err path bypasses
clearing msix_map_table->base_addr and size. 

While nbl_res_intr_destroy_msix_map() clears it unconditionally on the next
call, doesn't this leave the internal state inconsistent by keeping base_addr
populated when interrupts is NULL?

[ ... ]
> +get_interrupt_err:
> +	while (i--) {
> +		intr_index = interrupts[i];
> +		if (intr_index >= NBL_NET_INTR_BASE)
> +			clear_bit(intr_index - NBL_NET_INTR_BASE,
> +				  intr_mgt->interrupt_net_bitmap);
> +		else
> +			clear_bit(intr_index,
> +				  intr_mgt->interrupt_others_bitmap);
> +	}
> +
> +	intr_mgt->func_intr_res[func_id].num_interrupts = 0;
> +	intr_mgt->func_intr_res[func_id].interrupts = NULL;
> +	intr_mgt->func_intr_res[func_id].num_net_interrupts = 0;
> +	intr_mgt->func_intr_res[func_id].msix_map_table.base_addr = NULL;
> +	intr_mgt->func_intr_res[func_id].msix_map_table.size = 0;
> +alloc_interrupts_err:
> +	return ret;
> +}
-- 
This is an AI-generated review.


  reply	other threads:[~2026-07-02  9:43 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-30  1:07 [PATCH v20 net-next 00/10] nbl driver for Nebulamatrix NICs illusion.wang
2026-06-30  1:07 ` [PATCH v20 net-next 01/10] net/nebula-matrix: add minimum nbl build framework illusion.wang
2026-06-30  1:07 ` [PATCH v20 net-next 02/10] net/nebula-matrix: add our driver architecture illusion.wang
2026-06-30  1:07 ` [PATCH v20 net-next 03/10] net/nebula-matrix: channel msg value and msg struct illusion.wang
2026-06-30  1:07 ` [PATCH v20 net-next 04/10] net/nebula-matrix: add channel layer illusion.wang
2026-07-02  9:42   ` Paolo Abeni
2026-06-30  1:07 ` [PATCH v20 net-next 05/10] net/nebula-matrix: add common resource implementation illusion.wang
2026-07-02  9:42   ` Paolo Abeni
2026-06-30  1:07 ` [PATCH v20 net-next 06/10] net/nebula-matrix: add intr " illusion.wang
2026-07-02  9:42   ` Paolo Abeni [this message]
2026-06-30  1:07 ` [PATCH v20 net-next 07/10] net/nebula-matrix: add vsi " illusion.wang
2026-06-30  1:07 ` [PATCH v20 net-next 08/10] net/nebula-matrix: add Dispatch layer implementation illusion.wang
2026-07-02  9:43   ` Paolo Abeni
2026-06-30  1:07 ` [PATCH v20 net-next 09/10] net/nebula-matrix: add common/ctrl dev init/remove operation illusion.wang
2026-07-02  9:43   ` Paolo Abeni
2026-06-30  1:07 ` [PATCH v20 net-next 10/10] net/nebula-matrix: add common dev start/stop operation illusion.wang
2026-07-02  9:43   ` Paolo Abeni

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=20260702094253.111384-1-pabeni@redhat.com \
    --to=pabeni@redhat.com \
    --cc=alvin.wang@nebula-matrix.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=corbet@lwn.net \
    --cc=dimon.zhao@nebula-matrix.com \
    --cc=edumazet@google.com \
    --cc=enelsonmoore@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=horms@kernel.org \
    --cc=illusion.wang@nebula-matrix.com \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas.bulwahn@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=sam.chen@nebula-matrix.com \
    --cc=skhan@linuxfoundation.org \
    --cc=vadim.fedorenko@linux.dev \
    /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