[PATCH 0/3] gve: Fixes and clean-up

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 <redacted>
---
 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

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 <redacted>
---
 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

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 <redacted>
---
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

On Wed, Jun 30, 2021 at 10:58 PM Christophe JAILLET
[off-list ref] 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
[off-list ref] wrote:

quoted

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: 
lrizzo@google.com; 1 maintainers not CCed: lrizzo@google.com"

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
[off-list ref] wrote:

Le 01/07/2021 à 18:20, Jeroen de Borst a écrit :

quoted

On Wed, Jun 30, 2021 at 10:58 PM Christophe JAILLET
[off-list ref] wrote:

quoted

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.

quoted

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:
lrizzo@google.com; 1 maintainers not CCed: lrizzo@google.com"

This author/blame was not spotted by get_maintainer.pl. Is it something
I should worry about?

quoted

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.

quoted

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 (lrizzo@google.com) 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:

quoted

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