[PATCH net/stable] can bcm: fix tx_setup off-by-one errors

This patch fixes two off-by-one errors that canceled each other out.
Checking for the same condition two times in bcm_tx_timeout_tsklet() reduced
the count of frames to be sent by one. This did not show up the first time
tx_setup is invoked as an additional frame is sent due to TX_ANNONCE.
Invoking a second tx_setup on the same item led to a reduced (by 1) number of
sent frames.

Reported-by: Andre Naujoks <redacted>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>

---

diff --git a/net/can/bcm.c b/net/can/bcm.c
index d6c8ae5..c9cdb8d 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c

@@ -365,9 +365,6 @@ static void bcm_tx_timeout_tsklet(unsigned long data)
 
 			bcm_send_to_user(op, &msg_head, NULL, 0);
 		}
-	}
-
-	if (op->kt_ival1.tv64 && (op->count > 0)) {
 
 		/* send (next) frame */
 		bcm_can_tx(op);

@@ -970,8 +967,9 @@ static int bcm_tx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,
 		/* spec: send can_frame when starting timer */
 		op->flags |= TX_ANNOUNCE;
 
-		if (op->kt_ival1.tv64 && (op->count > 0)) {
-			/* op->count-- is done in bcm_tx_timeout_handler */
+		/* only start timer when having more frames than sent below */
+		if (op->kt_ival1.tv64 && (op->count > 1)) {
+			/* op->count-- is done in bcm_tx_timeout_tsklet */
 			hrtimer_start(&op->timer, op->kt_ival1,
 				      HRTIMER_MODE_REL);
 		} else

@@ -979,8 +977,11 @@ static int bcm_tx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,
 				      HRTIMER_MODE_REL);
 	}
 
-	if (op->flags & TX_ANNOUNCE)
+	if (op->flags & TX_ANNOUNCE) {
 		bcm_can_tx(op);
+		if (op->kt_ival1.tv64 && (op->count > 0))
+			op->count--;
+	}
 
 	return msg_head->nframes * CFSIZ + MHSIZ;
 }

Am 23.09.2011 20:23, schrieb Oliver Hartkopp:

This patch fixes two off-by-one errors that canceled each other out.
Checking for the same condition two times in bcm_tx_timeout_tsklet() reduced
the count of frames to be sent by one. This did not show up the first time
tx_setup is invoked as an additional frame is sent due to TX_ANNONCE.
Invoking a second tx_setup on the same item led to a reduced (by 1) number of
sent frames.

Reported-by: Andre Naujoks <redacted>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>

Tested by: Andre Naujoks [off-list ref]

From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Fri, 23 Sep 2011 20:23:47 +0200

This patch fixes two off-by-one errors that canceled each other out.
Checking for the same condition two times in bcm_tx_timeout_tsklet() reduced
the count of frames to be sent by one. This did not show up the first time
tx_setup is invoked as an additional frame is sent due to TX_ANNONCE.
Invoking a second tx_setup on the same item led to a reduced (by 1) number of
sent frames.

Reported-by: Andre Naujoks <redacted>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>

Applied, and queued up for -stable.

On 09/29/11 06:33, David Miller wrote:

From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Fri, 23 Sep 2011 20:23:47 +0200

quoted

This patch fixes two off-by-one errors that canceled each other out.
Checking for the same condition two times in bcm_tx_timeout_tsklet() reduced
the count of frames to be sent by one. This did not show up the first time
tx_setup is invoked as an additional frame is sent due to TX_ANNONCE.
Invoking a second tx_setup on the same item led to a reduced (by 1) number of
sent frames.

Reported-by: Andre Naujoks <redacted>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>

Applied, and queued up for -stable.

Hello Dave,

when backporting the patch to an older kernel we discovered a problem this
patch is introducing - which causes a new regression :-(

Could you please revert this patch and dequeue it from stable?

We'll send a new patch for net-next as this fix changes/repairs the behaviour
of the count variable. Therefore it's probably better to have a fixed Kernel
version where the fix emerges. Or should we better not fix it at all and
document it in 'know bugs' ?

Sorry for that noise ...

Thanks,
Oliver

From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Thu, 29 Sep 2011 09:46:46 +0200

when backporting the patch to an older kernel we discovered a problem this
patch is introducing - which causes a new regression :-(

Could you please revert this patch and dequeue it from stable?

It's already pushed out to the net GIT tree, I can't delete history so
now the only thing I can do is add a butt-ugly revert commit this late
in the -rcX which is terrible.

This patch was sitting out there for review for 6 days, which should
have been more than enough time to audit it for problems.

On 09/29/11 09:58, David Miller wrote:

From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Thu, 29 Sep 2011 09:46:46 +0200

quoted

when backporting the patch to an older kernel we discovered a problem this
patch is introducing - which causes a new regression :-(

Could you please revert this patch and dequeue it from stable?

It's already pushed out to the net GIT tree, I can't delete history so
now the only thing I can do is add a butt-ugly revert commit this late
in the -rcX which is terrible.

This patch was sitting out there for review for 6 days, which should
have been more than enough time to audit it for problems.

Yeah, i'm really sorry about that.

As Linus didn't pull the latest changes, what would be your favorite then to
not revert the patch?

Sending a new fix that fixes the broken fix?

Regards,
Oliver

From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Thu, 29 Sep 2011 10:04:40 +0200

Sending a new fix that fixes the broken fix?

Yes, please do that.