can bcm: fix tx_setup off-by-one errors
Subsystems (3)
Oliver Hartkopp
maintainerPATCH 1/1 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.
---
net/can/bcm.c +7 -6
@@ -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:
Quoted 9 lines
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 timetx_setupis invoked as an additional frame is sent due toTX_ANNONCE. Invoking a secondtx_setupon the same item led to a reduced (by 1) number of sent frames.Reported-by Andre Naujoks <[email protected]>Signed-off-by Oliver Hartkopp <[email protected]>
Tested by: Andre Naujoks <[email protected]>
Quoted 43 lines
---
net/can/bcm.c +7
-6@@ -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 ; }
From: Oliver Hartkopp <[email protected]>
Date: Fri, 23 Sep 2011 20:23:47 +0200
Quoted 9 lines
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 timetx_setupis invoked as an additional frame is sent due toTX_ANNONCE. Invoking a secondtx_setupon the same item led to a reduced (by 1) number of sent frames.Reported-by Andre Naujoks <[email protected]>Signed-off-by Oliver Hartkopp <[email protected]>
Applied, and queued up for -stable.
Oliver Hartkopp
maintainerQuoted 10 lines · David Miller
From: Oliver Hartkopp <[email protected]>
Date: Fri, 23 Sep 2011 20:23:47 +0200Quoted 7 lines
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 timetx_setupis invoked as an additional frame is sent due toTX_ANNONCE. Invoking a secondtx_setupon the same item led to a reduced (by 1) number of sent frames.
Quoted 4 lines
Quoted 2 lines
Reported-by Andre Naujoks <[email protected]>Signed-off-by Oliver Hartkopp <[email protected]>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
David Miller
maintainerFrom: Oliver Hartkopp <[email protected]>
Date: Thu, 29 Sep 2011 09:46:46 +0200
Quoted 4 lines
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.
Oliver Hartkopp
maintainerQuoted 6 lines · David Miller
From: Oliver Hartkopp <[email protected]>
Date: Thu, 29 Sep 2011 09:46:46 +0200Quoted 3 lines
when backporting the patch to an older kernel we discovered a problem this patch is introducing - which causes a new regression :-(
Quoted 8 lines
Quoted 1 line
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
David Miller
maintainerFrom: Oliver Hartkopp <[email protected]>
Date: Thu, 29 Sep 2011 10:04:40 +0200
Quoted 1 line
Sending a new fix that fixes the broken fix?
Yes, please do that.