This serie is part of the effort to axe the wrappers in
include/linux/pci-dma-compat.h
While looking at it, I spotted:
- a resource leak in an error handling path (patch 1)
- an error code that could be propagated. (patch 2)
This patch could be ignored. It's only goal is to be more consistent
with other drivers.
These 2 paches are not related to the 'pci-dma-compat.h' stuff, which can
be found in patch 3.
Christophe JAILLET (3):
gve: Fix an error handling path in 'gve_probe()'
gve: Propagate error codes to caller
gve: Simplify code and axe the use of a deprecated API
drivers/net/ethernet/google/gve/gve_main.c | 19 ++++++++-----------
1 file changed, 8 insertions(+), 11 deletions(-)
--
2.30.2
If the 'register_netdev() call fails, we must release the resources
allocated by the previous 'gve_init_priv()' call, as already done in the
remove function.
Add a new label and the missing 'gve_teardown_priv_resources()' in the
error handling path.
Fixes: 893ce44df565 ("gve: Add basic driver framework for Compute Engine Virtual NIC")
Signed-off-by: Christophe JAILLET <[email protected]>
---
drivers/net/ethernet/google/gve/gve_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
index 867e87af3432..32166ebc0f01 100644
--- a/drivers/net/ethernet/google/gve/gve_main.c
+++ b/drivers/net/ethernet/google/gve/gve_main.c
@@ -1565,7 +1565,7 @@ static int gve_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
err = register_netdev(dev);
if (err)
- goto abort_with_wq;
+ goto abort_with_vge_init;
dev_info(&pdev->dev, "GVE version %s\n", gve_version_str);
dev_info(&pdev->dev, "GVE queue format %d\n", (int)priv->queue_format);
@@ -1573,6 +1573,9 @@ static int gve_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
queue_work(priv->gve_wq, &priv->service_task);
return 0;
+abort_with_vge_init:
+ gve_teardown_priv_resources(priv);
+
abort_with_wq:
destroy_workqueue(priv->gve_wq);
--
2.30.2
The wrappers in include/linux/pci-dma-compat.h should go away.
Replace 'pci_set_dma_mask/pci_set_consistent_dma_mask' by an equivalent
and less verbose 'dma_set_mask_and_coherent()' call.
Signed-off-by: Christophe JAILLET <[email protected]>
---
If needed, see post from Christoph Hellwig on the kernel-janitors ML:
https://marc.info/?l=kernel-janitors&m=158745678307186&w=4
---
drivers/net/ethernet/google/gve/gve_main.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
index 85a5076dc788..53a39c024456 100644
--- a/drivers/net/ethernet/google/gve/gve_main.c
+++ b/drivers/net/ethernet/google/gve/gve_main.c
@@ -1477,19 +1477,12 @@ static int gve_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
pci_set_master(pdev);
- err = pci_set_dma_mask(pdev, DMA_BIT_MASK(64));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
if (err) {
dev_err(&pdev->dev, "Failed to set dma mask: err=%d\n", err);
goto abort_with_pci_region;
}
- err = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64));
- if (err) {
- dev_err(&pdev->dev,
- "Failed to set consistent dma mask: err=%d\n", err);
- goto abort_with_pci_region;
- }
-
reg_bar = pci_iomap(pdev, GVE_REGISTER_BAR, 0);
if (!reg_bar) {
dev_err(&pdev->dev, "Failed to map pci bar!\n");
--
2.30.2
If 'gve_probe()' fails, we should propagate the error code, instead of
hard coding a -ENXIO value.
Make sure that all error handling paths set a correct value for 'err'.
Signed-off-by: Christophe JAILLET <[email protected]>
---
drivers/net/ethernet/google/gve/gve_main.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
index 32166ebc0f01..85a5076dc788 100644
--- a/drivers/net/ethernet/google/gve/gve_main.c
+++ b/drivers/net/ethernet/google/gve/gve_main.c
@@ -1469,7 +1469,7 @@ static int gve_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
err = pci_enable_device(pdev);
if (err)
- return -ENXIO;
+ return err;
err = pci_request_regions(pdev, "gvnic-cfg");
if (err)
@@ -1512,6 +1512,7 @@ static int gve_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
dev = alloc_etherdev_mqs(sizeof(*priv), max_tx_queues, max_rx_queues);
if (!dev) {
dev_err(&pdev->dev, "could not allocate netdev\n");
+ err = -ENOMEM;
goto abort_with_db_bar;
}
SET_NETDEV_DEV(dev, &pdev->dev);
@@ -1593,7 +1594,7 @@ static int gve_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
abort_with_enabled:
pci_disable_device(pdev);
- return -ENXIO;
+ return err;
}
static void gve_remove(struct pci_dev *pdev)
--
2.30.2
On Wed, Jun 30, 2021 at 10:58 PM Christophe JAILLET
<[email protected]> wrote:
>
> This serie is part of the effort to axe the wrappers in
> include/linux/pci-dma-compat.h
>
> While looking at it, I spotted:
> - a resource leak in an error handling path (patch 1)
> - an error code that could be propagated. (patch 2)
> This patch could be ignored. It's only goal is to be more consistent
> with other drivers.
>
> These 2 paches are not related to the 'pci-dma-compat.h' stuff, which can
> be found in patch 3.
>
> Christophe JAILLET (3):
> gve: Fix an error handling path in 'gve_probe()'
> gve: Propagate error codes to caller
> gve: Simplify code and axe the use of a deprecated API
>
>
Thanks for these patches.
Can split this into 2 patch series; one for net (with the first 2
patches) and one for net-next (with the cleanup one)?
Also the label in the first patch should probably read
'abort_with_gve_init' instead of 'abort_with_vge_init'.
Jeroen
Le 01/07/2021 à 18:20, Jeroen de Borst a écrit :
> On Wed, Jun 30, 2021 at 10:58 PM Christophe JAILLET
> <[email protected]> wrote:
>>
>> This serie is part of the effort to axe the wrappers in
>> include/linux/pci-dma-compat.h
>>
>> While looking at it, I spotted:
>> - a resource leak in an error handling path (patch 1)
>> - an error code that could be propagated. (patch 2)
>> This patch could be ignored. It's only goal is to be more consistent
>> with other drivers.
>>
>> These 2 paches are not related to the 'pci-dma-compat.h' stuff, which can
>> be found in patch 3.
>>
>> Christophe JAILLET (3):
>> gve: Fix an error handling path in 'gve_probe()'
>> gve: Propagate error codes to caller
>> gve: Simplify code and axe the use of a deprecated API
>>
>>
>
> Thanks for these patches.
>
> Can split this into 2 patch series;
Sure.
> one for net (with the first 2
> patches) and one for net-next (with the cleanup one)?
I've never worked with net and net-next directly.
If just adding net and net-next after [PATCH] in the subject of the
mail, yes, I can do it if it helps.
BTW, I gave a look at https://patchwork.kernel.org/project/netdevbpf/list/
The patch 1/3 is marked as failed because "1 blamed authors not CCed:
[email protected]; 1 maintainers not CCed: [email protected]"
This author/blame was not spotted by get_maintainer.pl. Is it something
I should worry about?
> Also the label in the first patch should probably read
> 'abort_with_gve_init' instead of 'abort_with_vge_init'.
Good catch. Sorry about that.
>
> Jeroen
>
CJ
On Thu, Jul 1, 2021 at 10:42 AM Christophe JAILLET
<[email protected]> wrote:
>
> Le 01/07/2021 à 18:20, Jeroen de Borst a écrit :
> > On Wed, Jun 30, 2021 at 10:58 PM Christophe JAILLET
> > <[email protected]> wrote:
> >>
> >> This serie is part of the effort to axe the wrappers in
> >> include/linux/pci-dma-compat.h
> >>
> >> While looking at it, I spotted:
> >> - a resource leak in an error handling path (patch 1)
> >> - an error code that could be propagated. (patch 2)
> >> This patch could be ignored. It's only goal is to be more consistent
> >> with other drivers.
> >>
> >> These 2 paches are not related to the 'pci-dma-compat.h' stuff, which can
> >> be found in patch 3.
> >>
> >> Christophe JAILLET (3):
> >> gve: Fix an error handling path in 'gve_probe()'
> >> gve: Propagate error codes to caller
> >> gve: Simplify code and axe the use of a deprecated API
> >>
> >>
> >
> > Thanks for these patches.
> >
> > Can split this into 2 patch series;
>
> Sure.
>
> > one for net (with the first 2
> > patches) and one for net-next (with the cleanup one)?
>
> I've never worked with net and net-next directly.
> If just adding net and net-next after [PATCH] in the subject of the
> mail, yes, I can do it if it helps.
>
>
> BTW, I gave a look at https://patchwork.kernel.org/project/netdevbpf/list/
> The patch 1/3 is marked as failed because "1 blamed authors not CCed:
> [email protected]; 1 maintainers not CCed: [email protected]"
>
> This author/blame was not spotted by get_maintainer.pl. Is it something
> I should worry about?
>
>
> > Also the label in the first patch should probably read
> > 'abort_with_gve_init' instead of 'abort_with_vge_init'.
>
> Good catch. Sorry about that.
>
> >
> > Jeroen
> >
>
> CJ
>
[again, now in plaintext, sorry for the spam]
You tag the patch sets with [PATCH net <n>/2] for the 2 fixes and just
[PATCH net-next] for the cleanup one.
You can cc Luigi ([email protected]) on that one patch for
completeness, but I think it shouldn't be necessary.
Thanks!
On Thu, Jul 01, 2021 at 07:42:48PM +0200, Christophe JAILLET wrote:
> > one for net (with the first 2
> > patches) and one for net-next (with the cleanup one)?
>
> I've never worked with net and net-next directly.
> If just adding net and net-next after [PATCH] in the subject of the mail,
> yes, I can do it if it helps.
I have a separate tree that I use for sending net patches. I generally
write my patches against linux-next and then postpone sending them until
the next day.
Then I open my patch in mutt.
cd tmp_tree/
../switch_to_net.sh
cat /var/tmp/mutt-speke-1000-511162-9994856746594827871 | patch -p1 --dry-run
If that applies then I "net" to the subject. Otherwise I do a
`../switch_to_net-next.sh` verify it applies and send that.
Once in a while I will have to modify my patches to apply cleanly
against the net tree.
It's a pain in the butt and I get it wrong disappointingly often. I
only do it for networking. Not for linux-wireless. There is another
tree where they complain if you don't add a tree to their patches but I
forget what it is... (I don't use the process for them, only for
networking).
regards,
dan carpenter