[PATCH net V3] net: stmmac: Premature loop termination check was ignored

The premature loop termination check makes sense only in case of the
jump to read_again where the count may have been updated. But
read_again did not include the check.

Fixes: bba2556efad6 ("net: stmmac: Enable RX via AF_XDP zero-copy")
Fixes: ec222003bd94 ("net: stmmac: Prepare to add Split Header support")
Signed-off-by: Jochen Henneberg <redacted>
---
V2: Added fixes tags
V3: Fixed fixes tag format

 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 1a5b8dab5e9b..de98c009866a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c

@@ -5031,10 +5031,10 @@ static int stmmac_rx_zc(struct stmmac_priv *priv, int limit, u32 queue)
 			len = 0;
 		}
 
+read_again:
 		if (count >= limit)
 			break;
 
-read_again:
 		buf1_len = 0;
 		entry = next_entry;
 		buf = &rx_q->buf_pool[entry];

@@ -5221,10 +5221,10 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
 			len = 0;
 		}
 
+read_again:
 		if (count >= limit)
 			break;
 
-read_again:
 		buf1_len = 0;
 		buf2_len = 0;
 		entry = next_entry;

-- 
2.39.2

On Wed, Feb 22, 2023 at 08:38:28AM +0100, Jochen Henneberg wrote:

The premature loop termination check makes sense only in case of the
jump to read_again where the count may have been updated. But
read_again did not include the check.

Fixes: bba2556efad6 ("net: stmmac: Enable RX via AF_XDP zero-copy")

This commit was included in v5.13

Fixes: ec222003bd94 ("net: stmmac: Prepare to add Split Header support")

While this one was included in v5.4

It seems to me that each of the above commits correspond to one
of the two hunks below. I don't know if that means this
patch should be split in two to assist backporting.

Signed-off-by: Jochen Henneberg <redacted>

That aside, this looks good to me.

Reviewed-by: Simon Horman <redacted>

Simon Horman [off-list ref] writes:

On Wed, Feb 22, 2023 at 08:38:28AM +0100, Jochen Henneberg wrote:

quoted

The premature loop termination check makes sense only in case of the
jump to read_again where the count may have been updated. But
read_again did not include the check.

Fixes: bba2556efad6 ("net: stmmac: Enable RX via AF_XDP zero-copy")

This commit was included in v5.13

quoted

Fixes: ec222003bd94 ("net: stmmac: Prepare to add Split Header support")

While this one was included in v5.4

It seems to me that each of the above commits correspond to one
of the two hunks below. I don't know if that means this
patch should be split in two to assist backporting.

I was thinking about this already but the change was so trivial that I
hesitated to split it into two commits. I wanted I will surely change
this.

quoted

Signed-off-by: Jochen Henneberg <redacted>

That aside, this looks good to me.

Reviewed-by: Simon Horman <redacted>

quoted

---
V2: Added fixes tags
V3: Fixed fixes tag format

 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 1a5b8dab5e9b..de98c009866a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c

@@ -5031,10 +5031,10 @@ static int stmmac_rx_zc(struct stmmac_priv *priv, int limit, u32 queue)
 			len = 0;
 		}
 
+read_again:
 		if (count >= limit)
 			break;
 
-read_again:
 		buf1_len = 0;
 		entry = next_entry;
 		buf = &rx_q->buf_pool[entry];

@@ -5221,10 +5221,10 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
 			len = 0;
 		}
 
+read_again:
 		if (count >= limit)
 			break;
 
-read_again:
 		buf1_len = 0;
 		buf2_len = 0;
 		entry = next_entry;

-- 
2.39.2

-- 
Henneberg - Systemdesign
Jochen Henneberg
Loehnfeld 26
21423 Winsen (Luhe)
--
Fon: +49 172 160 14 69
Url: https://www.henneberg-systemdesign.com

On Wed, Feb 22, 2023 at 04:49:55PM +0100, Henneberg - Systemdesign wrote:

Simon Horman [off-list ref] writes:

quoted

On Wed, Feb 22, 2023 at 08:38:28AM +0100, Jochen Henneberg wrote:

quoted

The premature loop termination check makes sense only in case of the
jump to read_again where the count may have been updated. But
read_again did not include the check.

Fixes: bba2556efad6 ("net: stmmac: Enable RX via AF_XDP zero-copy")

This commit was included in v5.13

quoted

Fixes: ec222003bd94 ("net: stmmac: Prepare to add Split Header support")

While this one was included in v5.4

It seems to me that each of the above commits correspond to one
of the two hunks below. I don't know if that means this
patch should be split in two to assist backporting.

I was thinking about this already but the change was so trivial that I
hesitated to split it into two commits. I wanted I will surely change
this.

The advantage of splitting is that it makes back porting easy. Both
parts are needed for 6.1 and 5.15. 5.10 only needs the fix for
ec222003bd94. It if does not easily apply to 5.10 it could get
dropped. By splitting it, the backporting probably happens fully
automated, no human involved.

	Andrew

Andrew Lunn [off-list ref] writes:

On Wed, Feb 22, 2023 at 04:49:55PM +0100, Henneberg - Systemdesign wrote:

quoted

Simon Horman [off-list ref] writes:

quoted

On Wed, Feb 22, 2023 at 08:38:28AM +0100, Jochen Henneberg wrote:

quoted

The premature loop termination check makes sense only in case of the
jump to read_again where the count may have been updated. But
read_again did not include the check.

Fixes: bba2556efad6 ("net: stmmac: Enable RX via AF_XDP zero-copy")

This commit was included in v5.13

quoted

Fixes: ec222003bd94 ("net: stmmac: Prepare to add Split Header support")

While this one was included in v5.4

It seems to me that each of the above commits correspond to one
of the two hunks below. I don't know if that means this
patch should be split in two to assist backporting.

I was thinking about this already but the change was so trivial that I
hesitated to split it into two commits. I wanted I will surely change
this.

The advantage of splitting is that it makes back porting easy. Both
parts are needed for 6.1 and 5.15. 5.10 only needs the fix for
ec222003bd94. It if does not easily apply to 5.10 it could get
dropped. By splitting it, the backporting probably happens fully
automated, no human involved.

Understood. Will do the split and send two new patches. I will not
continue with version upcounting and not send a patch series but two
completly independent patches.

Jochen

	Andrew

-- 
Henneberg - Systemdesign
Jochen Henneberg
Loehnfeld 26
21423 Winsen (Luhe)
--
Fon: +49 172 160 14 69
Url: https://www.henneberg-systemdesign.com

On Thu, Feb 23, 2023 at 12:34:18PM +0100, Jochen Henneberg wrote:

Andrew Lunn [off-list ref] writes:

quoted

On Wed, Feb 22, 2023 at 04:49:55PM +0100, Henneberg - Systemdesign wrote:

quoted

Simon Horman [off-list ref] writes:

quoted

On Wed, Feb 22, 2023 at 08:38:28AM +0100, Jochen Henneberg wrote:

quoted

The premature loop termination check makes sense only in case of the
jump to read_again where the count may have been updated. But
read_again did not include the check.

Fixes: bba2556efad6 ("net: stmmac: Enable RX via AF_XDP zero-copy")

This commit was included in v5.13

quoted

Fixes: ec222003bd94 ("net: stmmac: Prepare to add Split Header support")

While this one was included in v5.4

It seems to me that each of the above commits correspond to one
of the two hunks below. I don't know if that means this
patch should be split in two to assist backporting.

I was thinking about this already but the change was so trivial that I
hesitated to split it into two commits. I wanted I will surely change
this.

The advantage of splitting is that it makes back porting easy. Both
parts are needed for 6.1 and 5.15. 5.10 only needs the fix for
ec222003bd94. It if does not easily apply to 5.10 it could get
dropped. By splitting it, the backporting probably happens fully
automated, no human involved.

Understood. Will do the split and send two new patches. I will not
continue with version upcounting and not send a patch series but two
completly independent patches.

There may be fuzz if the patches are not applied in order.
I'd suggest making a series.