* bnx2x_sriov.c: Missing switch/case breaks?
@ 2013-12-13 23:01 Joe Perches
2013-12-14 6:16 ` Yuval Mintz
0 siblings, 1 reply; 5+ messages in thread
From: Joe Perches @ 2013-12-13 23:01 UTC (permalink / raw)
To: Ariel Elior; +Cc: netdev, LKML
Hi Ariel.
I wrote a little checkpatch script to look for missing
switch/case breaks.
http://www.kernelhub.org/?msg=379933&p=2
There are _many_ instances of case blocks in sriov.c
that could be missing breaks as they use fall-throughs.
It would be good if these are actually intended to be
fall-throughs to add a /* fall-through */ comment between
each case block.
For instance:
static void bnx2x_vfop_qctor(struct bnx2x *bp, struct bnx2x_virtf *vf)
{
[...]
switch (state) {
case BNX2X_VFOP_QCTOR_INIT:
/* has this queue already been opened? */
if (bnx2x_get_q_logical_state(bp, q_params->q_obj) ==
BNX2X_Q_LOGICAL_STATE_ACTIVE) {
DP(BNX2X_MSG_IOV,
"Entered qctor but queue was already up. Aborting gracefully\n");
goto op_done;
}
/* next state */
vfop->state = BNX2X_VFOP_QCTOR_SETUP;
q_params->cmd = BNX2X_Q_CMD_INIT;
vfop->rc = bnx2x_queue_state_change(bp, q_params);
bnx2x_vfop_finalize(vf, vfop->rc, VFOP_CONT);
case BNX2X_VFOP_QCTOR_SETUP:
/* next state */
vfop->state = BNX2X_VFOP_QCTOR_INT_EN;
/* copy pre-prepared setup params to the queue-state params */
vfop->op_p->qctor.qstate.params.setup =
vfop->op_p->qctor.prep_qsetup;
q_params->cmd = BNX2X_Q_CMD_SETUP;
vfop->rc = bnx2x_queue_state_change(bp, q_params);
bnx2x_vfop_finalize(vf, vfop->rc, VFOP_CONT);
---
Here's the checkpatch output on that file
$ ./scripts/checkpatch.pl -f --types=missing_break drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
WARNING: Possible switch case/default not preceeded by break or fallthrough comment
#326: FILE: drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:326:
+ case BNX2X_VFOP_QCTOR_SETUP:
WARNING: Possible switch case/default not preceeded by break or fallthrough comment
#339: FILE: drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:339:
+ case BNX2X_VFOP_QCTOR_INT_EN:
WARNING: Possible switch case/default not preceeded by break or fallthrough comment
#416: FILE: drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:416:
+ case BNX2X_VFOP_QDTOR_TERMINATE:
WARNING: Possible switch case/default not preceeded by break or fallthrough comment
#425: FILE: drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:425:
+ case BNX2X_VFOP_QDTOR_CFCDEL:
WARNING: Possible switch case/default not preceeded by break or fallthrough comment
#437: FILE: drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:437:
+ case BNX2X_VFOP_QDTOR_DONE:
WARNING: Possible switch case/default not preceeded by break or fallthrough comment
#622: FILE: drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:622:
+ case BNX2X_VFOP_VLAN_MAC_CONFIG_SINGLE:
WARNING: Possible switch case/default not preceeded by break or fallthrough comment
#633: FILE: drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:633:
+ case BNX2X_VFOP_VLAN_MAC_CHK_DONE:
WARNING: Possible switch case/default not preceeded by break or fallthrough comment
#637: FILE: drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:637:
+ case BNX2X_VFOP_MAC_CONFIG_LIST:
WARNING: Possible switch case/default not preceeded by break or fallthrough comment
#650: FILE: drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:650:
+ case BNX2X_VFOP_VLAN_CONFIG_LIST:
WARNING: Possible switch case/default not preceeded by break or fallthrough comment
#662: FILE: drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:662:
+ default:
WARNING: Possible switch case/default not preceeded by break or fallthrough comment
#971: FILE: drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:971:
+ case BNX2X_VFOP_QSETUP_DONE:
WARNING: Possible switch case/default not preceeded by break or fallthrough comment
#1068: FILE: drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:1068:
+ case BNX2X_VFOP_QFLR_DONE:
WARNING: Possible switch case/default not preceeded by break or fallthrough comment
#1119: FILE: drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:1119:
+ case BNX2X_VFOP_MCAST_ADD:
WARNING: Possible switch case/default not preceeded by break or fallthrough comment
#1136: FILE: drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:1136:
+ case BNX2X_VFOP_MCAST_CHK_DONE:
WARNING: Possible switch case/default not preceeded by break or fallthrough comment
#1139: FILE: drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:1139:
+ default:
WARNING: Possible switch case/default not preceeded by break or fallthrough comment
#1217: FILE: drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:1217:
+ case BNX2X_VFOP_RXMODE_DONE:
WARNING: Possible switch case/default not preceeded by break or fallthrough comment
#1326: FILE: drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:1326:
+ case BNX2X_VFOP_QTEARDOWN_DONE:
WARNING: Possible switch case/default not preceeded by break or fallthrough comment
#2985: FILE: drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:2985:
+ case BNX2X_VFOP_RSS_DONE:
total: 0 errors, 18 warnings, 3683 lines checked
NOTE: Used message types: MISSING_BREAK
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c has style problems, please review.
If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
total: 0 errors, 0 warnings, 2006 lines checked
NOTE: Used message types: MISSING_BREAK
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: bnx2x_sriov.c: Missing switch/case breaks?
2013-12-13 23:01 bnx2x_sriov.c: Missing switch/case breaks? Joe Perches
@ 2013-12-14 6:16 ` Yuval Mintz
2013-12-14 6:57 ` Joe Perches
0 siblings, 1 reply; 5+ messages in thread
From: Yuval Mintz @ 2013-12-14 6:16 UTC (permalink / raw)
To: Joe Perches, Ariel Elior; +Cc: netdev@vger.kernel.org, LKML
> Hi Ariel.
>
> I wrote a little checkpatch script to look for missing
> switch/case breaks.
>
> http://www.kernelhub.org/?msg=379933&p=2
>
> There are _many_ instances of case blocks in sriov.c
> that could be missing breaks as they use fall-throughs.
>
> It would be good if these are actually intended to be
> fall-throughs to add a /* fall-through */ comment between
> each case block.
>
> For instance:
>
> static void bnx2x_vfop_qctor(struct bnx2x *bp, struct bnx2x_virtf *vf)
> {
> [...]
> switch (state) {
> case BNX2X_VFOP_QCTOR_INIT:
>
> /* has this queue already been opened? */
> if (bnx2x_get_q_logical_state(bp, q_params->q_obj) ==
> BNX2X_Q_LOGICAL_STATE_ACTIVE) {
> DP(BNX2X_MSG_IOV,
> "Entered qctor but queue was already up. Aborting
> gracefully\n");
> goto op_done;
> }
>
> /* next state */
> vfop->state = BNX2X_VFOP_QCTOR_SETUP;
>
> q_params->cmd = BNX2X_Q_CMD_INIT;
> vfop->rc = bnx2x_queue_state_change(bp, q_params);
>
> bnx2x_vfop_finalize(vf, vfop->rc, VFOP_CONT);
Hi Joe,
The `vfop' part of the code contains a lot of usage of the `bnx2x_vfop_finalize()',
which either goto or return at the end of almost every case.
"Normal" analysis tools/scripts fail to recognize them as valid case breaks.
Adding `fallthrough' comments would make little sense, as this is not the real
behavior; Perhaps we need some alternative comment? (something in the line
of `macro case break')
Cheers,
Yuval
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: bnx2x_sriov.c: Missing switch/case breaks?
2013-12-14 6:16 ` Yuval Mintz
@ 2013-12-14 6:57 ` Joe Perches
2013-12-14 13:26 ` Yuval Mintz
0 siblings, 1 reply; 5+ messages in thread
From: Joe Perches @ 2013-12-14 6:57 UTC (permalink / raw)
To: Yuval Mintz; +Cc: Ariel Elior, netdev@vger.kernel.org, LKML
On Sat, 2013-12-14 at 06:16 +0000, Yuval Mintz wrote:
> > Hi Ariel.
> >
> > I wrote a little checkpatch script to look for missing
> > switch/case breaks.
> >
> > http://www.kernelhub.org/?msg=379933&p=2
> >
> > There are _many_ instances of case blocks in sriov.c
> > that could be missing breaks as they use fall-throughs.
> >
> > It would be good if these are actually intended to be
> > fall-throughs to add a /* fall-through */ comment between
> > each case block.
> >
> > For instance:
> >
> > static void bnx2x_vfop_qctor(struct bnx2x *bp, struct bnx2x_virtf *vf)
> > {
> > [...]
> > switch (state) {
> > case BNX2X_VFOP_QCTOR_INIT:
> >
> > /* has this queue already been opened? */
> > if (bnx2x_get_q_logical_state(bp, q_params->q_obj) ==
> > BNX2X_Q_LOGICAL_STATE_ACTIVE) {
> > DP(BNX2X_MSG_IOV,
> > "Entered qctor but queue was already up. Aborting
> > gracefully\n");
> > goto op_done;
> > }
> >
> > /* next state */
> > vfop->state = BNX2X_VFOP_QCTOR_SETUP;
> >
> > q_params->cmd = BNX2X_Q_CMD_INIT;
> > vfop->rc = bnx2x_queue_state_change(bp, q_params);
> >
> > bnx2x_vfop_finalize(vf, vfop->rc, VFOP_CONT);
>
> Hi Joe,
Hi Yuval.
> The `vfop' part of the code contains a lot of usage of the `bnx2x_vfop_finalize()',
> which either goto or return at the end of almost every case.
> "Normal" analysis tools/scripts fail to recognize them as valid case breaks.
>
> Adding `fallthrough' comments would make little sense, as this is not the real
> behavior; Perhaps we need some alternative comment? (something in the line
> of `macro case break')
No idea. It's certainly an ugly macro.
This does have a fallthrough path though when
(rc == 0 && next == VFOP_VERIFY_PEND) so
maybe there should be a break after most all
uses of this macro anyway. When next is
VFOP_VERIFY_PEND, then a "fall-through" comment
would be appropriate.
cheers, Joe
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h:#define bnx2x_vfop_finalize(vf, rc, next) do { \
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h- if ((rc) < 0) \
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h- goto op_err; \
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h- else if ((rc) > 0) \
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h- goto op_pending; \
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h- else if ((next) == VFOP_DONE) \
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h- goto op_done; \
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h- else if ((next) == VFOP_VERIFY_PEND) \
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h- BNX2X_ERR("expected pending\n"); \
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h- else { \
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h- DP(BNX2X_MSG_IOV, "no ramrod. Scheduling\n"); \
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h- atomic_set(&vf->op_in_progress, 1); \
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h- queue_delayed_work(bnx2x_wq, &bp->sp_task, 0); \
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h- return; \
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h- } \
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h- } while (0)
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h-
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: bnx2x_sriov.c: Missing switch/case breaks?
2013-12-14 6:57 ` Joe Perches
@ 2013-12-14 13:26 ` Yuval Mintz
2013-12-14 17:49 ` Joe Perches
0 siblings, 1 reply; 5+ messages in thread
From: Yuval Mintz @ 2013-12-14 13:26 UTC (permalink / raw)
To: Joe Perches; +Cc: Ariel Elior, netdev@vger.kernel.org, LKML
> > > Hi Ariel.
> > >
> > > I wrote a little checkpatch script to look for missing
> > > switch/case breaks.
> > >
> > > http://www.kernelhub.org/?msg=379933&p=2
> > >
> > > There are _many_ instances of case blocks in sriov.c
> > > that could be missing breaks as they use fall-throughs.
> > >
> > > It would be good if these are actually intended to be
> > > fall-throughs to add a /* fall-through */ comment between
> > > each case block.
> > >
> > Hi Joe,
>
> Hi Yuval.
>
> > The `vfop' part of the code contains a lot of usage of the
> `bnx2x_vfop_finalize()',
> > which either goto or return at the end of almost every case.
> > "Normal" analysis tools/scripts fail to recognize them as valid case
> breaks.
> >
> > Adding `fallthrough' comments would make little sense, as this is not the
> real
> > behavior; Perhaps we need some alternative comment? (something in the
> line
> > of `macro case break')
>
> No idea. It's certainly an ugly macro.
>
True.
> This does have a fallthrough path though when
> (rc == 0 && next == VFOP_VERIFY_PEND) so
This is a very rare path - there's exactly one place in the bnx2x code
Where `next == VFOP_VERIFY_PEND' (also notice this path prints an
error, so this is obviously not the expected behaviour).
> maybe there should be a break after most all
> uses of this macro anyway. When next is
Won't some static code analysis tools regard such `break' calls as
unreachable code?
> VFOP_VERIFY_PEND, then a "fall-through" comment
> would be appropriate.
>
> cheers, Joe
Thanks,
Yuval
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: bnx2x_sriov.c: Missing switch/case breaks?
2013-12-14 13:26 ` Yuval Mintz
@ 2013-12-14 17:49 ` Joe Perches
0 siblings, 0 replies; 5+ messages in thread
From: Joe Perches @ 2013-12-14 17:49 UTC (permalink / raw)
To: Yuval Mintz; +Cc: Ariel Elior, netdev@vger.kernel.org, LKML
On Sat, 2013-12-14 at 13:26 +0000, Yuval Mintz wrote:
> > > The `vfop' part of the code contains a lot of usage of the
> > `bnx2x_vfop_finalize()',
> > > which either goto or return at the end of almost every case.
> > > "Normal" analysis tools/scripts fail to recognize them as valid case
> > breaks.
> > >
> > > Adding `fallthrough' comments would make little sense, as this is not the
> > real
> > > behavior; Perhaps we need some alternative comment? (something in the
> > line
> > > of `macro case break')
> >
> > No idea. It's certainly an ugly macro.
> >
>
> True.
[]
> > maybe there should be a break after most all
> > uses of this macro anyway. When next is
>
> Won't some static code analysis tools regard such `break' calls as
> unreachable code?
I suppose that maybe true,
but this could also work...
bnx2x_vfop_finalize(vf, vfop->rc, VFOP_CONT);
/* Ugly goto|return macro, not fall-through */
;)
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-12-14 17:49 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-13 23:01 bnx2x_sriov.c: Missing switch/case breaks? Joe Perches
2013-12-14 6:16 ` Yuval Mintz
2013-12-14 6:57 ` Joe Perches
2013-12-14 13:26 ` Yuval Mintz
2013-12-14 17:49 ` Joe Perches
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).