mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: han.junyang@zte.com.cn
Cc: Simon Horman <horms@kernel.org>,
	andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org, ran.ming@zte.com.cn,
	han.chengfei@zte.com.cn, zhang.yanze@zte.com.cn
Subject: Re: [PATCH net-next v2 3/3] dinghai: add async event queue for firmware notifications
Date: Mon, 14 Sep 2026 08:20:51 +0100	[thread overview]
Message-ID: <20260914072101.233003-1-horms@kernel.org> (raw)
In-Reply-To: <20260911120507276-LIb4JGajTovY-mjFYhKq@zte.com.cn>

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/#/patchset/20260911115929435mXJzcTF08xlUAdjnT8qqm@zte.com.cn?part=3
---
dinghai: add async event queue for firmware notifications

This commit adds an event queue table and an async event queue for firmware
notifications. The queue claims an MSI-X vector from the async pool and maps
firmware events to notifier chains.

> diff --git a/drivers/net/ethernet/zte/dinghai/en_pf.c b/drivers/net/ethernet/zte/dinghai/en_pf.c
> --- a/drivers/net/ethernet/zte/dinghai/en_pf.c
> +++ b/drivers/net/ethernet/zte/dinghai/en_pf.c
[ ... ]
> @@ -612,12 +612,26 @@ static int zxdh_pf_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>  		goto err_irq_table;
>  	}
>  
> +	ret = zxdh_pf_eq_table_init(zxdh_dev);
> +	if (ret) {
> +		dev_err(&pdev->dev, "zxdh_pf_eq_table_init failed: %d\n", ret);
> +		goto err_eq_table;
> +	}
> +
> +	ret = zxdh_pf_eq_table_create(zxdh_dev);
> +	if (ret) {
> +		dev_err(&pdev->dev, "zxdh_pf_eq_table_create failed: %d\n", ret);
> +		goto err_eq_table;
> +	}
> +
>  	devlink_register(devlink);
>  
>  	return 0;
>  
> +err_eq_table:
> +	zxdh_pf_eq_table_destroy(zxdh_dev);
>  err_irq_table:
> -	kvfree(zxdh_dev->irq_table.priv);
> +	zxdh_pf_irq_table_destroy(zxdh_dev);
>  err_cfg_init:
>  	zxdh_pf_pci_close(zxdh_dev);

[Severity: Medium]
Does this error path leak the modern configuration MMIO mappings?

The zxdh_pf_modern_cfg_init() function successfully maps several capabilities.
If a subsequent step fails (such as zxdh_pf_eq_table_init() or other device
initialization checks), the code jumps to err_eq_table and falls through to
err_cfg_init. However, this label only calls zxdh_pf_pci_close() and misses
a call to zxdh_pf_modern_cfg_uninit(), leaving the memory mapped.

>  err_pci_init:
[ ... ]
> diff --git a/drivers/net/ethernet/zte/dinghai/zxdh_eq.c b/drivers/net/ethernet/zte/dinghai/zxdh_eq.c
> --- /dev/null
> +++ b/drivers/net/ethernet/zte/dinghai/zxdh_eq.c
[ ... ]
> +static u16 zxdh_eq_event_id_get(struct zxdh_core_dev *zxdh_dev)
> +{
> +	struct zxdh_pf_dev *pf_dev = zxdh_dev->priv;
> +	void __iomem *subchan;
> +
> +	subchan = pf_dev->pci_ioremap_addr[0] + ZXDH_BAR_MSG_SUBCHAN_RECV;
> +
> +	return ioread32(subchan) >> 16;
> +}

[Severity: High]
Is there a risk of an out-of-bounds MMIO read here?

The device blindly maps BAR 0 based on pci_resource_len() during
zxdh_pf_pci_init(). If the hardware or an emulated environment exposes a
truncated BAR 0 length that is smaller than 0x2804 bytes, reading from
ZXDH_BAR_MSG_SUBCHAN_RECV (offset 0x2800) could exceed the mapped boundaries
and cause a page fault or oops.

[ ... ]
> +int zxdh_pf_eq_table_create(struct zxdh_core_dev *zxdh_dev)
> +{
> +	struct zxdh_pf_eq_table *pf_eq_table = zxdh_dev->eq_table.priv;
> +	struct zxdh_eq_table *table = &zxdh_dev->eq_table;
> +	struct zxdh_eq_async *eq = &pf_eq_table->riscv_eq;
> +	int err;
> +
> +	mutex_lock(&table->lock);
> +
> +	eq->priv = zxdh_dev;
> +	eq->irq = zxdh_pf_async_irq_request(zxdh_dev);
> +	if (IS_ERR(eq->irq)) {
> +		err = PTR_ERR(eq->irq);
> +		goto unlock;
> +	}

[Severity: High]
Could this lead to an invalid pointer dereference on the cleanup path?

If zxdh_pf_async_irq_request() fails (e.g., due to memory exhaustion), it
returns an error pointer like ERR_PTR(-ENOMEM). This error pointer is
assigned to eq->irq but is not cleared to NULL before jumping to unlock.

When the error propagates, zxdh_pf_probe() jumps to the err_eq_table label
and calls zxdh_pf_eq_table_destroy().

Because eq->irq contains an error pointer, the cleanup check in
zxdh_pf_eq_table_destroy():

    if (eq->irq) {
        zxdh_irq_detach_nb(eq->irq, &eq->irq_nb);
        ...

will evaluate to true, and zxdh_irq_detach_nb() will attempt to dereference
the error pointer, causing a kernel panic.

> +
> +	eq->irq_nb.notifier_call = zxdh_eq_async_riscv_int;
> +	err = zxdh_irq_attach_nb(eq->irq, &eq->irq_nb);
[ ... ]

      reply	other threads:[~2026-09-14  7:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-11  3:56 [PATCH net-next v2 0/3] dinghai: firmware handshake, MSI-X pools and async event queues han.junyang
2026-09-11  3:59 ` [PATCH net-next v2 1/3] dinghai: add firmware version check and RISC-V readiness polling han.junyang
2026-09-14  7:20   ` Simon Horman
2026-09-11  4:02 ` [PATCH net-next v2 2/3] dinghai: add MSI-X interrupt pools han.junyang
2026-09-14  7:20   ` Simon Horman
2026-09-11  4:05 ` [PATCH net-next v2 3/3] dinghai: add async event queue for firmware notifications han.junyang
2026-09-14  7:20   ` 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=20260914072101.233003-1-horms@kernel.org \
    --to=horms@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=han.chengfei@zte.com.cn \
    --cc=han.junyang@zte.com.cn \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=ran.ming@zte.com.cn \
    --cc=zhang.yanze@zte.com.cn \
    /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

all inboxes | Powered by JetHome®