Skip to contentSkip to conversation

net: more timeouts that reach -1

PATCH Applied Roel Kluin 3 participants 8 messages Feb 25, 2009 – Mar 4, 2009

Subsystems (2)
lore
Share & tools
lore

Roel Kluin

author
#0 lore raw

PATCH 1/1 net: more timeouts that reach -1

These were not previously reported by me. ------------------------------>8-------------8<--------------------------------- with while (timeout-- > 0); timeout reaches -1 after the loop, so the tests below are off by one.

---
 drivers/net/arm/ks8695net.c |    2 +-
 drivers/net/jme.c           |    3 ++-
 drivers/net/ucc_geth_mii.c  |    2 +-
 3 files changed, 4 insertions(+), 3 deletions(-)
drivers/net/arm/ks8695net.c +1 -1
index 1cf2f94..f3a1274 100644
@@ -560,7 +560,7 @@ ks8695_reset(struct ks8695_priv *ksp)
 		msleep(1);
 	}
 
-	if (reset_timeout == 0) {
+	if (reset_timeout < 0) {
 		dev_crit(ksp->dev,
 			 "Timeout waiting for DMA engines to reset\n");
 		/* And blithely carry on */
drivers/net/jme.c +2 -1
index 08b3405..0173ed0 100644
@@ -957,7 +957,8 @@ jme_process_receive(struct jme_adapter *jme, int limit)
 		goto out_inc;
 
 	i = atomic_read(&rxring->next_to_clean);
-	while (limit-- > 0) {
+	while (limit > 0) {
+		limit--;
 		rxdesc = rxring->desc;
 		rxdesc += i;
 
drivers/net/ucc_geth_mii.c +1 -1
index 5463591..7b1b46c 100644
@@ -123,7 +123,7 @@ static int uec_mdio_reset(struct mii_bus *bus)
 
 	mutex_unlock(&bus->mdio_lock);
 
-	if (timeout <= 0) {
+	if (timeout < 0) {
 		printk(KERN_ERR "%s: The MII Bus is stuck!\n", bus->name);
 		return -EBUSY;
 	}
#1 lore raw

On Wed, 25 Feb 2009 12:15:57 +0100, Roel Kluin wrote

Quoted 30 lines

These were not previously reported by me. ------------------------------>8-------------8<--------------------------------- with while (timeout-- > 0); timeout reaches -1 after the loop, so the tests below are off by one.

---
 drivers/net/arm/ks8695net.c |    2 +-
 drivers/net/jme.c           |    3 ++-
 drivers/net/ucc_geth_mii.c  |    2 +-
 3 files changed, 4 insertions(+), 3 deletions(-)
drivers/net/arm/ks8695net.c +1 -1
index 1cf2f94..f3a1274 100644
@@ -560,7 +560,7 @@ ks8695_reset(struct ks8695_priv *ksp)
 		msleep(1);
 	}
 
-	if (reset_timeout == 0) {
+	if (reset_timeout < 0) {
 		dev_crit(ksp->dev,
 			 "Timeout waiting for DMA engines to reset\n");
 		/* And blithely carry on */
drivers/net/jme.c +0 -0
index 08b3405..0173ed0 100644

drivers/net/jme.c jme_process_receive(struct jme_adapter *jme, int limit) · line 964

Quoted 9 lines
drivers/net/jme.c +2 -1
@@ -957,7 +957,8 @@ jme_process_receive(struct jme_adapter *jme, int limit)
 		goto out_inc;
 
 	i = atomic_read(&rxring->next_to_clean);
-	while (limit-- > 0) {
+	while (limit > 0) {
+		limit--;
 		rxdesc = rxring->desc;
 		rxdesc += i;
 

There should be no difference after this modification. The return value of this function is: "limit > 0 ? limit : 0;"

Quoted 14 lines
drivers/net/ucc_geth_mii.c +1 -2
index 5463591..7b1b46c 100644
@@ -123,7 +123,7 @@ static int uec_mdio_reset(struct mii_bus *bus)
 
 	mutex_unlock(&bus->mdio_lock);
 
-	if (timeout <= 0) {
+	if (timeout < 0) {
 		printk(KERN_ERR "%s: The MII Bus is stuck!\n", bus->name);
 		return -EBUSY;
 	}
--
Quoted 3 lines

To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Guo-Fu Tseng

author
#2 lore raw
Quoted 16 lines · Guo-Fu Tseng

On Wed, 25 Feb 2009 12:15:57 +0100, Roel Kluin wrote

Quoted 15 lines

These were not previously reported by me. ------------------------------>8-------------8<--------------------------------- with while (timeout-- > 0); timeout reaches -1 after the loop, so the tests below are off by one.

---

drivers/net/jme.c +0 -0
index 08b3405..0173ed0 100644
@@ -957,7 +957,8 @@ jme_process_receive(struct jme_adapter *jme, int limit)
               goto out_inc;
 
Quoted 9 lines

drivers/net/jme.c jme_process_receive(struct jme_adapter *jme, int limit) · line 964

Quoted 7 lines
drivers/net/jme.c +2 -1
       i = atomic_read(&rxring->next_to_clean);
-     while (limit-- > 0) {
+     while (limit > 0) {
+             limit--;
               rxdesc = rxring->desc;
               rxdesc += i;
 

There should be no difference after this modification. The return value of this function is: "limit > 0 ? limit : 0;"

There is:
In the last iteration limit is 1 during the test before it is decremented to 0.

rxdesc = rxring->desc;
rxdesc += i;

If then we break out of the loop by the 'goto out;', we continue with:

out:

        atomic_set(&rxring->next_to_clean, i);

out_inc:

        atomic_inc(&jme->rx_cleaning);

but since limit is already decremented, 0 is returned.

Quoted 3 lines

Guo-Fu Tseng

Roel

#3 lore raw

On Fri, 27 Feb 2009 16:37:30 +0100, roel kluin wrote

Quoted 18 lines · Guo-Fu Tseng
Quoted 2 lines

There should be no difference after this modification. The return value of this function is: "limit > 0 ? limit : 0;"

There is:
In the last iteration limit is 1 during the test before it is decremented to 0.

rxdesc = rxring->desc;
rxdesc += i;

If then we break out of the loop by the 'goto out;', we continue with:

out:

        atomic_set(&rxring->next_to_clean, i);

out_inc:

        atomic_inc(&jme->rx_cleaning);
Quoted 7 lines

but since limit is already decremented, 0 is returned.

Quoted 3 lines

Guo-Fu Tseng

Roel

I see.
But the correct patch should be following one, right?

===================================================================

jme.c +2 -1
@@ -958,13 +958,14 @@
 		goto out_inc;
 
 	i = atomic_read(&rxring->next_to_clean);
-	while (limit-- > 0) {
+	while (limit > 0) {
 		rxdesc = rxring->desc;
 		rxdesc += i;
 
 		if ((rxdesc->descwb.flags & RXWBFLAG_OWN) ||
 		!(rxdesc->descwb.desccnt & RXWBDCNT_WBCPL))
 			goto out;
+		--limit;
 
 		desccnt = rxdesc->descwb.desccnt & RXWBDCNT_DCNT;
 

Guo-Fu Tseng

author
#4 lore raw

PATCH v3 1/1 net: more timeouts that reach -1

Quoted 48 lines · Guo-Fu Tseng

On Fri, 27 Feb 2009 16:37:30 +0100, roel kluin wrote

Quoted 14 lines · Guo-Fu Tseng
Quoted 2 lines

There should be no difference after this modification. The return value of this function is: "limit > 0 ? limit : 0;"

There is:
In the last iteration limit is 1 during the test before it is decremented to 0.

rxdesc = rxring->desc;
rxdesc += i;

If then we break out of the loop by the 'goto out;', we continue with:

out:

        atomic_set(&rxring->next_to_clean, i);
Quoted 8 lines

out_inc:

        atomic_inc(&jme->rx_cleaning);

but since limit is already decremented, 0 is returned.

Quoted 2 lines

Guo-Fu Tseng

Roel

I see.
But the correct patch should be following one, right?

===================================================================

jme.c +2 -1
@@ -958,13 +958,14 @@
 		goto out_inc;
 
 	i = atomic_read(&rxring->next_to_clean);
-	while (limit-- > 0) {
+	while (limit > 0) {
 		rxdesc = rxring->desc;
 		rxdesc += i;
 
 		if ((rxdesc->descwb.flags & RXWBFLAG_OWN) ||
 		!(rxdesc->descwb.desccnt & RXWBDCNT_WBCPL))
 			goto out;
+		--limit;
 
 		desccnt = rxdesc->descwb.desccnt & RXWBDCNT_DCNT;
 
Quoted 1 line

Guo-Fu Tseng

Correct, thanks.
Here are all three patches again with another issue I spotted in drivers/net/ucc_geth_mii.c:

After my patch it still wouldn't err, because timeout was unsigned. ------------------------------>8-------------8<--------------------------------- with while (timeout-- > 0); timeout reaches -1 after the loop, so the tests below are off by one. also don't do an '< 0' test on an unsigned.

---

drivers/net/arm/ks8695net.c +1 -1
index 1cf2f94..f3a1274 100644
@@ -560,7 +560,7 @@ ks8695_reset(struct ks8695_priv *ksp)
 		msleep(1);
 	}
 
-	if (reset_timeout == 0) {
+	if (reset_timeout < 0) {
 		dev_crit(ksp->dev,
 			 "Timeout waiting for DMA engines to reset\n");
 		/* And blithely carry on */
drivers/net/jme.c +2 -1
index 08b3405..a6e1a35 100644
@@ -957,13 +957,14 @@ jme_process_receive(struct jme_adapter *jme, int limit)
 		goto out_inc;
 
 	i = atomic_read(&rxring->next_to_clean);
-	while (limit-- > 0) {
+	while (limit > 0) {
 		rxdesc = rxring->desc;
 		rxdesc += i;
 
 		if ((rxdesc->descwb.flags & cpu_to_le16(RXWBFLAG_OWN)) ||
 		!(rxdesc->descwb.desccnt & RXWBDCNT_WBCPL))
 			goto out;
+		--limit;
 
 		desccnt = rxdesc->descwb.desccnt & RXWBDCNT_DCNT;
 
drivers/net/ucc_geth_mii.c +2 -2
index 5463591..0ada4ed 100644
@@ -107,7 +107,7 @@ int uec_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
 static int uec_mdio_reset(struct mii_bus *bus)
 {
 	struct ucc_mii_mng __iomem *regs = (void __iomem *)bus->priv;
-	unsigned int timeout = PHY_INIT_TIMEOUT;
+	int timeout = PHY_INIT_TIMEOUT;
 
 	mutex_lock(&bus->mdio_lock);
 
@@ -123,7 +123,7 @@ static int uec_mdio_reset(struct mii_bus *bus)
 
 	mutex_unlock(&bus->mdio_lock);
 
-	if (timeout <= 0) {
+	if (timeout < 0) {
 		printk(KERN_ERR "%s: The MII Bus is stuck!\n", bus->name);
 		return -EBUSY;
 	}
maintainer
#5 lore raw

From: Roel Kluin <[email protected]>
Date: Fri, 27 Feb 2009 17:43:06 +0100

Quoted 4 lines

Here are all three patches again with another issue I spotted in drivers/net/ucc_geth_mii.c:

After my patch it still wouldn't err, because timeout was unsigned.

I'll make sure to integrate this version of your patch instead of the original which I just said I applied :-)

author
#6 lore raw

PATCH v2 1/1 net: more timeouts that reach -1

In reply to Roel Kluin
Quoted 4 lines · Roel Kluin

These were not previously reported by me. ------------------------------>8-------------8<--------------------------------- with while (timeout-- > 0); timeout reaches -1 after the loop, so the tests below are off by one.

I just noticed that in drivers/net/ucc_geth_mii.c after my patch this still won't give an err, because timeout is unsigned ------------------------------>8-------------8<--------------------------------- with while (timeout-- > 0); timeout reaches -1 after the loop, so the tests below are off by one. also don't do an '< 0' test on an unsigned.

---

drivers/net/arm/ks8695net.c +1 -1
index 1cf2f94..f3a1274 100644
@@ -560,7 +560,7 @@ ks8695_reset(struct ks8695_priv *ksp)
 		msleep(1);
 	}
 
-	if (reset_timeout == 0) {
+	if (reset_timeout < 0) {
 		dev_crit(ksp->dev,
 			 "Timeout waiting for DMA engines to reset\n");
 		/* And blithely carry on */
drivers/net/jme.c +2 -1
index 08b3405..0173ed0 100644
@@ -957,7 +957,8 @@ jme_process_receive(struct jme_adapter *jme, int limit)
 		goto out_inc;
 
 	i = atomic_read(&rxring->next_to_clean);
-	while (limit-- > 0) {
+	while (limit > 0) {
+		limit--;
 		rxdesc = rxring->desc;
 		rxdesc += i;
 
drivers/net/ucc_geth_mii.c +2 -2
index 5463591..0ada4ed 100644
@@ -107,7 +107,7 @@ int uec_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
 static int uec_mdio_reset(struct mii_bus *bus)
 {
 	struct ucc_mii_mng __iomem *regs = (void __iomem *)bus->priv;
-	unsigned int timeout = PHY_INIT_TIMEOUT;
+	int timeout = PHY_INIT_TIMEOUT;
 
 	mutex_lock(&bus->mdio_lock);
 
@@ -123,7 +123,7 @@ static int uec_mdio_reset(struct mii_bus *bus)
 
 	mutex_unlock(&bus->mdio_lock);
 
-	if (timeout <= 0) {
+	if (timeout < 0) {
 		printk(KERN_ERR "%s: The MII Bus is stuck!\n", bus->name);
 		return -EBUSY;
 	}
maintainer Applied
#7 lore raw
In reply to Roel Kluin

From: Roel Kluin <[email protected]>
Date: Wed, 25 Feb 2009 12:15:57 +0100

Quoted 6 lines

These were not previously reported by me. ------------------------------>8-------------8<--------------------------------- with while (timeout-- > 0); timeout reaches -1 after the loop, so the tests below are off by one.

Applied, thanks.