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

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

[Christophe JAILLET]

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

[PATCH 1/3] gve: Fix an error handling path in 'gve_probe()'

[Christophe JAILLET]

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 <christophe.jaillet@wanadoo.fr>
---
 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

[PATCH 2/3] gve: Propagate error codes to caller

[Christophe JAILLET]

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 <christophe.jaillet@wanadoo.fr>
---
 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

[PATCH 3/3] gve: Simplify code and axe the use of a deprecated API

[Christophe JAILLET]

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 <christophe.jaillet@wanadoo.fr>
---
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

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

[Jeroen de Borst]

On Wed, Jun 30, 2021 at 10:58 PM Christophe JAILLET
<christophe.jaillet@wanadoo.fr> 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

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

[Christophe JAILLET]

Le 01/07/2021 à 18:20, Jeroen de Borst a écrit :
> On Wed, Jun 30, 2021 at 10:58 PM Christophe JAILLET
> <christophe.jaillet@wanadoo.fr> 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: 
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

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

[Jeroen de Borst]

On Thu, Jul 1, 2021 at 10:42 AM Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
>
> Le 01/07/2021 à 18:20, Jeroen de Borst a écrit :
> > On Wed, Jun 30, 2021 at 10:58 PM Christophe JAILLET
> > <christophe.jaillet@wanadoo.fr> 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:
> 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
>

[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!

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

[Dan Carpenter]

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