From: Jakub Kicinski <kuba@kernel.org>
To: xuanzhuo@linux.alibaba.com
Cc: Jakub Kicinski <kuba@kernel.org>,
lorenzo@kernel.org, andrew+netdev@lunn.ch, hkallweit1@gmail.com,
dust.li@linux.alibaba.com, edumazet@google.com,
davem@davemloft.net, pabeni@redhat.com, lulie@linux.alibaba.com,
andrew@lunn.ch, netdev@vger.kernel.org, guwen@linux.alibaba.com,
dong100@mucse.com, lukas.bulwahn@redhat.com,
vadim.fedorenko@linux.dev, enelsonmoore@gmail.com
Subject: Re: [net-next,v24,1/6] eea: introduce PCI framework
Date: Fri, 30 Jan 2026 15:32:38 -0800 [thread overview]
Message-ID: <20260130233238.923339-1-kuba@kernel.org> (raw)
In-Reply-To: <20260130093412.98407-2-xuanzhuo@linux.alibaba.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.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
eea: introduce PCI framework
Add basic driver framework for the Alibaba Elastic Ethernet Adapter(EEA).
This commit implements the EEA PCI probe functionality.
> diff --git a/drivers/net/ethernet/alibaba/Kconfig b/drivers/net/ethernet/alibaba/Kconfig
> --- /dev/null
> +++ b/drivers/net/ethernet/alibaba/Kconfig
> @@ -0,0 +1,28 @@
> +#
> +# Alibaba network device configuration
> +#
> +
> +config NET_VENDOR_ALIBABA
> + bool "Alibaba Devices"
> + default y
> + help
> + If you have a network (Ethernet) device belonging to this class, say Y.
> +
> + Note that the answer to this question doesn't directly affect the
> + kernel: saying N will just cause the configurator to skip all
> + the questions about Alibaba devices. If you say Y, you will be asked
> + for your specific device in the following questions.
> +
> +if NET_VENDOR_ALIBABA
> +
> +config EEA
> + tristate "Alibaba Elastic Ethernet Adapter support"
> + depends on PCI_MSI
> + depends on 64BIT
> + select PAGE_POOL
> + help
> + This driver supports Alibaba Elastic Ethernet Adapter"
^
This isn't a bug, but the help text ends with an unmatched trailing quote.
This should likely be a period instead.
[ ... ]
> diff --git a/drivers/net/ethernet/alibaba/eea/eea_pci.c b/drivers/net/ethernet/alibaba/eea/eea_pci.c
> --- /dev/null
> +++ b/drivers/net/ethernet/alibaba/eea/eea_pci.c
[ ... ]
> +static int eea_init_device(struct eea_device *edev)
> +{
> + int err;
> +
> + err = eea_device_reset(edev);
> + if (err)
> + return err;
> +
> + eea_pci_io_set_status(edev, BIT(0) | BIT(1));
> +
> + err = eea_negotiate(edev);
> + if (err)
> + goto err;
> +
> + /* do net device probe ... */
> +
> + return 0;
> +err:
> + eea_add_status(edev, EEA_S_FAILED);
> + return err;
> +}
> +
> +static int __eea_pci_probe(struct pci_dev *pci_dev,
> + struct eea_pci_device *ep_dev)
> +{
> + int err;
> +
> + pci_set_drvdata(pci_dev, ep_dev);
> +
> + err = eea_pci_setup(pci_dev, ep_dev);
> + if (err)
> + return err;
> +
> + err = eea_init_device(&ep_dev->edev);
> + if (err)
> + goto err_pci_rel;
If eea_init_device() fails here, can this create a use-after-free issue?
The function sets pci_set_drvdata() at the beginning, then if
eea_init_device() fails, the error path jumps to err_pci_rel which
calls eea_pci_release_resource() but doesn't clear the driver data.
Control then returns to eea_pci_probe():
eea_pci_probe()->__eea_pci_probe():
pci_set_drvdata(pci_dev, ep_dev); // sets driver data
err = eea_init_device(&ep_dev->edev);
if (err)
goto err_pci_rel; // jumps on failure
err_pci_rel:
eea_pci_release_resource(ep_dev); // doesn't clear driver data
return err; // returns to eea_pci_probe
Back in eea_pci_probe:
err = __eea_pci_probe(pci_dev, ep_dev);
if (err)
kfree(ep_dev); // frees memory, driver data
// still points to freed memory
Would it make sense to either move pci_set_drvdata() after successful
initialization, or add pci_set_drvdata(pci_dev, NULL) in the error path?
> +
> + return 0;
> +
> +err_pci_rel:
> + eea_pci_release_resource(ep_dev);
> + return err;
> +}
[ ... ]
> +static int eea_pci_probe(struct pci_dev *pci_dev,
> + const struct pci_device_id *id)
> +{
> + struct eea_pci_device *ep_dev;
> + struct eea_device *edev;
> + int err;
> +
> + ep_dev = kzalloc(sizeof(*ep_dev), GFP_KERNEL);
> + if (!ep_dev)
> + return -ENOMEM;
> +
> + edev = &ep_dev->edev;
> +
> + edev->ep_dev = ep_dev;
> + edev->dma_dev = &pci_dev->dev;
> +
> + ep_dev->pci_dev = pci_dev;
> +
> + err = __eea_pci_probe(pci_dev, ep_dev);
> + if (err)
> + kfree(ep_dev);
> +
> + return err;
> +}
--
pw-bot: cr
next prev parent reply other threads:[~2026-01-30 23:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-30 9:34 [PATCH net-next v24 0/6] eea: Add basic driver framework for Alibaba Elastic Ethernet Adaptor Xuan Zhuo
2026-01-30 9:34 ` [PATCH net-next v24 1/6] eea: introduce PCI framework Xuan Zhuo
2026-01-30 23:32 ` Jakub Kicinski [this message]
2026-01-30 9:34 ` [PATCH net-next v24 2/6] eea: introduce ring and descriptor structures Xuan Zhuo
2026-01-30 23:32 ` [net-next,v24,2/6] " Jakub Kicinski
2026-01-30 9:34 ` [PATCH net-next v24 3/6] eea: probe the netdevice and create adminq Xuan Zhuo
2026-01-30 9:34 ` [PATCH net-next v24 4/6] eea: create/destroy rx,tx queues for netdevice open and stop Xuan Zhuo
2026-01-30 23:32 ` [net-next,v24,4/6] " Jakub Kicinski
2026-02-02 3:23 ` Xuan Zhuo
2026-01-30 9:34 ` [PATCH net-next v24 5/6] eea: introduce ethtool support Xuan Zhuo
2026-01-30 9:34 ` [PATCH net-next v24 6/6] eea: introduce callback for ndo_get_stats64 Xuan Zhuo
2026-01-30 23:32 ` [net-next,v24,6/6] " Jakub Kicinski
2026-02-02 2:09 ` Xuan Zhuo
2026-01-31 0:20 ` [PATCH net-next v24 0/6] eea: Add basic driver framework for Alibaba Elastic Ethernet Adaptor Ethan Nelson-Moore
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=20260130233238.923339-1-kuba@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=dong100@mucse.com \
--cc=dust.li@linux.alibaba.com \
--cc=edumazet@google.com \
--cc=enelsonmoore@gmail.com \
--cc=guwen@linux.alibaba.com \
--cc=hkallweit1@gmail.com \
--cc=lorenzo@kernel.org \
--cc=lukas.bulwahn@redhat.com \
--cc=lulie@linux.alibaba.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=vadim.fedorenko@linux.dev \
--cc=xuanzhuo@linux.alibaba.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