| Message ID | cover.1605896059.git.gustavoars@kernel.org |
|---|---|
| Headers | show |
| Series | Fix fall-through warnings for Clang | expand |
On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote: > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote: > > This series aims to fix almost all remaining fall-through warnings in > > order to enable -Wimplicit-fallthrough for Clang. > > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly > > add multiple break/goto/return/fallthrough statements instead of just > > letting the code fall through to the next case. > > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this > > change[1] is meant to be reverted at some point. So, this patch helps > > to move in that direction. > > > > Something important to mention is that there is currently a discrepancy > > between GCC and Clang when dealing with switch fall-through to empty case > > statements or to cases that only contain a break/continue/return > > statement[2][3][4]. > > Are we sure we want to make this change? Was it discussed before? > > Are there any bugs Clangs puritanical definition of fallthrough helped > find? > > IMVHO compiler warnings are supposed to warn about issues that could > be bugs. Falling through to default: break; can hardly be a bug?! It's certainly a place where the intent is not always clear. I think this makes all the cases unambiguous, and doesn't impact the machine code, since the compiler will happily optimize away any behavioral redundancy.
On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote: > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote: > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote: > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote: > > > > This series aims to fix almost all remaining fall-through warnings in > > > > order to enable -Wimplicit-fallthrough for Clang. > > > > > > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly > > > > add multiple break/goto/return/fallthrough statements instead of just > > > > letting the code fall through to the next case. > > > > > > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this > > > > change[1] is meant to be reverted at some point. So, this patch helps > > > > to move in that direction. > > > > > > > > Something important to mention is that there is currently a discrepancy > > > > between GCC and Clang when dealing with switch fall-through to empty case > > > > statements or to cases that only contain a break/continue/return > > > > statement[2][3][4]. > > > > > > Are we sure we want to make this change? Was it discussed before? > > > > > > Are there any bugs Clangs puritanical definition of fallthrough helped > > > find? > > > > > > IMVHO compiler warnings are supposed to warn about issues that could > > > be bugs. Falling through to default: break; can hardly be a bug?! > > > > It's certainly a place where the intent is not always clear. I think > > this makes all the cases unambiguous, and doesn't impact the machine > > code, since the compiler will happily optimize away any behavioral > > redundancy. > > If none of the 140 patches here fix a real bug, and there is no change > to machine code then it sounds to me like a W=2 kind of a warning. I'd like to avoid splitting common -W options between default and W=2 just based on the compiler. Getting -Wimplicit-fallthrough enabled found plenty of bugs, so making sure it works correctly for both compilers feels justified to me. (This is just a subset of the same C language short-coming.) > I think clang is just being annoying here, but if I'm the only one who > feels this way chances are I'm wrong :) It's being pretty pedantic, but I don't think it's unreasonable to explicitly state how every case ends. GCC's silence for the case of "fall through to a break" doesn't really seem justified.
Gustavo A. R. Silva <gustavoars@kernel.org> wrote: > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning > by explicitly adding a break statement instead of letting the code fall > through to the next case. Acked-by: Florian Westphal <fw@strlen.de>
On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote: > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote: > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote: > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote: > > > > This series aims to fix almost all remaining fall-through warnings in > > > > order to enable -Wimplicit-fallthrough for Clang. > > > > > > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly > > > > add multiple break/goto/return/fallthrough statements instead of just > > > > letting the code fall through to the next case. > > > > > > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this > > > > change[1] is meant to be reverted at some point. So, this patch helps > > > > to move in that direction. > > > > > > > > Something important to mention is that there is currently a discrepancy > > > > between GCC and Clang when dealing with switch fall-through to empty case > > > > statements or to cases that only contain a break/continue/return > > > > statement[2][3][4]. > > > > > > Are we sure we want to make this change? Was it discussed before? > > > > > > Are there any bugs Clangs puritanical definition of fallthrough helped > > > find? > > > > > > IMVHO compiler warnings are supposed to warn about issues that could > > > be bugs. Falling through to default: break; can hardly be a bug?! > > > > It's certainly a place where the intent is not always clear. I think > > this makes all the cases unambiguous, and doesn't impact the machine > > code, since the compiler will happily optimize away any behavioral > > redundancy. > > If none of the 140 patches here fix a real bug, and there is no change > to machine code then it sounds to me like a W=2 kind of a warning. FWIW, this series has found at least one bug so far: https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote: > Please tell me > our reward for all this effort isn't a single missing error print. There were quite literally dozens of logical defects found by the fallthrough additions. Very few were logging only.
On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote: > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote: > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote: > > > Please tell me our reward for all this effort isn't a single > > > missing error print. > > > > There were quite literally dozens of logical defects found > > by the fallthrough additions. Very few were logging only. > > So can you give us the best examples (or indeed all of them if someone > is keeping score)? hopefully this isn't a US election situation ... Gustavo? Are you running for congress now? https://lwn.net/Articles/794944/
On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote: > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote: > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote: > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote: > > > > Please tell me our reward for all this effort isn't a single > > > > missing error print. > > > > > > There were quite literally dozens of logical defects found > > > by the fallthrough additions. Very few were logging only. > > > > So can you give us the best examples (or indeed all of them if > > someone is keeping score)? hopefully this isn't a US election > > situation ... > > Gustavo? Are you running for congress now? > > https://lwn.net/Articles/794944/ That's 21 reported fixes of which about 50% seem to produce no change in code behaviour at all, a quarter seem to have no user visible effect with the remaining quarter producing unexpected errors on obscure configuration parameters, which is why no-one really noticed them before. James
On Mon, 2020-11-23 at 09:54 +1100, Finn Thain wrote: > But is anyone keeping score of the regressions? If unreported bugs > count, what about unreported regressions? Well, I was curious about the former (obviously no tool will tell me about the latter), so I asked git what patches had a fall-through series named in a fixes tag and these three popped out: 9cf51446e686 bpf, powerpc: Fix misuse of fallthrough in bpf_jit_comp() 6a9dc5fd6170 lib: Revert use of fallthrough pseudo-keyword in lib/ 91dbd73a1739 mips/oprofile: Fix fallthrough placement I don't think any of these is fixing a significant problem, but they did cause someone time and trouble to investigate. James
On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote: > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote: > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote: > > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote: > > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote: > > > > > Please tell me our reward for all this effort isn't a single > > > > > missing error print. > > > > > > > > There were quite literally dozens of logical defects found > > > > by the fallthrough additions. Very few were logging only. > > > > > > So can you give us the best examples (or indeed all of them if > > > someone is keeping score)? hopefully this isn't a US election > > > situation ... > > > > Gustavo? Are you running for congress now? > > > > https://lwn.net/Articles/794944/ > > That's 21 reported fixes of which about 50% seem to produce no change > in code behaviour at all, a quarter seem to have no user visible effect > with the remaining quarter producing unexpected errors on obscure > configuration parameters, which is why no-one really noticed them > before. The really important point here is the number of bugs this has prevented and will prevent in the future. See an example of this, below: https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/ This work is still relevant, even if the total number of issues/bugs we find in the process is zero (which is not the case). "The sucky thing about doing hard work to deploy hardening is that the result is totally invisible by definition (things not happening) [..]" - Dmitry Vyukov Thanks -- Gustavo
On Sun, Nov 22, 2020 at 11:54 PM Finn Thain <fthain@telegraphics.com.au> wrote: > > We should also take into account optimisim about future improvements in > tooling. Not sure what you mean here. There is no reliable way to guess what the intention was with a missing fallthrough, even if you parsed whitespace and indentation. > It is if you want to spin it that way. How is that a "spin"? It is a fact that we won't get *implicit* fallthrough mistakes anymore (in particular if we make it a hard error). > But what we inevitably get is changes like this: > > case 3: > this(); > + break; > case 4: > hmmm(); > > Why? Mainly to silence the compiler. Also because the patch author argued > successfully that they had found a theoretical bug, often in mature code. If someone changes control flow, that is on them. Every kernel developer knows what `break` does. > But is anyone keeping score of the regressions? If unreported bugs count, > what about unreported regressions? Introducing `fallthrough` does not change semantics. If you are really keen, you can always compare the objects because the generated code shouldn't change. Cheers, Miguel
On Sun, Nov 22, 2020 at 11:36 PM James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > > Well, it seems to be three years of someone's time plus the maintainer > review time and series disruption of nearly a thousand patches. Let's > be conservative and assume the producer worked about 30% on the series > and it takes about 5-10 minutes per patch to review, merge and for > others to rework existing series. So let's say it's cost a person year > of a relatively junior engineer producing the patches and say 100h of > review and application time. The latter is likely the big ticket item > because it's what we have in least supply in the kernel (even though > it's 20x vs the producer time). How are you arriving at such numbers? It is a total of ~200 trivial lines. > It's not about the risk of the changes it's about the cost of > implementing them. Even if you discount the producer time (which > someone gets to pay for, and if I were the engineering manager, I'd be > unhappy about), the review/merge/rework time is pretty significant in > exchange for six minor bug fixes. Fine, when a new compiler warning > comes along it's certainly reasonable to see if we can benefit from it > and the fact that the compiler people think it's worthwhile is enough > evidence to assume this initially. But at some point you have to ask > whether that assumption is supported by the evidence we've accumulated > over the time we've been using it. And if the evidence doesn't support > it perhaps it is time to stop the experiment. Maintainers routinely review 1-line trivial patches, not to mention internal API changes, etc. If some company does not want to pay for that, that's fine, but they don't get to be maintainers and claim `Supported`. Cheers, Miguel
On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote: > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley > <James.Bottomley@hansenpartnership.com> wrote: > > Well, it seems to be three years of someone's time plus the > > maintainer review time and series disruption of nearly a thousand > > patches. Let's be conservative and assume the producer worked > > about 30% on the series and it takes about 5-10 minutes per patch > > to review, merge and for others to rework existing series. So > > let's say it's cost a person year of a relatively junior engineer > > producing the patches and say 100h of review and application > > time. The latter is likely the big ticket item because it's what > > we have in least supply in the kernel (even though it's 20x vs the > > producer time). > > How are you arriving at such numbers? It is a total of ~200 trivial > lines. Well, I used git. It says that as of today in Linus' tree we have 889 patches related to fall throughs and the first series went in in october 2017 ... ignoring a couple of outliers back to February. > > It's not about the risk of the changes it's about the cost of > > implementing them. Even if you discount the producer time (which > > someone gets to pay for, and if I were the engineering manager, I'd > > be unhappy about), the review/merge/rework time is pretty > > significant in exchange for six minor bug fixes. Fine, when a new > > compiler warning comes along it's certainly reasonable to see if we > > can benefit from it and the fact that the compiler people think > > it's worthwhile is enough evidence to assume this initially. But > > at some point you have to ask whether that assumption is supported > > by the evidence we've accumulated over the time we've been using > > it. And if the evidence doesn't support it perhaps it is time to > > stop the experiment. > > Maintainers routinely review 1-line trivial patches, not to mention > internal API changes, etc. We're also complaining about the inability to recruit maintainers: https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/ And burn out: http://antirez.com/news/129 The whole crux of your argument seems to be maintainers' time isn't important so we should accept all trivial patches ... I'm pushing back on that assumption in two places, firstly the valulessness of the time and secondly that all trivial patches are valuable. > If some company does not want to pay for that, that's fine, but they > don't get to be maintainers and claim `Supported`. What I'm actually trying to articulate is a way of measuring value of the patch vs cost ... it has nothing really to do with who foots the actual bill. One thesis I'm actually starting to formulate is that this continual devaluing of maintainers is why we have so much difficulty keeping and recruiting them. James
On Mon, Nov 23, 2020 at 4:58 PM James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > > On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote: > > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley > > <James.Bottomley@hansenpartnership.com> wrote: [cut] > > > > Maintainers routinely review 1-line trivial patches, not to mention > > internal API changes, etc. > > We're also complaining about the inability to recruit maintainers: > > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/ > > And burn out: > > http://antirez.com/news/129 Right. > The whole crux of your argument seems to be maintainers' time isn't > important so we should accept all trivial patches ... I'm pushing back > on that assumption in two places, firstly the valulessness of the time > and secondly that all trivial patches are valuable. > > > If some company does not want to pay for that, that's fine, but they > > don't get to be maintainers and claim `Supported`. > > What I'm actually trying to articulate is a way of measuring value of > the patch vs cost ... it has nothing really to do with who foots the > actual bill. > > One thesis I'm actually starting to formulate is that this continual > devaluing of maintainers is why we have so much difficulty keeping and > recruiting them. Absolutely. This is just one of the factors involved, but a significant one IMV.
On Mon, 2020-11-23 at 07:03 -0600, Gustavo A. R. Silva wrote: > On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote: > > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote: > > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote: > > > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote: > > > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote: > > > > > > Please tell me our reward for all this effort isn't a > > > > > > single missing error print. > > > > > > > > > > There were quite literally dozens of logical defects found > > > > > by the fallthrough additions. Very few were logging only. > > > > > > > > So can you give us the best examples (or indeed all of them if > > > > someone is keeping score)? hopefully this isn't a US election > > > > situation ... > > > > > > Gustavo? Are you running for congress now? > > > > > > https://lwn.net/Articles/794944/ > > > > That's 21 reported fixes of which about 50% seem to produce no > > change in code behaviour at all, a quarter seem to have no user > > visible effect with the remaining quarter producing unexpected > > errors on obscure configuration parameters, which is why no-one > > really noticed them before. > > The really important point here is the number of bugs this has > prevented and will prevent in the future. See an example of this, > below: > > https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/ I think this falls into the same category as the other six bugs: it changes the output/input for parameters but no-one has really noticed, usually because the command is obscure or the bias effect is minor. > This work is still relevant, even if the total number of issues/bugs > we find in the process is zero (which is not the case). Really, no ... something which produces no improvement has no value at all ... we really shouldn't be wasting maintainer time with it because it has a cost to merge. I'm not sure we understand where the balance lies in value vs cost to merge but I am confident in the zero value case. > "The sucky thing about doing hard work to deploy hardening is that > the result is totally invisible by definition (things not happening) > [..]" > - Dmitry Vyukov Really, no. Something that can't be measured at all doesn't exist. And actually hardening is one of those things you can measure (which I do have to admit isn't true for everything in the security space) ... it's number of exploitable bugs found before you did it vs number of exploitable bugs found after you did it. Usually hardening eliminates a class of bug, so the way I've measured hardening before is to go through the CVE list for the last couple of years for product X, find all the bugs that are of the class we're looking to eliminate and say if we had hardened X against this class of bug we'd have eliminated Y% of the exploits. It can be quite impressive if Y is a suitably big number. James
On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote: > We're also complaining about the inability to recruit maintainers: > > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/ > > And burn out: > > http://antirez.com/news/129 https://www.wired.com/story/open-source-coders-few-tired/ > What I'm actually trying to articulate is a way of measuring value of > the patch vs cost ... it has nothing really to do with who foots the > actual bill. It's unclear how to measure value in consistency. But one way that costs can be reduced is by automation and _not_ involving maintainers when the patch itself is provably correct. > One thesis I'm actually starting to formulate is that this continual > devaluing of maintainers is why we have so much difficulty keeping and > recruiting them. The linux kernel has something like 1500 different maintainers listed in the MAINTAINERS file. That's not a trivial number. $ git grep '^M:' MAINTAINERS | sort | uniq -c | wc -l 1543 $ git grep '^M:' MAINTAINERS| cut -f1 -d'<' | sort | uniq -c | wc -l 1446 I think the question you are asking is about trust and how it effects development. And back to that wired story, the actual number of what you might be considering to be maintainers is likely less than 10% of the listed numbers above.
On Mon, Nov 23, 2020 at 4:58 PM James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > > Well, I used git. It says that as of today in Linus' tree we have 889 > patches related to fall throughs and the first series went in in > october 2017 ... ignoring a couple of outliers back to February. I can see ~10k insertions over ~1k commits and 15 years that mention a fallthrough in the entire repo. That is including some commits (like the biggest one, 960 insertions) that have nothing to do with C fallthrough. A single kernel release has an order of magnitude more changes than this... But if we do the math, for an author, at even 1 minute per line change and assuming nothing can be automated at all, it would take 1 month of work. For maintainers, a couple of trivial lines is noise compared to many other patches. In fact, this discussion probably took more time than the time it would take to review the 200 lines. :-) > We're also complaining about the inability to recruit maintainers: > > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/ > > And burn out: > > http://antirez.com/news/129 Accepting trivial and useful 1-line patches is not what makes a voluntary maintainer quit... Thankless work with demanding deadlines is. > The whole crux of your argument seems to be maintainers' time isn't > important so we should accept all trivial patches I have not said that, at all. In fact, I am a voluntary one and I welcome patches like this. It takes very little effort on my side to review and it helps the kernel overall. Paid maintainers are the ones that can take care of big features/reviews. > What I'm actually trying to articulate is a way of measuring value of > the patch vs cost ... it has nothing really to do with who foots the > actual bill. I understand your point, but you were the one putting it in terms of a junior FTE. In my view, 1 month-work (worst case) is very much worth removing a class of errors from a critical codebase. > One thesis I'm actually starting to formulate is that this continual > devaluing of maintainers is why we have so much difficulty keeping and > recruiting them. That may very well be true, but I don't feel anybody has devalued maintainers in this discussion. Cheers, Miguel
On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote: > IB/hfi1: Fix fall-through warnings for Clang > IB/mlx4: Fix fall-through warnings for Clang > IB/qedr: Fix fall-through warnings for Clang > RDMA/mlx5: Fix fall-through warnings for Clang I picked these four to the rdma tree, thanks Jason
On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote: > On Mon, Nov 23, 2020 at 4:58 PM James Bottomley > <James.Bottomley@hansenpartnership.com> wrote: > > Well, I used git. It says that as of today in Linus' tree we have > > 889 patches related to fall throughs and the first series went in > > in october 2017 ... ignoring a couple of outliers back to February. > > I can see ~10k insertions over ~1k commits and 15 years that mention > a fallthrough in the entire repo. That is including some commits > (like the biggest one, 960 insertions) that have nothing to do with C > fallthrough. A single kernel release has an order of magnitude more > changes than this... > > But if we do the math, for an author, at even 1 minute per line > change and assuming nothing can be automated at all, it would take 1 > month of work. For maintainers, a couple of trivial lines is noise > compared to many other patches. So you think a one line patch should take one minute to produce ... I really don't think that's grounded in reality. I suppose a one line patch only takes a minute to merge with b4 if no-one reviews or tests it, but that's not really desirable. > In fact, this discussion probably took more time than the time it > would take to review the 200 lines. :-) I'm framing the discussion in terms of the whole series of changes we have done for fall through, both what's in the tree currently (889 patches) both in terms of the produce and the consumer. That's what I used for my figures for cost. > > We're also complaining about the inability to recruit maintainers: > > > > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/ > > > > And burn out: > > > > http://antirez.com/news/129 > > Accepting trivial and useful 1-line patches Part of what I'm trying to measure is the "and useful" bit because that's not a given. > is not what makes a voluntary maintainer quit... so the proverb "straw which broke the camel's back" uniquely doesn't apply to maintainers > Thankless work with demanding deadlines is. That's another potential reason, but it doesn't may other reasons less valid. > > The whole crux of your argument seems to be maintainers' time isn't > > important so we should accept all trivial patches > > I have not said that, at all. In fact, I am a voluntary one and I > welcome patches like this. It takes very little effort on my side to > review and it helps the kernel overall. Well, you know, subsystems are very different in terms of the amount of patches a maintainer has to process per release cycle of the kernel. If a maintainer is close to capacity, additional patches, however trivial, become a problem. If a maintainer has spare cycles, trivial patches may look easy. > Paid maintainers are the ones that can take care of big > features/reviews. > > > What I'm actually trying to articulate is a way of measuring value > > of the patch vs cost ... it has nothing really to do with who foots > > the actual bill. > > I understand your point, but you were the one putting it in terms of > a junior FTE. No, I evaluated the producer side in terms of an FTE. What we're mostly arguing about here is the consumer side: the maintainers and people who have to rework their patch sets. I estimated that at 100h. > In my view, 1 month-work (worst case) is very much worth > removing a class of errors from a critical codebase. > > > One thesis I'm actually starting to formulate is that this > > continual devaluing of maintainers is why we have so much > > difficulty keeping and recruiting them. > > That may very well be true, but I don't feel anybody has devalued > maintainers in this discussion. You seem to be saying that because you find it easy to merge trivial patches, everyone should. I'm reminded of a friend long ago who thought being a Tees River Pilot was a sinecure because he could navigate the Tees blindfold. What he forgot, of course, is that just because it's easy with a trawler doesn't mean it's easy with an oil tanker. In fact it takes longer to qualify as a Tees River Pilot than it does to get a PhD. James
On Fri, Nov 20, 2020 at 11:47:37PM +0100, Florian Westphal wrote: > Gustavo A. R. Silva <gustavoars@kernel.org> wrote: > > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple > > warnings by explicitly adding multiple break statements instead of just > > letting the code fall through to the next case. > > Acked-by: Florian Westphal <fw@strlen.de> > > Feel free to carry this in next iteration of series, if any. Thanks, Florian. -- Gustavo
On Fri, Nov 20, 2020 at 09:50:06PM +0300, Igor Russkikh wrote: > > > On 20/11/2020 9:26 pm, Gustavo A. R. Silva wrote: > > External Email > > > > ---------------------------------------------------------------------- > > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple > > warnings by explicitly adding a couple of break statements instead of > > just letting the code fall through to the next case. > > > > Link: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_KSPP_linux > > _issues_115&d=DwIBAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=GtqbaEwqFLiM6BiwNMdKmpXb5o > > up1VLiSIroUNQwbYA&m=6E7IvGvqcEGj8wEOVoN1BySZhGUVECVTBJCmNiRsHUw&s=J1SWrfEL > > erJOzUlJdD_S5afGaZosmVP8lyKsu9DTULw&e= > > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> > > Reviewed-by: Igor Russkikh <irusskikh@marvell.com> Thanks, Igor. -- Gustavo
On Mon, 23 Nov 2020, Miguel Ojeda wrote: > On Mon, 23 Nov 2020, Finn Thain wrote: > > > On Sun, 22 Nov 2020, Miguel Ojeda wrote: > > > > > > > > It isn't that much effort, isn't it? Plus we need to take into > > > account the future mistakes that it might prevent, too. > > > > We should also take into account optimisim about future improvements > > in tooling. > > > Not sure what you mean here. There is no reliable way to guess what the > intention was with a missing fallthrough, even if you parsed whitespace > and indentation. > What I meant was that you've used pessimism as if it was fact. For example, "There is no way to guess what the effect would be if the compiler trained programmers to add a knee-jerk 'break' statement to avoid a warning". Moreover, what I meant was that preventing programmer mistakes is a problem to be solved by development tools. The idea that retro-fitting new language constructs onto mature code is somehow necessary to "prevent future mistakes" is entirely questionable. > > > So even if there were zero problems found so far, it is still a > > > positive change. > > > > > > > It is if you want to spin it that way. > > > How is that a "spin"? It is a fact that we won't get *implicit* > fallthrough mistakes anymore (in particular if we make it a hard error). > Perhaps "handwaving" is a better term? > > > I would agree if these changes were high risk, though; but they are > > > almost trivial. > > > > > > > This is trivial: > > > > case 1: > > this(); > > + fallthrough; > > case 2: > > that(); > > > > But what we inevitably get is changes like this: > > > > case 3: > > this(); > > + break; > > case 4: > > hmmm(); > > > > Why? Mainly to silence the compiler. Also because the patch author > > argued successfully that they had found a theoretical bug, often in > > mature code. > > > If someone changes control flow, that is on them. Every kernel developer > knows what `break` does. > Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that leads to well-intentioned patches that cause regressions, it is partly on you. Have you ever considered the overall cost of the countless -Wpresume-incompetence flags? Perhaps you pay the power bill for a build farm that produces logs that no-one reads? Perhaps you've run git bisect, knowing that the compiler messages are not interesting? Or compiled software in using a language that generates impenetrable messages? If so, here's a tip: # grep CFLAGS /etc/portage/make.conf CFLAGS="... -Wno-all -Wno-extra ..." CXXFLAGS="${CFLAGS}" Now allow me some pessimism: the hardware upgrades, gigawatt hours and wait time attributable to obligatory static analyses are a net loss. > > But is anyone keeping score of the regressions? If unreported bugs > > count, what about unreported regressions? > > > Introducing `fallthrough` does not change semantics. If you are really > keen, you can always compare the objects because the generated code > shouldn't change. > No, it's not for me to prove that such patches don't affect code generation. That's for the patch author and (unfortunately) for reviewers. > Cheers, > Miguel >
On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote: > > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote: > > If none of the 140 patches here fix a real bug, and there is no change > > to machine code then it sounds to me like a W=2 kind of a warning. > > FWIW, this series has found at least one bug so far: > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/ So looks like the bulk of these are: switch (x) { case 0: ++x; default: break; } I have a patch that fixes those up for clang: https://reviews.llvm.org/D91895 There's 3 other cases that don't quite match between GCC and Clang I observe in the kernel: switch (x) { case 0: ++x; default: goto y; } y:; switch (x) { case 0: ++x; default: return; } switch (x) { case 0: ++x; default: ; } Based on your link, and Nathan's comment on my patch, maybe Clang should continue to warn for the above (at least the `default: return;` case) and GCC should change? While the last case looks harmless, there were only 1 or 2 across the tree in my limited configuration testing; I really think we should just add `break`s for those.
On Fri, Nov 20, 2020 at 11:49:05PM +0100, Florian Westphal wrote: > Gustavo A. R. Silva <gustavoars@kernel.org> wrote: > > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning > > by explicitly adding a break statement instead of letting the code fall > > through to the next case. > > Acked-by: Florian Westphal <fw@strlen.de> Thanks, Florian. -- Gustavo
On Mon, Nov 23, 2020 at 04:03:45PM -0400, Jason Gunthorpe wrote: > On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote: > > > IB/hfi1: Fix fall-through warnings for Clang > > IB/mlx4: Fix fall-through warnings for Clang > > IB/qedr: Fix fall-through warnings for Clang > > RDMA/mlx5: Fix fall-through warnings for Clang > > I picked these four to the rdma tree, thanks Awesome. :) Thank you, Jason. -- Gustavo
On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote: > On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote: > > > > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote: > > > If none of the 140 patches here fix a real bug, and there is no change > > > to machine code then it sounds to me like a W=2 kind of a warning. > > > > FWIW, this series has found at least one bug so far: > > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/ > > So looks like the bulk of these are: > switch (x) { > case 0: > ++x; > default: > break; > } > > I have a patch that fixes those up for clang: > https://reviews.llvm.org/D91895 I still think this isn't right -- it's a case statement that runs off the end without an explicit flow control determination. I think Clang is right to warn for these, and GCC should also warn.
On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote: > Really, no ... something which produces no improvement has no value at > all ... we really shouldn't be wasting maintainer time with it because > it has a cost to merge. I'm not sure we understand where the balance > lies in value vs cost to merge but I am confident in the zero value > case. What? We can't measure how many future bugs aren't introduced because the kernel requires explicit case flow-control statements for all new code. We already enable -Wimplicit-fallthrough globally, so that's not the discussion. The issue is that Clang is (correctly) even more strict than GCC for this, so these are the remaining ones to fix for full Clang coverage too. People have spent more time debating this already than it would have taken to apply the patches. :) This is about robustness and language wrangling. It's a big code-base, and this is the price of our managing technical debt for permanent robustness improvements. (The numbers I ran from Gustavo's earlier patches were that about 10% of the places adjusted were identified as legitimate bugs being fixed. This final series may be lower, but there are still bugs being found from it -- we need to finish this and shut the door on it for good.)
On Tue, Nov 24, 2020 at 1:58 AM Finn Thain <fthain@telegraphics.com.au> wrote: > > What I meant was that you've used pessimism as if it was fact. "future mistakes that it might prevent" is neither pessimism nor states a fact. > For example, "There is no way to guess what the effect would be if the > compiler trained programmers to add a knee-jerk 'break' statement to avoid > a warning". It is only knee-jerk if you think you are infallible. > Moreover, what I meant was that preventing programmer mistakes is a > problem to be solved by development tools This warning comes from a development tool -- the compiler. > The idea that retro-fitting new > language constructs onto mature code is somehow necessary to "prevent > future mistakes" is entirely questionable. The kernel is not a frozen codebase. Further, "mature code vs. risk of change" arguments don't apply here because the semantics of the program and binary output isn't changing. > Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that > leads to well-intentioned patches that cause regressions, it is partly on > you. Again: adding a `fallthrough` does not change the program semantics. If you are a maintainer and want to cross-check, compare the codegen. > Have you ever considered the overall cost of the countless > -Wpresume-incompetence flags? Yeah: negative. On the other hand, the overall cost of the countless -fI-am-infallible flags is very noticeable. > Perhaps you pay the power bill for a build farm that produces logs that > no-one reads? Perhaps you've run git bisect, knowing that the compiler > messages are not interesting? Or compiled software in using a language > that generates impenetrable messages? If so, here's a tip: > > # grep CFLAGS /etc/portage/make.conf > CFLAGS="... -Wno-all -Wno-extra ..." > CXXFLAGS="${CFLAGS}" > > Now allow me some pessimism: the hardware upgrades, gigawatt hours and > wait time attributable to obligatory static analyses are a net loss. If you really believe compiler warnings and static analysis are useless and costly, I think there is not much point in continuing the discussion. > No, it's not for me to prove that such patches don't affect code > generation. That's for the patch author and (unfortunately) for reviewers. I was not asking you to prove it. I am stating that proving it is very easy. Cheers, Miguel
On 2020-11-20 12:39 -0600, Gustavo A. R. Silva wrote: > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning > by explicitly adding a break statement instead of letting the code fall > through to the next case. > > Link: https://github.com/KSPP/linux/issues/115 > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> > --- > drivers/staging/qlge/qlge_main.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/staging/qlge/qlge_main.c b/drivers/staging/qlge/qlge_main.c > index 27da386f9d87..c41b1373dcf8 100644 > --- a/drivers/staging/qlge/qlge_main.c > +++ b/drivers/staging/qlge/qlge_main.c > @@ -1385,6 +1385,7 @@ static void ql_categorize_rx_err(struct ql_adapter *qdev, u8 rx_err, > break; > case IB_MAC_IOCB_RSP_ERR_CRC: > stats->rx_crc_err++; > + break; > default: > break; > } In this instance, it think it would be more appropriate to remove the "default" case.
On Mon, Nov 23, 2020 at 10:39 PM James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote: > > On Mon, Nov 23, 2020 at 4:58 PM James Bottomley > > <James.Bottomley@hansenpartnership.com> wrote: ... > > But if we do the math, for an author, at even 1 minute per line > > change and assuming nothing can be automated at all, it would take 1 > > month of work. For maintainers, a couple of trivial lines is noise > > compared to many other patches. > > So you think a one line patch should take one minute to produce ... I > really don't think that's grounded in reality. I suppose a one line > patch only takes a minute to merge with b4 if no-one reviews or tests > it, but that's not really desirable. In my practice most of the one line patches were either to fix or to introduce quite interesting issues. 1 minute is 2-3 orders less than usually needed for such patches. That's why I don't like churn produced by people who often even didn't compile their useful contributions.
On Tue, Nov 24, 2020 at 11:05 PM James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > > On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote: > > We already enable -Wimplicit-fallthrough globally, so that's not the > > discussion. The issue is that Clang is (correctly) even more strict > > than GCC for this, so these are the remaining ones to fix for full > > Clang coverage too. > > > > People have spent more time debating this already than it would have > > taken to apply the patches. :) > > You mean we've already spent 90% of the effort to come this far so we > might as well go the remaining 10% because then at least we get some > return? It's certainly a clinching argument in defence procurement ... So developers and distributions using Clang can't have -Wimplicit-fallthrough enabled because GCC is less strict (which has been shown in this thread to lead to bugs)? We'd like to have nice things too, you know. I even agree that most of the churn comes from case 0: ++x; default: break; which I have a patch for: https://reviews.llvm.org/D91895. I agree that can never lead to bugs. But that's not the sole case of this series, just most of them. Though, note how the reviewer (C++ spec editor and clang front end owner) in https://reviews.llvm.org/D91895 even asks in that review how maybe a new flag would be more appropriate for a watered down/stylistic variant of the existing behavior. And if the current wording of Documentation/process/deprecated.rst around "fallthrough" is a straightforward rule of thumb, I kind of agree with him. > > > This is about robustness and language wrangling. It's a big code- > > base, and this is the price of our managing technical debt for > > permanent robustness improvements. (The numbers I ran from Gustavo's > > earlier patches were that about 10% of the places adjusted were > > identified as legitimate bugs being fixed. This final series may be > > lower, but there are still bugs being found from it -- we need to > > finish this and shut the door on it for good.) > > I got my six patches by analyzing the lwn.net report of the fixes that > was cited which had 21 of which 50% didn't actually change the emitted > code, and 25% didn't have a user visible effect. > > But the broader point I'm making is just because the compiler people > come up with a shiny new warning doesn't necessarily mean the problem That's not what this is though; you're attacking a strawman. I'd encourage you to bring that up when that actually occurs, unlike this case since it's actively hindering getting -Wimplicit-fallthrough enabled for Clang. This is not a shiny new warning; it's already on for GCC and has existed in both compilers for multiple releases. And I'll also note that warnings are warnings and not errors because they cannot be proven to be bugs in 100% of cases, but they have led to bugs in the past. They require a human to review their intent and remove ambiguities. If 97% of cases would end in a break ("Expert C Programming: Deep C Secrets" - Peter van der Linden), then it starts to look to me like a language defect; certainly an incorrectly chosen default. But the compiler can't know those 3% were intentional, unless you're explicit for those exceptional cases. > it's detecting is one that causes us actual problems in the code base. > I'd really be happier if we had a theory about what classes of CVE or > bug we could eliminate before we embrace the next new warning. We don't generally file CVEs and waiting for them to occur might be too reactive, but I agree that pointing to some additional documentation in commit messages about how a warning could lead to a bug would make it clearer to reviewers why being able to enable it treewide, even if there's no bug in their particular subsystem, is in the general interest of the commons. On Mon, Nov 23, 2020 at 7:58 AM James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > > We're also complaining about the inability to recruit maintainers: > > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/ > > And burn out: > > http://antirez.com/news/129 > > The whole crux of your argument seems to be maintainers' time isn't > important so we should accept all trivial patches ... I'm pushing back > on that assumption in two places, firstly the valulessness of the time > and secondly that all trivial patches are valuable. It's critical to the longevity of any open source project that there are not single points of failure. If someone is not expendable or replaceable (or claims to be) then that's a risk to the project and a bottleneck. Not having a replacement in training or some form of redundancy is short sighted. If trivial patches are adding too much to your workload, consider training a co-maintainer or asking for help from one of your reviewers whom you trust. I don't doubt it's hard to find maintainers, but existing maintainers should go out of their way to entrust co-maintainers especially when they find their workload becomes too high. And reviewing/picking up trivial patches is probably a great way to get started. If we allow too much knowledge of any one subsystem to collect with one maintainer, what happens when that maintainer leaves the community (which, given a finite lifespan, is an inevitability)?
On Wed, Nov 25, 2020 at 5:24 PM Jakub Kicinski <kuba@kernel.org> wrote: > > And just to spell it out, > > case ENUM_VALUE1: > bla(); > break; > case ENUM_VALUE2: > bla(); > default: > break; > > is a fairly idiomatic way of indicating that not all values of the enum > are expected to be handled by the switch statement. It looks like a benign typo to me -- `ENUM_VALUE2` does not follow the same pattern like `ENUM_VALUE1`. To me, the presence of the `default` is what indicates (explicitly) that not everything is handled. > Applying a real patch set and then getting a few follow ups the next day > for trivial coding things like fallthrough missing or static missing, > just because I didn't have the full range of compilers to check with > before applying makes me feel pretty shitty, like I'm not doing a good > job. YMMV. The number of compilers, checkers, static analyzers, tests, etc. we use keeps going up. That, indeed, means maintainers will miss more things (unless maintainers do more work than before). But catching bugs before they happen is *not* a bad thing. Perhaps we could encourage more rebasing in -next (while still giving credit to bots and testers) to avoid having many fixing commits afterwards, but that is orthogonal. I really don't think we should encourage the feeling that a maintainer is doing a bad job if they don't catch everything on their reviews. Any review is worth it. Maintainers, in the end, are just the "guaranteed" reviewers that decide when the code looks reasonable enough. They should definitely not feel pressured to be perfect. Cheers, Miguel
On Tue, Nov 24, 2020 at 11:05:35PM -0800, James Bottomley wrote: > Now, what we have seems to be about 6 cases (at least what's been shown > in this thread) where a missing break would cause potentially user > visible issues. That means the value of this isn't zero, but it's not > a no-brainer massive win either. That's why I think asking what we've > invested vs the return isn't a useless exercise. The number is much higher[1]. If it were 6 in the entire history of the kernel, I would agree with you. :) Some were fixed _before_ Gustavo's effort too, which I also count towards the idea of "this is a dangerous weakness in C, and now we have stopped it forever." > But the broader point I'm making is just because the compiler people > come up with a shiny new warning doesn't necessarily mean the problem > it's detecting is one that causes us actual problems in the code base. > I'd really be happier if we had a theory about what classes of CVE or > bug we could eliminate before we embrace the next new warning. But we did! It was long ago justified and documented[2], and even links to the CWE[3] for it. This wasn't random joy over discovering a new warning we could turn on, this was turning on a warning that the compiler folks finally gave us to handle an entire class of flaws. If we need to update the code-base to address it not a useful debate -- that was settled already, even if you're only discovering it now. :P. This last patch set is about finishing that work for Clang, which is correctly even more strict than GCC. -Kees [1] https://outflux.net/slides/2019/lss/kspp.pdf calls out specific numbers (about 6.5% of the patches fixed missing breaks): v4.19: 3 of 129 v4.20: 2 of 59 v5.0: 3 of 56 v5.1: 10 of 100 v5.2: 6 of 71 v5.3: 7 of 69 And in the history of the kernel, it's been an ongoing source of flaws: $ l --no-merges | grep -i 'missing break' | wc -l 185 The frequency of such errors being "naturally" found was pretty steady until the static checkers started warning, and then it was on the rise, but the full effort flushed the rest out, and now it's dropped to almost zero: 1 v2.6.12 3 v2.6.16.28 1 v2.6.17 1 v2.6.19 2 v2.6.21 1 v2.6.22 3 v2.6.24 3 v2.6.29 1 v2.6.32 1 v2.6.33 1 v2.6.35 4 v2.6.36 3 v2.6.38 2 v2.6.39 7 v3.0 2 v3.1 2 v3.2 2 v3.3 3 v3.4 1 v3.5 8 v3.6 7 v3.7 3 v3.8 6 v3.9 3 v3.10 2 v3.11 5 v3.12 5 v3.13 2 v3.14 4 v3.15 2 v3.16 3 v3.17 2 v3.18 2 v3.19 1 v4.0 2 v4.1 5 v4.2 4 v4.5 5 v4.7 6 v4.8 1 v4.9 3 v4.10 2 v4.11 6 v4.12 3 v4.13 2 v4.14 5 v4.15 2 v4.16 7 v4.18 2 v4.19 6 v4.20 3 v5.0 12 v5.1 3 v5.2 4 v5.3 2 v5.4 1 v5.8 And the reason it's fully zero, is because we still have the cases we're cleaning up right now. Even this last one from v5.8 is specifically of the same type this series addresses: case 4: color_index = TrueCModeIndex; + break; default: return; } [2] https://www.kernel.org/doc/html/latest/process/deprecated.html#implicit-switch-case-fall-through All switch/case blocks must end in one of: break; fallthrough; continue; goto <label>; return [expression]; [3] https://cwe.mitre.org/data/definitions/484.html
On Wed, Nov 25, 2020 at 8:24 AM Jakub Kicinski <kuba@kernel.org> wrote: > > Applying a real patch set and then getting a few follow ups the next day > for trivial coding things like fallthrough missing or static missing, > just because I didn't have the full range of compilers to check with > before applying makes me feel pretty shitty, like I'm not doing a good > job. YMMV. I understand. Everyone feels that way, except maybe Bond villains and robots. My advice in that case is don't take it personally. We're working with a language that's more error prone relative to others. While one would like to believe they are flawless, over time they can't beat the aggregate statistics. A balance between Imposter Syndrome and Dunning Kruger is walked by all software developers, and the fear of making mistakes in public is one of the number one reasons folks don't take the plunge contributing to open source software or even the kernel. My advice to them is "don't sweat the small stuff."
On Wed, 25 Nov 2020, Nick Desaulniers wrote: > On Wed, Nov 25, 2020 at 1:33 PM Finn Thain <fthain@telegraphics.com.au> wrote: > > > > Or do you think that a codebase can somehow satisfy multiple checkers > > and their divergent interpretations of the language spec? > > Have we found any cases yet that are divergent? I don't think so. You mean, aside from -Wimplicit-fallthrough? I'm glad you asked. How about -Wincompatible-pointer-types and -Wframe-larger-than? All of the following files have been affected by divergent diagnostics produced by clang and gcc. arch/arm64/include/asm/neon-intrinsics.h arch/powerpc/xmon/Makefile drivers/gpu/drm/i915/Makefile drivers/gpu/drm/i915/i915_utils.h drivers/staging/media/atomisp/pci/atomisp_subdev.c fs/ext4/super.c include/trace/events/qla.h net/mac80211/rate.c tools/lib/string.c tools/perf/util/setup.py tools/scripts/Makefile.include And if I searched for 'smatch' or 'coverity' instead of 'clang' I'd probably find more divergence. Here are some of the relevant commits. 0738c8b5915c7eaf1e6007b441008e8f3b460443 9c87156cce5a63735d1218f0096a65c50a7a32aa babaab2f473817f173a2d08e410c25abf5ed0f6b 065e5e559555e2f100bc95792a8ef1b609bbe130 93f56de259376d7e4fff2b2d104082e1fa66e237 6c4798d3f08b81c2c52936b10e0fa872590c96ae b7a313d84e853049062011d78cb04b6decd12f5c 093b75ef5995ea35d7f6bdb6c7b32a42a1999813 And before you object, "but -Wconstant-logical-operand is a clang-only warning! it can't be divergent with gcc!", consider that the special cases added to deal with clang-only warnings have to be removed when gcc catches up, which is more churn. Now multiply that by the number of checkers you care about.
On Wed, Nov 25, 2020 at 11:44 PM Edward Cree <ecree.xilinx@gmail.com> wrote: > > To make the intent clear, you have to first be certain that you > understand the intent; otherwise by adding either a break or a > fallthrough to suppress the warning you are just destroying the > information that "the intent of this code is unknown". If you don't know what the intent of your own code is, then you *already* have a problem in your hands. > Figuring out the intent of a piece of unfamiliar code takes more > than 1 minute; just because > case foo: > thing; > case bar: > break; > produces identical code to > case foo: > thing; > break; > case bar: > break; > doesn't mean that *either* is correct — maybe the author meant What takes 1 minute is adding it *mechanically* by the author, i.e. so that you later compare whether codegen is the same. > to write > case foo: > return thing; > case bar: > break; > and by inserting that break you've destroyed the marker that > would direct someone who knew what the code was about to look > at that point in the code and spot the problem. Then it means you already have a bug. This patchset gives the maintainer a chance to notice it, which is a good thing. The "you've destroyed the market" claim is bogus, because: 1. you were not looking into it 2. you didn't notice the bug so far 3. is implicit -- harder to spot 4. is only useful if you explicitly take a look at this kind of bug. So why don't you do it now? > Thus, you *always* have to look at more than just the immediate > mechanical context of the code, to make a proper judgement that > yes, this was the intent. I find that is the responsibility of the maintainers and reviewers for tree-wide patches like this, assuming they want. They can also keep the behavior (and the bugs) without spending time. Their choice. > If you think that that sort of thing > can be done in an *average* time of one minute, then I hope you > stay away from code I'm responsible for! Please don't accuse others of recklessness or incompetence, especially if you didn't understand what they said. > A warning is only useful because it makes you *think* about the > code. If you suppress the warning without doing that thinking, > then you made the warning useless; and if the warning made you > think about code that didn't *need* it, then the warning was > useless from the start. We are not suppressing the warning. Quite the opposite, in fact. > So make your mind up: does Clang's stricter -Wimplicit-fallthrough > flag up code that needs thought (in which case the fixes take > effort both to author and to review) As I said several times already, it does take time to review if the maintainer wants to take the chance to see if they had a bug to begin with, but it does not require thought for the author if they just go for equivalent codegen. > or does it flag up code > that can be mindlessly "fixed" (in which case the warning is > worthless)? Proponents in this thread seem to be trying to > have it both ways. A warning is not worthless just because you can mindlessly fix it. There are many counterexamples, e.g. many checkpatch/lint/lang-format/indentation warnings, functional ones like the `if (a = b)` warning... Cheers, Miguel
Hi Miguel, On Thu, Nov 26, 2020 at 3:54 PM Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > On Wed, Nov 25, 2020 at 11:44 PM Edward Cree <ecree.xilinx@gmail.com> wrote: > > To make the intent clear, you have to first be certain that you > > understand the intent; otherwise by adding either a break or a > > fallthrough to suppress the warning you are just destroying the > > information that "the intent of this code is unknown". > > If you don't know what the intent of your own code is, then you > *already* have a problem in your hands. The maintainer is not necessarily the owner/author of the code, and thus may not know the intent of the code. > > or does it flag up code > > that can be mindlessly "fixed" (in which case the warning is > > worthless)? Proponents in this thread seem to be trying to > > have it both ways. > > A warning is not worthless just because you can mindlessly fix it. > There are many counterexamples, e.g. many > checkpatch/lint/lang-format/indentation warnings, functional ones like > the `if (a = b)` warning... BTW, you cannot mindlessly fix the latter, as you cannot know if "(a == b)" or "((a = b))" was intended, without understanding the code (and the (possibly unavailable) data sheet, and the hardware, ...). P.S. So far I've stayed out of this thread, as I like it if the compiler flags possible mistakes. After all I was the one fixing new "may be used uninitialized" warnings thrown up by gcc-4.1, until (a bit later than) support for that compiler was removed... Gr{oetje,eeting}s, Geert
On Thu, Nov 26, 2020 at 4:28 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Miguel, > > On Thu, Nov 26, 2020 at 3:54 PM Miguel Ojeda > <miguel.ojeda.sandonis@gmail.com> wrote: > > On Wed, Nov 25, 2020 at 11:44 PM Edward Cree <ecree.xilinx@gmail.com> wrote: > > > To make the intent clear, you have to first be certain that you > > > understand the intent; otherwise by adding either a break or a > > > fallthrough to suppress the warning you are just destroying the > > > information that "the intent of this code is unknown". > > > > If you don't know what the intent of your own code is, then you > > *already* have a problem in your hands. > > The maintainer is not necessarily the owner/author of the code, and > thus may not know the intent of the code. > > > > or does it flag up code > > > that can be mindlessly "fixed" (in which case the warning is > > > worthless)? Proponents in this thread seem to be trying to > > > have it both ways. > > > > A warning is not worthless just because you can mindlessly fix it. > > There are many counterexamples, e.g. many > > checkpatch/lint/lang-format/indentation warnings, functional ones like > > the `if (a = b)` warning... > > BTW, you cannot mindlessly fix the latter, as you cannot know if > "(a == b)" or "((a = b))" was intended, without understanding the code > (and the (possibly unavailable) data sheet, and the hardware, ...). > to allow assignments in if statements was clearly a mistake and if you need outside information to understand the code, your code is the issue already. > P.S. So far I've stayed out of this thread, as I like it if the compiler > flags possible mistakes. After all I was the one fixing new > "may be used uninitialized" warnings thrown up by gcc-4.1, until > (a bit later than) support for that compiler was removed... > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel >
On Thu, Nov 26, 2020 at 4:28 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > The maintainer is not necessarily the owner/author of the code, and > thus may not know the intent of the code. Agreed, I was not blaming maintainers -- just trying to point out that the problem is there :-) In those cases, it is still very useful: we add the `fallthrough` and a comment saying `FIXME: fallthrough intended? Figure this out...`. Thus a previous unknown unknown is now a known unknown. And no new unknown unknowns will be introduced since we enabled the warning globally. > BTW, you cannot mindlessly fix the latter, as you cannot know if > "(a == b)" or "((a = b))" was intended, without understanding the code > (and the (possibly unavailable) data sheet, and the hardware, ...). That's right, I was referring to the cases where the compiler saves someone time from a typo they just made. Cheers, Miguel
On Wed, Nov 25, 2020 at 01:42:57PM +0900, Benjamin Poirier wrote: > On 2020-11-20 12:39 -0600, Gustavo A. R. Silva wrote: > > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning > > by explicitly adding a break statement instead of letting the code fall > > through to the next case. > > > > Link: https://github.com/KSPP/linux/issues/115 > > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> > > --- > > drivers/staging/qlge/qlge_main.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/staging/qlge/qlge_main.c b/drivers/staging/qlge/qlge_main.c > > index 27da386f9d87..c41b1373dcf8 100644 > > --- a/drivers/staging/qlge/qlge_main.c > > +++ b/drivers/staging/qlge/qlge_main.c > > @@ -1385,6 +1385,7 @@ static void ql_categorize_rx_err(struct ql_adapter *qdev, u8 rx_err, > > break; > > case IB_MAC_IOCB_RSP_ERR_CRC: > > stats->rx_crc_err++; > > + break; > > default: > > break; > > } > > In this instance, it think it would be more appropriate to remove the > "default" case. There are checkers which complain about that. (As a static checker developer myself, I think complaining about missing default cases is a waste of everyone's time). regards, dan carpenter
Gustavo, > This series aims to fix almost all remaining fall-through warnings in > order to enable -Wimplicit-fallthrough for Clang. Applied 20-22,54,120-124 to 5.11/scsi-staging, thanks.
On Tue, Dec 01, 2020 at 12:52:27AM -0500, Martin K. Petersen wrote: > > Gustavo, > > > This series aims to fix almost all remaining fall-through warnings in > > order to enable -Wimplicit-fallthrough for Clang. > > Applied 20-22,54,120-124 to 5.11/scsi-staging, thanks. Awesome! :) Thanks, Martin. -- Gustavo
On Sun, Nov 22, 2020 at 08:17:03AM -0800, Kees Cook wrote: > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote: > > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote: > > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote: > > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote: > > > > > This series aims to fix almost all remaining fall-through warnings in > > > > > order to enable -Wimplicit-fallthrough for Clang. > > > > > > > > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly > > > > > add multiple break/goto/return/fallthrough statements instead of just > > > > > letting the code fall through to the next case. > > > > > > > > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this > > > > > change[1] is meant to be reverted at some point. So, this patch helps > > > > > to move in that direction. > > > > > > > > > > Something important to mention is that there is currently a discrepancy > > > > > between GCC and Clang when dealing with switch fall-through to empty case > > > > > statements or to cases that only contain a break/continue/return > > > > > statement[2][3][4]. > > > > > > > > Are we sure we want to make this change? Was it discussed before? > > > > > > > > Are there any bugs Clangs puritanical definition of fallthrough helped > > > > find? > > > > > > > > IMVHO compiler warnings are supposed to warn about issues that could > > > > be bugs. Falling through to default: break; can hardly be a bug?! > > > > > > It's certainly a place where the intent is not always clear. I think > > > this makes all the cases unambiguous, and doesn't impact the machine > > > code, since the compiler will happily optimize away any behavioral > > > redundancy. > > > > If none of the 140 patches here fix a real bug, and there is no change > > to machine code then it sounds to me like a W=2 kind of a warning. > > FWIW, this series has found at least one bug so far: > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/ This is a fallthrough to a return and not to a break. That should trigger a warning. The fallthrough to a break should not generate a warning. The bug we're trying to fix is "missing break statement" but if the result of the bug is "we hit a break statement" then now we're just talking about style. GCC should limit itself to warning about potentially buggy code. regards, dan carpenter
On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote: > On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote: > > > > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote: > > > If none of the 140 patches here fix a real bug, and there is no change > > > to machine code then it sounds to me like a W=2 kind of a warning. > > > > FWIW, this series has found at least one bug so far: > > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/ > > So looks like the bulk of these are: > switch (x) { > case 0: > ++x; > default: > break; > } This should not generate a warning. > > I have a patch that fixes those up for clang: > https://reviews.llvm.org/D91895 > > There's 3 other cases that don't quite match between GCC and Clang I > observe in the kernel: > switch (x) { > case 0: > ++x; > default: > goto y; > } > y:; This should generate a warning. > > switch (x) { > case 0: > ++x; > default: > return; > } Warn for this. > > switch (x) { > case 0: > ++x; > default: > ; > } Don't warn for this. If adding a break statement changes the flow of the code then warn about potentially missing break statements, but if it doesn't change anything then don't warn about it. regards, dan carpenter
On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote: > This series aims to fix almost all remaining fall-through warnings in > order to enable -Wimplicit-fallthrough for Clang. > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly > add multiple break/goto/return/fallthrough statements instead of just > letting the code fall through to the next case. > > [...] Applied to 5.11/scsi-queue, thanks! [054/141] target: Fix fall-through warnings for Clang https://git.kernel.org/mkp/scsi/c/492096ecfa39
On 20/11/2020 20:37, Gustavo A. R. Silva wrote: > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning > by explicitly adding a break statement instead of letting the code fall > through to the next case. > > Link: https://github.com/KSPP/linux/issues/115 > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> > --- > net/bridge/br_input.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c > index 59a318b9f646..8db219d979c5 100644 > --- a/net/bridge/br_input.c > +++ b/net/bridge/br_input.c > @@ -148,6 +148,7 @@ int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb > break; > case BR_PKT_UNICAST: > dst = br_fdb_find_rcu(br, eth_hdr(skb)->h_dest, vid); > + break; > default: > break; > } > Somehow this hasn't hit my inbox, good thing I just got the reply and saw the patch. Anyway, thanks! Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Hi all, It's been more than 3 months; who can take this, please? :) Thanks -- Gustavo On Fri, Nov 20, 2020 at 12:31:02PM -0600, Gustavo A. R. Silva wrote: > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning > by explicitly adding a break statement instead of just letting the code > fall through to the next case. > > Link: https://github.com/KSPP/linux/issues/115 > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> > --- > drivers/net/ethernet/sun/cassini.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/net/ethernet/sun/cassini.c b/drivers/net/ethernet/sun/cassini.c > index 9ff894ba8d3e..54f45d8c79a7 100644 > --- a/drivers/net/ethernet/sun/cassini.c > +++ b/drivers/net/ethernet/sun/cassini.c > @@ -1599,6 +1599,7 @@ static inline int cas_mdio_link_not_up(struct cas *cp) > cas_phy_write(cp, MII_BMCR, val); > break; > } > + break; > default: > break; > } > -- > 2.27.0 >
Hi all, It's been more than 3 months; who can take this, please? :) Thanks -- Gustavo On Fri, Nov 20, 2020 at 12:31:13PM -0600, Gustavo A. R. Silva wrote: > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning > by explicitly adding a break statement instead of just letting the code > fall through to the next case. > > Link: https://github.com/KSPP/linux/issues/115 > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> > --- > drivers/net/ethernet/mscc/ocelot_vcap.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/net/ethernet/mscc/ocelot_vcap.c b/drivers/net/ethernet/mscc/ocelot_vcap.c > index d8c778ee6f1b..8f3ed81b9a08 100644 > --- a/drivers/net/ethernet/mscc/ocelot_vcap.c > +++ b/drivers/net/ethernet/mscc/ocelot_vcap.c > @@ -761,6 +761,7 @@ static void is1_entry_set(struct ocelot *ocelot, int ix, > vcap_key_bytes_set(vcap, &data, VCAP_IS1_HK_ETYPE, > etype.value, etype.mask); > } > + break; > } > default: > break; > -- > 2.27.0 >
Hi all, It's been more than 3 months; who can take this, please? :) Thanks -- Gustavo On Fri, Nov 20, 2020 at 12:35:01PM -0600, Gustavo A. R. Silva wrote: > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning > by explicitly adding a break statement instead of letting the code fall > through to the next case. > > Link: https://github.com/KSPP/linux/issues/115 > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> > --- > net/decnet/dn_route.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/decnet/dn_route.c b/net/decnet/dn_route.c > index 4cac31d22a50..2f3e5c49a221 100644 > --- a/net/decnet/dn_route.c > +++ b/net/decnet/dn_route.c > @@ -1407,7 +1407,7 @@ static int dn_route_input_slow(struct sk_buff *skb) > flags |= RTCF_DOREDIRECT; > > local_src = DN_FIB_RES_PREFSRC(res); > - > + break; > case RTN_BLACKHOLE: > case RTN_UNREACHABLE: > break; > -- > 2.27.0 >
Hi all, It's been more than 3 months; who can take this, please? :) Thanks -- Gustavo On Tue, Feb 02, 2021 at 04:16:07PM +0200, Nikolay Aleksandrov wrote: > On 20/11/2020 20:37, Gustavo A. R. Silva wrote: > > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning > > by explicitly adding a break statement instead of letting the code fall > > through to the next case. > > > > Link: https://github.com/KSPP/linux/issues/115 > > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> > > --- > > net/bridge/br_input.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c > > index 59a318b9f646..8db219d979c5 100644 > > --- a/net/bridge/br_input.c > > +++ b/net/bridge/br_input.c > > @@ -148,6 +148,7 @@ int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb > > break; > > case BR_PKT_UNICAST: > > dst = br_fdb_find_rcu(br, eth_hdr(skb)->h_dest, vid); > > + break; > > default: > > break; > > } > > > > Somehow this hasn't hit my inbox, good thing I just got the reply and saw the > patch. Anyway, thanks! > > Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com> >
Hi all, It's been more than 3 months; who can take this, please? :) Thanks -- Gustavo On Fri, Nov 20, 2020 at 12:38:25PM -0600, Gustavo A. R. Silva wrote: > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple > warnings by explicitly adding multiple break statements instead of > letting the code fall through to the next case. > > Link: https://github.com/KSPP/linux/issues/115 > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> > --- > drivers/net/plip/plip.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/net/plip/plip.c b/drivers/net/plip/plip.c > index 4406b353123e..e26cf91bdec2 100644 > --- a/drivers/net/plip/plip.c > +++ b/drivers/net/plip/plip.c > @@ -516,6 +516,7 @@ plip_receive(unsigned short nibble_timeout, struct net_device *dev, > *data_p |= (c0 << 1) & 0xf0; > write_data (dev, 0x00); /* send ACK */ > *ns_p = PLIP_NB_BEGIN; > + break; > case PLIP_NB_2: > break; > } > @@ -808,6 +809,7 @@ plip_send_packet(struct net_device *dev, struct net_local *nl, > return HS_TIMEOUT; > } > } > + break; > > case PLIP_PK_LENGTH_LSB: > if (plip_send(nibble_timeout, dev, > -- > 2.27.0 >
Hi all, It's been more than 3 months; who can take this, please? :) Thanks -- Gustavo On Fri, Nov 20, 2020 at 12:38:32PM -0600, Gustavo A. R. Silva wrote: > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple > warnings by explicitly adding multiple break statements instead of > letting the code fall through to the next case. > > Link: https://github.com/KSPP/linux/issues/115 > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> > --- > net/rose/rose_route.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/net/rose/rose_route.c b/net/rose/rose_route.c > index 6e35703ff353..c0e04c261a15 100644 > --- a/net/rose/rose_route.c > +++ b/net/rose/rose_route.c > @@ -347,6 +347,7 @@ static int rose_del_node(struct rose_route_struct *rose_route, > case 1: > rose_node->neighbour[1] = > rose_node->neighbour[2]; > + break; > case 2: > break; > } > @@ -508,6 +509,7 @@ void rose_rt_device_down(struct net_device *dev) > fallthrough; > case 1: > t->neighbour[1] = t->neighbour[2]; > + break; > case 2: > break; > } > -- > 2.27.0 >
Hi Gustavo, On Thu, Mar 04, 2021 at 04:53:18PM -0600, Gustavo A. R. Silva wrote: > Hi all, > > It's been more than 3 months; who can take this, please? :) > > Thanks > -- > Gustavo > > On Fri, Nov 20, 2020 at 12:31:13PM -0600, Gustavo A. R. Silva wrote: > > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning > > by explicitly adding a break statement instead of just letting the code > > fall through to the next case. > > > > Link: https://github.com/KSPP/linux/issues/115 > > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> > > --- You'd obviously need to resend. But when you do please add my: Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> And by the way, I think the netdev maintainers might want to take the patches on network drivers to avoid conflicts, but on the other hand they might not be too keen on cherry-picking bits and pieces of your 141 patch series. Would you mind creating a bundle of patches only for netdev? I see there's definitely more than just one patch, they would certainly get in a lot quicker that way.
Hi Vladimir, On 3/4/21 17:01, Vladimir Oltean wrote: > Hi Gustavo, > > On Thu, Mar 04, 2021 at 04:53:18PM -0600, Gustavo A. R. Silva wrote: >> Hi all, >> >> It's been more than 3 months; who can take this, please? :) >> >> Thanks >> -- >> Gustavo >> >> On Fri, Nov 20, 2020 at 12:31:13PM -0600, Gustavo A. R. Silva wrote: >>> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning >>> by explicitly adding a break statement instead of just letting the code >>> fall through to the next case. >>> >>> Link: https://github.com/KSPP/linux/issues/115 >>> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> >>> --- > > You'd obviously need to resend. But when you do please add my: > > Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> > > And by the way, I think the netdev maintainers might want to take the > patches on network drivers to avoid conflicts, but on the other hand > they might not be too keen on cherry-picking bits and pieces of your 141 > patch series. Would you mind creating a bundle of patches only for > netdev? I see there's definitely more than just one patch, they would > certainly get in a lot quicker that way. Thanks for your feedback. I already sent those patches again. I hope they are applied this time. :) -- Gustavo
Hi all, Friendly ping: who can take this, please? Thanks -- Gustavo On 11/20/20 12:34, Gustavo A. R. Silva wrote: > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning > by explicitly adding a fallthrough pseudo-keyword. > > Link: https://github.com/KSPP/linux/issues/115 > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> > --- > drivers/atm/fore200e.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c > index 9a70bee84125..ba3ed1b77bc5 100644 > --- a/drivers/atm/fore200e.c > +++ b/drivers/atm/fore200e.c > @@ -423,6 +423,7 @@ fore200e_shutdown(struct fore200e* fore200e) > /* XXX shouldn't we *start* by deregistering the device? */ > atm_dev_deregister(fore200e->atm_dev); > > + fallthrough; > case FORE200E_STATE_BLANK: > /* nothing to do for that state */ > break; >
Hi all, I've added this to my -next[1] branch for v5.14. Thanks -- Gustavo [1] https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/log/?h=for-next/kspp On 4/20/21 15:17, Gustavo A. R. Silva wrote: > Hi all, > > Friendly ping: who can take this, please? > > Thanks > -- > Gustavo > > On 11/20/20 12:34, Gustavo A. R. Silva wrote: >> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning >> by explicitly adding a fallthrough pseudo-keyword. >> >> Link: https://github.com/KSPP/linux/issues/115 >> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> >> --- >> drivers/atm/fore200e.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c >> index 9a70bee84125..ba3ed1b77bc5 100644 >> --- a/drivers/atm/fore200e.c >> +++ b/drivers/atm/fore200e.c >> @@ -423,6 +423,7 @@ fore200e_shutdown(struct fore200e* fore200e) >> /* XXX shouldn't we *start* by deregistering the device? */ >> atm_dev_deregister(fore200e->atm_dev); >> >> + fallthrough; >> case FORE200E_STATE_BLANK: >> /* nothing to do for that state */ >> break; >>
Hi all, This series aims to fix almost all remaining fall-through warnings in order to enable -Wimplicit-fallthrough for Clang. In preparation to enable -Wimplicit-fallthrough for Clang, explicitly add multiple break/goto/return/fallthrough statements instead of just letting the code fall through to the next case. Notice that in order to enable -Wimplicit-fallthrough for Clang, this change[1] is meant to be reverted at some point. So, this patch helps to move in that direction. Something important to mention is that there is currently a discrepancy between GCC and Clang when dealing with switch fall-through to empty case statements or to cases that only contain a break/continue/return statement[2][3][4]. Now that the -Wimplicit-fallthrough option has been globally enabled[5], any compiler should really warn on missing either a fallthrough annotation or any of the other case-terminating statements (break/continue/return/ goto) when falling through to the next case statement. Making exceptions to this introduces variation in case handling which may continue to lead to bugs, misunderstandings, and a general lack of robustness. The point of enabling options like -Wimplicit-fallthrough is to prevent human error and aid developers in spotting bugs before their code is even built/ submitted/committed, therefore eliminating classes of bugs. So, in order to really accomplish this, we should, and can, move in the direction of addressing any error-prone scenarios and get rid of the unintentional fallthrough bug-class in the kernel, entirely, even if there is some minor redundancy. Better to have explicit case-ending statements than continue to have exceptions where one must guess as to the right result. The compiler will eliminate any actual redundancy. Note that there is already a patch in mainline that addresses almost 40,000 of these issues[6]. I'm happy to carry this whole series in my own tree if people are OK with it. :) [1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now") [2] ClangBuiltLinux#636 [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 [4] https://godbolt.org/z/xgkvIh [5] commit a035d552a93b ("Makefile: Globally enable fall-through warning") [6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang") Thanks! Gustavo A. R. Silva (141): afs: Fix fall-through warnings for Clang ASoC: codecs: Fix fall-through warnings for Clang cifs: Fix fall-through warnings for Clang drm/amdgpu: Fix fall-through warnings for Clang drm/radeon: Fix fall-through warnings for Clang gfs2: Fix fall-through warnings for Clang gpio: Fix fall-through warnings for Clang IB/hfi1: Fix fall-through warnings for Clang igb: Fix fall-through warnings for Clang ima: Fix fall-through warnings for Clang ipv4: Fix fall-through warnings for Clang ixgbe: Fix fall-through warnings for Clang media: dvb-frontends: Fix fall-through warnings for Clang media: usb: dvb-usb-v2: Fix fall-through warnings for Clang netfilter: Fix fall-through warnings for Clang nfsd: Fix fall-through warnings for Clang nfs: Fix fall-through warnings for Clang qed: Fix fall-through warnings for Clang qlcnic: Fix fall-through warnings for Clang scsi: aic7xxx: Fix fall-through warnings for Clang scsi: aic94xx: Fix fall-through warnings for Clang scsi: bfa: Fix fall-through warnings for Clang staging: rtl8723bs: core: Fix fall-through warnings for Clang staging: vt6655: Fix fall-through warnings for Clang bnxt_en: Fix fall-through warnings for Clang ceph: Fix fall-through warnings for Clang drbd: Fix fall-through warnings for Clang drm/amd/display: Fix fall-through warnings for Clang e1000: Fix fall-through warnings for Clang ext2: Fix fall-through warnings for Clang ext4: Fix fall-through warnings for Clang floppy: Fix fall-through warnings for Clang fm10k: Fix fall-through warnings for Clang IB/mlx4: Fix fall-through warnings for Clang IB/qedr: Fix fall-through warnings for Clang ice: Fix fall-through warnings for Clang Input: pcspkr - Fix fall-through warnings for Clang isofs: Fix fall-through warnings for Clang ixgbevf: Fix fall-through warnings for Clang kprobes/x86: Fix fall-through warnings for Clang mm: Fix fall-through warnings for Clang net: 3c509: Fix fall-through warnings for Clang net: cassini: Fix fall-through warnings for Clang net/mlx4: Fix fall-through warnings for Clang net: mscc: ocelot: Fix fall-through warnings for Clang netxen_nic: Fix fall-through warnings for Clang nfp: Fix fall-through warnings for Clang perf/x86: Fix fall-through warnings for Clang pinctrl: Fix fall-through warnings for Clang RDMA/mlx5: Fix fall-through warnings for Clang reiserfs: Fix fall-through warnings for Clang security: keys: Fix fall-through warnings for Clang selinux: Fix fall-through warnings for Clang target: Fix fall-through warnings for Clang uprobes/x86: Fix fall-through warnings for Clang vxge: Fix fall-through warnings for Clang watchdog: Fix fall-through warnings for Clang xen-blkfront: Fix fall-through warnings for Clang regulator: as3722: Fix fall-through warnings for Clang habanalabs: Fix fall-through warnings for Clang tee: Fix fall-through warnings for Clang HID: usbhid: Fix fall-through warnings for Clang HID: input: Fix fall-through warnings for Clang ACPI: Fix fall-through warnings for Clang airo: Fix fall-through warnings for Clang ALSA: hdspm: Fix fall-through warnings for Clang ALSA: pcsp: Fix fall-through warnings for Clang ALSA: sb: Fix fall-through warnings for Clang ath5k: Fix fall-through warnings for Clang atm: fore200e: Fix fall-through warnings for Clang braille_console: Fix fall-through warnings for Clang can: peak_usb: Fix fall-through warnings for Clang carl9170: Fix fall-through warnings for Clang cfg80211: Fix fall-through warnings for Clang crypto: ccree - Fix fall-through warnings for Clang decnet: Fix fall-through warnings for Clang dm raid: Fix fall-through warnings for Clang drm/amd/pm: Fix fall-through warnings for Clang drm: Fix fall-through warnings for Clang drm/i915/gem: Fix fall-through warnings for Clang drm/nouveau/clk: Fix fall-through warnings for Clang drm/nouveau: Fix fall-through warnings for Clang drm/nouveau/therm: Fix fall-through warnings for Clang drm/via: Fix fall-through warnings for Clang firewire: core: Fix fall-through warnings for Clang hwmon: (corsair-cpro) Fix fall-through warnings for Clang hwmon: (max6621) Fix fall-through warnings for Clang i3c: master: cdns: Fix fall-through warnings for Clang ide: Fix fall-through warnings for Clang iio: adc: cpcap: Fix fall-through warnings for Clang iwlwifi: iwl-drv: Fix fall-through warnings for Clang libata: Fix fall-through warnings for Clang mac80211: Fix fall-through warnings for Clang media: atomisp: Fix fall-through warnings for Clang media: dvb_frontend: Fix fall-through warnings for Clang media: rcar_jpu: Fix fall-through warnings for Clang media: saa7134: Fix fall-through warnings for Clang mmc: sdhci-of-arasan: Fix fall-through warnings for Clang mt76: mt7615: Fix fall-through warnings for Clang mtd: cfi: Fix fall-through warnings for Clang mtd: mtdchar: Fix fall-through warnings for Clang mtd: onenand: Fix fall-through warnings for Clang mtd: rawnand: fsmc: Fix fall-through warnings for Clang mtd: rawnand: stm32_fmc2: Fix fall-through warnings for Clang net: ax25: Fix fall-through warnings for Clang net: bridge: Fix fall-through warnings for Clang net: core: Fix fall-through warnings for Clang netfilter: ipt_REJECT: Fix fall-through warnings for Clang net: netrom: Fix fall-through warnings for Clang net/packet: Fix fall-through warnings for Clang net: plip: Fix fall-through warnings for Clang net: rose: Fix fall-through warnings for Clang nl80211: Fix fall-through warnings for Clang phy: qcom-usb-hs: Fix fall-through warnings for Clang rds: Fix fall-through warnings for Clang rt2x00: Fix fall-through warnings for Clang rtl8xxxu: Fix fall-through warnings for Clang rtw88: Fix fall-through warnings for Clang rxrpc: Fix fall-through warnings for Clang scsi: aacraid: Fix fall-through warnings for Clang scsi: aha1740: Fix fall-through warnings for Clang scsi: csiostor: Fix fall-through warnings for Clang scsi: lpfc: Fix fall-through warnings for Clang scsi: stex: Fix fall-through warnings for Clang sctp: Fix fall-through warnings for Clang slimbus: messaging: Fix fall-through warnings for Clang staging: qlge: Fix fall-through warnings for Clang staging: vt6656: Fix fall-through warnings for Clang SUNRPC: Fix fall-through warnings for Clang tipc: Fix fall-through warnings for Clang tpm: Fix fall-through warnings for Clang ubi: Fix fall-through warnings for Clang usb: Fix fall-through warnings for Clang video: fbdev: lxfb_ops: Fix fall-through warnings for Clang video: fbdev: pm2fb: Fix fall-through warnings for Clang virtio_net: Fix fall-through warnings for Clang wcn36xx: Fix fall-through warnings for Clang xen/manage: Fix fall-through warnings for Clang xfrm: Fix fall-through warnings for Clang zd1201: Fix fall-through warnings for Clang Input: libps2 - Fix fall-through warnings for Clang arch/x86/events/core.c | 2 +- arch/x86/kernel/kprobes/core.c | 1 + arch/x86/kernel/uprobes.c | 2 ++ drivers/accessibility/braille/braille_console.c | 1 + drivers/acpi/sbshc.c | 1 + drivers/ata/libata-eh.c | 1 + drivers/atm/fore200e.c | 1 + drivers/block/drbd/drbd_receiver.c | 1 + drivers/block/drbd/drbd_req.c | 1 + drivers/block/floppy.c | 1 + drivers/block/xen-blkfront.c | 1 + drivers/char/tpm/eventlog/tpm1.c | 1 + drivers/crypto/ccree/cc_cipher.c | 3 +++ drivers/firewire/core-topology.c | 1 + drivers/gpio/gpio-ath79.c | 1 + drivers/gpio/gpiolib-acpi.c | 1 + drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 1 + drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 1 + drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 1 + drivers/gpu/drm/amd/amdgpu/vi.c | 1 + drivers/gpu/drm/amd/display/dc/bios/bios_parser.c | 1 + drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 2 ++ drivers/gpu/drm/amd/display/dc/core/dc_link.c | 1 + drivers/gpu/drm/amd/pm/powerplay/si_dpm.c | 2 +- .../gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c | 1 + drivers/gpu/drm/drm_bufs.c | 1 + drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 1 + drivers/gpu/drm/nouveau/nouveau_bo.c | 1 + drivers/gpu/drm/nouveau/nouveau_connector.c | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c | 1 + drivers/gpu/drm/radeon/ci_dpm.c | 2 +- drivers/gpu/drm/radeon/r300.c | 1 + drivers/gpu/drm/radeon/si_dpm.c | 2 +- drivers/gpu/drm/via/via_irq.c | 1 + drivers/hid/hid-input.c | 1 + drivers/hid/usbhid/hid-core.c | 2 ++ drivers/hwmon/corsair-cpro.c | 1 + drivers/hwmon/max6621.c | 2 +- drivers/i3c/master/i3c-master-cdns.c | 2 ++ drivers/ide/siimage.c | 1 + drivers/iio/adc/cpcap-adc.c | 1 + drivers/infiniband/hw/hfi1/qp.c | 1 + drivers/infiniband/hw/hfi1/tid_rdma.c | 5 +++++ drivers/infiniband/hw/mlx4/mad.c | 1 + drivers/infiniband/hw/mlx5/qp.c | 1 + drivers/infiniband/hw/qedr/main.c | 1 + drivers/input/misc/pcspkr.c | 1 + drivers/input/serio/libps2.c | 2 +- drivers/md/dm-raid.c | 1 + drivers/media/dvb-core/dvb_frontend.c | 1 + drivers/media/dvb-frontends/cx24120.c | 1 + drivers/media/dvb-frontends/dib0090.c | 2 ++ drivers/media/dvb-frontends/drxk_hard.c | 1 + drivers/media/dvb-frontends/m88rs2000.c | 1 + drivers/media/pci/saa7134/saa7134-tvaudio.c | 1 + drivers/media/platform/rcar_jpu.c | 1 + drivers/media/usb/dvb-usb-v2/af9015.c | 1 + drivers/media/usb/dvb-usb-v2/lmedm04.c | 1 + drivers/misc/habanalabs/gaudi/gaudi.c | 1 + drivers/mmc/host/sdhci-of-arasan.c | 4 ++++ drivers/mtd/chips/cfi_cmdset_0001.c | 1 + drivers/mtd/chips/cfi_cmdset_0002.c | 2 ++ drivers/mtd/chips/cfi_cmdset_0020.c | 2 ++ drivers/mtd/mtdchar.c | 1 + drivers/mtd/nand/onenand/onenand_samsung.c | 1 + drivers/mtd/nand/raw/fsmc_nand.c | 1 + drivers/mtd/nand/raw/stm32_fmc2_nand.c | 2 ++ drivers/mtd/ubi/build.c | 1 + drivers/net/can/usb/peak_usb/pcan_usb_core.c | 2 ++ drivers/net/ethernet/3com/3c509.c | 1 + drivers/net/ethernet/broadcom/bnxt/bnxt.c | 1 + drivers/net/ethernet/intel/e1000/e1000_hw.c | 1 + drivers/net/ethernet/intel/fm10k/fm10k_mbx.c | 2 ++ drivers/net/ethernet/intel/ice/ice_txrx_lib.c | 1 + drivers/net/ethernet/intel/igb/e1000_phy.c | 1 + drivers/net/ethernet/intel/igb/igb_ethtool.c | 1 + drivers/net/ethernet/intel/igb/igb_ptp.c | 1 + drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c | 2 ++ drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 1 + drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c | 1 + drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 1 + drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 1 + drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 1 + drivers/net/ethernet/mscc/ocelot_vcap.c | 1 + drivers/net/ethernet/neterion/vxge/vxge-config.c | 1 + drivers/net/ethernet/netronome/nfp/nfp_net_repr.c | 1 + drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c | 1 + drivers/net/ethernet/qlogic/qed/qed_l2.c | 1 + drivers/net/ethernet/qlogic/qed/qed_sriov.c | 1 + drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c | 1 + drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 1 + drivers/net/ethernet/sun/cassini.c | 1 + drivers/net/plip/plip.c | 2 ++ drivers/net/virtio_net.c | 1 + drivers/net/wireless/ath/ath5k/mac80211-ops.c | 1 + drivers/net/wireless/ath/carl9170/tx.c | 1 + drivers/net/wireless/ath/wcn36xx/smd.c | 2 +- drivers/net/wireless/cisco/airo.c | 1 + drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 2 +- drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c | 2 +- drivers/net/wireless/ralink/rt2x00/rt2x00queue.c | 1 + drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 8 ++++---- drivers/net/wireless/realtek/rtw88/fw.c | 2 +- drivers/net/wireless/zydas/zd1201.c | 2 +- drivers/phy/qualcomm/phy-qcom-usb-hs.c | 1 + drivers/pinctrl/renesas/pinctrl-rza1.c | 1 + drivers/regulator/as3722-regulator.c | 3 ++- drivers/scsi/aacraid/commsup.c | 1 + drivers/scsi/aha1740.c | 1 + drivers/scsi/aic7xxx/aic79xx_core.c | 4 +++- drivers/scsi/aic7xxx/aic7xxx_core.c | 4 ++-- drivers/scsi/aic94xx/aic94xx_scb.c | 2 ++ drivers/scsi/aic94xx/aic94xx_task.c | 2 ++ drivers/scsi/bfa/bfa_fcs_lport.c | 2 +- drivers/scsi/bfa/bfa_ioc.c | 6 ++++-- drivers/scsi/csiostor/csio_wr.c | 1 + drivers/scsi/lpfc/lpfc_bsg.c | 1 + drivers/scsi/stex.c | 1 + drivers/slimbus/messaging.c | 1 + drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c | 1 + drivers/staging/qlge/qlge_main.c | 1 + drivers/staging/rtl8723bs/core/rtw_cmd.c | 1 + drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 1 + drivers/staging/rtl8723bs/core/rtw_wlan_util.c | 1 + drivers/staging/vt6655/device_main.c | 1 + drivers/staging/vt6655/rxtx.c | 2 ++ drivers/staging/vt6656/main_usb.c | 1 + drivers/target/target_core_iblock.c | 1 + drivers/target/target_core_pr.c | 1 + drivers/tee/tee_core.c | 1 + drivers/usb/gadget/function/f_fs.c | 2 ++ drivers/usb/gadget/function/f_loopback.c | 2 +- drivers/usb/gadget/function/f_sourcesink.c | 1 + drivers/usb/gadget/udc/dummy_hcd.c | 2 ++ drivers/usb/host/fotg210-hcd.c | 2 +- drivers/usb/host/isp116x-hcd.c | 1 + drivers/usb/host/max3421-hcd.c | 1 + drivers/usb/host/oxu210hp-hcd.c | 1 + drivers/usb/misc/yurex.c | 1 + drivers/usb/musb/tusb6010.c | 1 + drivers/usb/storage/ene_ub6250.c | 1 + drivers/usb/storage/uas.c | 1 + drivers/video/fbdev/geode/lxfb_ops.c | 1 + drivers/video/fbdev/pm2fb.c | 1 + drivers/watchdog/machzwd.c | 1 + drivers/xen/manage.c | 1 + fs/afs/cmservice.c | 5 +++++ fs/afs/fsclient.c | 4 ++++ fs/afs/vlclient.c | 1 + fs/ceph/dir.c | 2 ++ fs/cifs/inode.c | 1 + fs/cifs/sess.c | 1 + fs/cifs/smbdirect.c | 1 + fs/ext2/inode.c | 1 + fs/ext4/super.c | 1 + fs/gfs2/inode.c | 2 ++ fs/gfs2/recovery.c | 1 + fs/isofs/rock.c | 1 + fs/nfs/nfs3acl.c | 1 + fs/nfs/nfs4client.c | 1 + fs/nfs/nfs4proc.c | 2 ++ fs/nfs/nfs4state.c | 1 + fs/nfs/pnfs.c | 2 ++ fs/nfsd/nfs4state.c | 1 + fs/nfsd/nfsctl.c | 1 + fs/reiserfs/namei.c | 1 + mm/mm_init.c | 1 + mm/vmscan.c | 1 + net/ax25/af_ax25.c | 1 + net/bridge/br_input.c | 1 + net/core/dev.c | 1 + net/decnet/dn_route.c | 2 +- net/ipv4/ah4.c | 1 + net/ipv4/esp4.c | 1 + net/ipv4/fib_semantics.c | 1 + net/ipv4/ip_vti.c | 1 + net/ipv4/ipcomp.c | 1 + net/ipv4/netfilter/ipt_REJECT.c | 1 + net/mac80211/cfg.c | 2 ++ net/netfilter/nf_conntrack_proto_dccp.c | 1 + net/netfilter/nf_tables_api.c | 1 + net/netfilter/nft_ct.c | 1 + net/netrom/nr_route.c | 4 ++++ net/packet/af_packet.c | 1 + net/rds/tcp_connect.c | 1 + net/rds/threads.c | 2 ++ net/rose/rose_route.c | 2 ++ net/rxrpc/af_rxrpc.c | 1 + net/sctp/input.c | 3 ++- net/sunrpc/rpc_pipe.c | 1 + net/sunrpc/xprtsock.c | 1 + net/tipc/link.c | 1 + net/wireless/nl80211.c | 1 + net/wireless/util.c | 1 + net/xfrm/xfrm_interface.c | 1 + security/integrity/ima/ima_main.c | 1 + security/integrity/ima/ima_policy.c | 2 ++ security/keys/process_keys.c | 1 + security/selinux/hooks.c | 1 + sound/drivers/pcsp/pcsp_input.c | 1 + sound/isa/sb/sb8_main.c | 1 + sound/pci/rme9652/hdspm.c | 1 + sound/soc/codecs/adav80x.c | 1 + sound/soc/codecs/arizona.c | 1 + sound/soc/codecs/cs42l52.c | 1 + sound/soc/codecs/cs42l56.c | 1 + sound/soc/codecs/cs47l92.c | 1 + sound/soc/codecs/wm8962.c | 1 + 209 files changed, 264 insertions(+), 26 deletions(-)