| Message ID | 4E7CCEB3.4050408@hartkopp.net |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
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 <nautsch@gmail.com> > Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Tested by: Andre Naujoks <nautsch@gmail.com> > > --- > > 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; > } > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <nautsch@gmail.com> > Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Applied, and queued up for -stable. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/29/11 06:33, David Miller wrote: > 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 <nautsch@gmail.com> >> 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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/29/11 09:58, David Miller wrote: > 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. 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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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; }
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 <nautsch@gmail.com> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> --- -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html