Re: [patch] mm, mempolicy: make mpol_to_str robust and always succeed

[Dave Jones]

On Tue, Sep 24, 2013 at 08:18:16PM -0700, David Rientjes wrote:
 > On Tue, 24 Sep 2013, Dave Jones wrote:
 > 
 > >  >  	case MPOL_BIND:
 > >  > -		/* Fall through */
 > >  >  	case MPOL_INTERLEAVE:
 > >  >  		nodes = pol->v.nodes;
 > >  >  		break;
 > > 
 > > Any reason not to leave this ?
 > > 
 > > "missing break" is the 2nd most common thing that coverity picks up.
 > > Most of them are false positives like the above, but the lack of annotations
 > > in our source makes it time-consuming to pick through them all to find the
 > > real bugs.
 > > 
 > 
 > Check out things like drivers/mfd/wm5110-tables.c that do things like
 > 
 > 	switch (reg) {
 > 	case ARIZONA_SOFTWARE_RESET:
 > 	case ARIZONA_DEVICE_REVISION:
 > 	case ARIZONA_CTRL_IF_SPI_CFG_1:
 > 	case ARIZONA_CTRL_IF_I2C1_CFG_1:
 > 	case ARIZONA_CTRL_IF_I2C2_CFG_1:
 > 	case ARIZONA_CTRL_IF_I2C1_CFG_2:
 > 	case ARIZONA_CTRL_IF_I2C2_CFG_2:
 > 	...
 > 
 > and that file has over 1,000 case statements.  Having a

yikes, at first I thought that was output from a code generator.
 
 > 	/* fall through */
 > 
 > for all of them would be pretty annoying.
 
agreed, but with that example, it seems pretty obvious (to me at least)
that the lack of break's is intentional.  Where it gets trickier to
make quick judgment calls is cases like the one I mentioned above,
where there are only a few cases, and there's real code involved in
some but not all cases.

 > I don't remember any coding style rule about this (in fact 
 > Documentation/CodingStyle has examples of case statements without such a 
 > comment), I think it's just personal preference so I'll leave it to Andrew 
 > and what he prefers.
 > 
 > (And if he prefers the /* fall through */ then we should ask that it be 
 > added to checkpatch.pl since it warns about a million other things and not 
 > this.)

The question of course is how much gain there is in doing anything at all here.
So far, I've only seen false positives from that checker, but there are hundreds
of them to pick through, so who knows what's further down the pile.

	Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/