linux-kernel - Re: [v4,net-next,07/11] net/nebula-matrix: add intr resource implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260207022457.4017922-1-kuba@kernel.org>
Date: Fri,  6 Feb 2026 18:24:57 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: illusion.wang@...ula-matrix.com
Cc: Jakub Kicinski <kuba@...nel.org>,
	sam.chen@...ula-matrix.com,
	lukas.bulwahn@...hat.com,
	dimon.zhao@...ula-matrix.com,
	netdev@...r.kernel.org,
	vadim.fedorenko@...ux.dev,
	linux-kernel@...r.kernel.org (open list),
	corbet@....net,
	lorenzo@...nel.org,
	alvin.wang@...ula-matrix.com,
	andrew+netdev@...n.ch,
	linux-doc@...r.kernel.org,
	pabeni@...hat.com,
	edumazet@...gle.com,
	horms@...nel.org
Subject: Re: [v4,net-next,07/11] net/nebula-matrix: add intr resource implementation

This is an AI-generated review of your patch. The human sending this
email says "This is an automated AI code reviewer, please treat what
it says with a grain of salt."

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net/nebula-matrix: add intr resource implementation

This commit adds MSI-X interrupt resource management for the Nebula Matrix
network driver, including interrupt vector allocation, mapping table
maintenance, and hardware interrupt enable/disable operations.

> 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
> --- /dev/null
> +++ b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_interrupt.c

[ ... ]

> +static 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)
> +{
> +	struct nbl_interrupt_mgt *intr_mgt = res_mgt->intr_mgt;
> +	struct nbl_hw_ops *hw_ops = res_mgt->hw_ops_tbl->ops;
> +	struct nbl_common_info *common = res_mgt->common;
> +	struct nbl_msix_map_table *msix_map_table;
> +	struct nbl_msix_map *msix_map_entries;
> +	struct device *dev = common->dev;
> +	u16 requested, intr_index;
> +	u8 bus, devid, function;
> +	bool msix_mask_en;
> +	u16 *interrupts;
> +	int ret = 0;
> +	u16 i;
> +
> +	if (intr_mgt->func_intr_res[func_id].interrupts)
> +		nbl_res_intr_destroy_msix_map(res_mgt, func_id);
> +
> +	nbl_res_func_id_to_bdf(res_mgt, func_id, &bus, &devid, &function);

Should the return value of nbl_res_func_id_to_bdf() be checked here?

Looking at nbl_res_func_id_to_bdf(), it returns U32_MAX when func_id is invalid:

    if (func_id >= NBL_RES_MGT_TO_PF_NUM(res_mgt) + ...)
        return U32_MAX;

When that happens, the output parameters bus, devid, and function are not
written, leaving them uninitialized. These values are then passed to
hw_ops->configure_msix_info() further down in the function.

> +
> +	msix_map_table = &intr_mgt->func_intr_res[func_id].msix_map_table;

[ ... ]