Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
Hi Gustavo, On Fri, Nov 20, 2020 at 7:21 PM Gustavo A. R. Silva wrote: > > Hi all, > > This series aims to fix almost all remaining fall-through warnings in > order to enable -Wimplicit-fallthrough for Clang. Thanks for this. Since this warning is reliable in both/all compilers and we are eventually getting rid of all the cases, what about going even further and making it an error right after? Cheers, Miguel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
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?! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
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
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
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. > 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. > 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. But is anyone keeping score of the regressions? If unreported bugs count, what about unreported regressions? > Cheers, > Miguel > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
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 think clang is just being annoying here, but if I'm the only one who feels this way chances are I'm wrong :) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 080/141] drm/i915/gem: Fix fall-through warnings for Clang
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a return 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
---
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index dc8f052a0ffe..b699c1adb106 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -59,6 +59,7 @@ static void try_to_writeback(struct drm_i915_gem_object *obj,
switch (obj->mm.madv) {
case I915_MADV_DONTNEED:
i915_gem_object_truncate(obj);
+ return;
case __I915_MADV_PURGED:
return;
}
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
On Sun, Nov 22, 2020 at 7:22 PM James Bottomley wrote: > > Well, it's a problem in an error leg, sure, but it's not a really > compelling reason for a 141 patch series, is it? All that fixing this > error will do is get the driver to print "oh dear there's a problem" > under four more conditions than it previously did. > > We've been at this for three years now with nearly a thousand patches, > firstly marking all the fall throughs with /* fall through */ and later > changing it to fallthrough. At some point we do have to ask if the > effort is commensurate with the protection afforded. Please tell me > our reward for all this effort isn't a single missing error print. It isn't that much effort, isn't it? Plus we need to take into account the future mistakes that it might prevent, too. So even if there were zero problems found so far, it is still a positive change. I would agree if these changes were high risk, though; but they are almost trivial. Cheers, Miguel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] MAINTAINERS tag for cleanup robot
On Sun, 22 Nov 2020, Joe Perches wrote: > On Sun, 2020-11-22 at 08:49 -0800, James Bottomley wrote: > > We can enforce sysfs_emit going forwards > > using tools like checkpatch > > It's not really possible for checkpatch to find or warn about > sysfs uses of sprintf. checkpatch is really just a trivial > line-by-line parser and it has no concept of code intent. > Checkpatch does suffer from the limitations of regular expressions. But that doesn't stop people from using it. Besides, Coccinelle can do analyses that can't be done with regular expressions, so it's moot. > It just can't warn on every use of the sprintf family. > There are just too many perfectly valid uses. > > > but there's no benefit and a lot of harm to > > be done by trying to churn the entire tree > > Single uses of sprintf for sysfs is not really any problem. > > But likely there are still several possible overrun sprintf/snprintf > paths in sysfs. Some of them are very obscure and unlikely to be > found by a robot as the logic for sysfs buf uses can be fairly twisty. > Logic errors of this kind are susceptible to fuzzing, formal methods, symbolic execution etc. No doubt there are other techniques that I don't know about. > But provably correct conversions IMO _should_ be done and IMO churn > considerations should generally have less importance. > Provably equivalent conversions are provably churn. So apparently you're advocating changes that are not provably equivalent. These are patches for code not that's not been shown to be buggy. Code which, after patching, can be shown to be free of a specific kind of theoretical bug. Hardly "provably correct". The problem is, the class of theoretical bugs that can be avoided in this way is probably limitless, as is the review cost and the risk of accidental regressions. And the payoff is entirely theoretical. Moreover, the patch review workload for skilled humans is being generated by the automation, which is completely backwards: the machine is supposed to be helping. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] MAINTAINERS tag for cleanup robot
On Mon, 2020-11-23 at 09:33 +1100, Finn Thain wrote:
> On Sun, 22 Nov 2020, Joe Perches wrote:
> > But provably correct conversions IMO _should_ be done and IMO churn
> > considerations should generally have less importance.
[]
> Moreover, the patch review workload for skilled humans is being generated
> by the automation, which is completely backwards: the machine is supposed
> to be helping.
Which is why the provably correct matters.
coccinelle transforms can be, but are not necessarily, provably correct.
The _show transforms done via the sysfs_emit_dev.cocci script are correct
as in commit aa838896d87a ("drivers core: Use sysfs_emit and sysfs_emit_at
for show(device *...) functions")
Worthwhile? A different question, but I think yes as it reduces the
overall question space of the existing other sprintf overrun possibilities.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
On Sun, 2020-11-22 at 21:35 +0100, Miguel Ojeda wrote: > On Sun, Nov 22, 2020 at 7:22 PM James Bottomley > wrote: > > Well, it's a problem in an error leg, sure, but it's not a really > > compelling reason for a 141 patch series, is it? All that fixing > > this error will do is get the driver to print "oh dear there's a > > problem" under four more conditions than it previously did. > > > > We've been at this for three years now with nearly a thousand > > patches, firstly marking all the fall throughs with /* fall through > > */ and later changing it to fallthrough. At some point we do have > > to ask if the effort is commensurate with the protection > > afforded. Please tell me our reward for all this effort isn't a > > single missing error print. > > It isn't that much effort, isn't it? 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). > Plus we need to take into account the future mistakes that it might > prevent, too. So even if there were zero problems found so far, it is > still a positive change. Well, the question I was asking is if it's worth the cost which I've tried to outline above. > I would agree if these changes were high risk, though; but they are > almost trivial. 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. James ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
Hi James. > > > 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...@mail.gmail.com/ > > > Well, it's a problem in an error leg, sure, but it's not a really > compelling reason for a 141 patch series, is it? All that fixing this > error will do is get the driver to print "oh dear there's a problem" > under four more conditions than it previously did. You are asking the wrong question here. Yuo should ask how many hours could have been saved by all the bugs people have been fighting with and then fixed *before* the code hit the kernel at all. My personal experience is that I, more than once, have had errors related to a missing break in my code. So this warnings is IMO a win. And if we are only ~100 patches to have it globally enabled then it is a no-brainer in my book. Sam ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
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/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
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 ... James ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
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. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] MAINTAINERS tag for cleanup robot
On Sun, 2020-11-22 at 08:49 -0800, James Bottomley wrote: > We can enforce sysfs_emit going forwards > using tools like checkpatch It's not really possible for checkpatch to find or warn about sysfs uses of sprintf. checkpatch is really just a trivial line-by-line parser and it has no concept of code intent. It just can't warn on every use of the sprintf family. There are just too many perfectly valid uses. > but there's no benefit and a lot of harm to > be done by trying to churn the entire tree Single uses of sprintf for sysfs is not really any problem. But likely there are still several possible overrun sprintf/snprintf paths in sysfs. Some of them are very obscure and unlikely to be found by a robot as the logic for sysfs buf uses can be fairly twisty. But provably correct conversions IMO _should_ be done and IMO churn considerations should generally have less importance. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] MAINTAINERS tag for cleanup robot
On Sun, 2020-11-22 at 08:33 -0800, Tom Rix wrote: > On 11/21/20 9:10 AM, Joe Perches wrote: > > On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote: > > > A difficult part of automating commits is composing the subsystem > > > preamble in the commit log. For the ongoing effort of a fixer producing > > > one or two fixes a release the use of 'treewide:' does not seem > > > appropriate. > > > > > > It would be better if the normal prefix was used. Unfortunately normal is > > > not consistent across the tree. > > > > > > So I am looking for comments for adding a new tag to the MAINTAINERS file > > > > > > D: Commit subsystem prefix > > > > > > ex/ for FPGA DFL DRIVERS > > > > > > D: fpga: dfl: > > I'm all for it. Good luck with the effort. It's not completely trivial. > > > > From a decade ago: > > > > https://lore.kernel.org/lkml/1289919077.28741.50.camel@Joe-Laptop/ > > > > (and that thread started with extra semicolon patches too) > > Reading the history, how about this. > > get_maintainer.pl outputs a single prefix, if multiple files have the > same prefix it works, if they don't its an error. > > Another script 'commit_one_file.sh' does the call to get_mainainter.pl > to get the prefix and be called by run-clang-tools.py to get the fixer > specific message. It's not whether the script used is get_maintainer or any other script, the question is really if the MAINTAINERS file is the appropriate place to store per-subsystem patch specific prefixes. It is. Then the question should be how are the forms described and what is the inheritance priority. My preference would be to have a default of inherit the parent base and add basename(subsystem dirname). Commit history seems to have standardized on using colons as the separator between the commit prefix and the subject. A good mechanism to explore how various subsystems have uses prefixes in the past might be something like: $ git log --no-merges --pretty='%s' - | \ perl -n -e 'print substr($_, 0, rindex($_, ":") + 1) . "\n";' | \ sort | uniq -c | sort -rn Using 1 for commit_count and drivers/scsi for subsystem_path, the top 40 entries are below: About 1% don't have a colon, and there is no real consistency even within individual drivers below scsi. For instance, qla2xxx: 1 814 scsi: qla2xxx: 2 691 scsi: lpfc: 3 389 scsi: hisi_sas: 4 354 scsi: ufs: 5 339 scsi: 6 291 qla2xxx: 7 256 scsi: megaraid_sas: 8 249 scsi: mpt3sas: 9 200 hpsa: 10 190 scsi: aacraid: 11 174 lpfc: 12 153 scsi: qedf: 13 144 scsi: smartpqi: 14 139 scsi: cxlflash: 15 122 scsi: core: 16 110 [SCSI] qla2xxx: 17 108 ncr5380: 18 98 scsi: hpsa: 19 97 20 89 treewide: 21 88 mpt3sas: 22 86 scsi: libfc: 23 85 scsi: qedi: 24 84 scsi: be2iscsi: 25 81 [SCSI] qla4xxx: 26 81 hisi_sas: 27 81 block: 28 75 megaraid_sas: 29 71 scsi: sd: 30 69 [SCSI] hpsa: 31 68 cxlflash: 32 65 scsi: libsas: 33 65 scsi: fnic: 34 61 scsi: scsi_debug: 35 60 scsi: arcmsr: 36 57 be2iscsi: 37 53 atp870u: 38 51 scsi: bfa: 39 50 scsi: storvsc: 40 48 sd: ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
On Sun, 2020-11-22 at 08:17 -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...@mail.gmail.com/ Well, it's a problem in an error leg, sure, but it's not a really compelling reason for a 141 patch series, is it? All that fixing this error will do is get the driver to print "oh dear there's a problem" under four more conditions than it previously did. We've been at this for three years now with nearly a thousand patches, firstly marking all the fall throughs with /* fall through */ and later changing it to fallthrough. At some point we do have to ask if the effort is commensurate with the protection afforded. Please tell me our reward for all this effort isn't a single missing error print. James ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] MAINTAINERS tag for cleanup robot
On Sun, 2020-11-22 at 08:10 -0800, Tom Rix wrote: > On 11/22/20 6:56 AM, Matthew Wilcox wrote: > > On Sun, Nov 22, 2020 at 06:46:46AM -0800, Tom Rix wrote: > > > On 11/21/20 7:23 PM, Matthew Wilcox wrote: > > > > On Sat, Nov 21, 2020 at 08:50:58AM -0800, t...@redhat.com > > > > wrote: > > > > > The fixer review is > > > > > https://reviews.llvm.org/D91789 > > > > > > > > > > A run over allyesconfig for x86_64 finds 62 issues, 5 are > > > > > false positives. The false positives are caused by macros > > > > > passed to other macros and by some macro expansions that did > > > > > not have an extra semicolon. > > > > > > > > > > This cleans up about 1,000 of the current 10,000 -Wextra- > > > > > semi-stmt warnings in linux-next. > > > > Are any of them not false-positives? It's all very well to > > > > enable stricter warnings, but if they don't fix any bugs, > > > > they're just churn. > > > > > > > While enabling additional warnings may be a side effect of this > > > effort > > > > > > the primary goal is to set up a cleaning robot. After that a > > > refactoring robot. > > Why do we need such a thing? Again, it sounds like more churn. > > It's really annoying when I'm working on something important that > > gets derailed by pointless churn. Churn also makes it harder to > > backport patches to earlier kernels. > > > A refactoring example on moving to treewide, consistent use of a new > api may help. > > Consider > > 2efc459d06f1630001e3984854848a5647086232 > > sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs output > > A new api for printing in the sysfs. How do we use it treewide ? > > Done manually, it would be a heroic effort requiring high level > maintainers pushing and likely only get partially done. > > If a refactoring programatic fixit is done and validated on a one > subsystem, it can run on all the subsystems. > > The effort is a couple of weeks to write and validate the fixer, > hours to run over the tree. > > It won't be perfect but will be better than doing it manually. Here's a thought: perhaps we don't. sysfs_emit isn't a "new api" its a minor rewrap of existing best practice. The damage caused by the churn of forcing its use everywhere would far outweigh any actual benefit because pretty much every bug in this area has already been caught and killed by existing tools. We can enforce sysfs_emit going forwards using tools like checkpatch but there's no benefit and a lot of harm to be done by trying to churn the entire tree retrofitting it (both in terms of review time wasted as well as patch series derailed). James ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] MAINTAINERS tag for cleanup robot
On 11/21/20 9:10 AM, Joe Perches wrote: > On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote: >> A difficult part of automating commits is composing the subsystem >> preamble in the commit log. For the ongoing effort of a fixer producing >> one or two fixes a release the use of 'treewide:' does not seem appropriate. >> >> It would be better if the normal prefix was used. Unfortunately normal is >> not consistent across the tree. >> >> So I am looking for comments for adding a new tag to the MAINTAINERS file >> >> D: Commit subsystem prefix >> >> ex/ for FPGA DFL DRIVERS >> >> D: fpga: dfl: > I'm all for it. Good luck with the effort. It's not completely trivial. > > From a decade ago: > > https://lore.kernel.org/lkml/1289919077.28741.50.camel@Joe-Laptop/ > > (and that thread started with extra semicolon patches too) Reading the history, how about this. get_mataintainer.pl outputs a single prefix, if multiple files have the same prefix it works, if they don't its an error. Another script 'commit_one_file.sh' does the call to get_mainainter.pl to get the prefix and be called by run-clang-tools.py to get the fixer specific message. Defer minimizing the commits by combining similar subsystems till later. In a steady state case, this should be uncommon. > >> Continuing with cleaning up clang's -Wextra-semi-stmt >> diff --git a/Makefile b/Makefile > [] >> @@ -1567,20 +1567,21 @@ help: >> echo '' >> @echo 'Static analysers:' >> @echo ' checkstack - Generate a list of stack hogs' >> @echo ' versioncheck- Sanity check on version.h usage' >> @echo ' includecheck- Check for duplicate included header files' >> @echo ' export_report - List the usages of all exported symbols' >> @echo ' headerdep - Detect inclusion cycles in headers' >> @echo ' coccicheck - Check with Coccinelle' >> @echo ' clang-analyzer - Check with clang static analyzer' >> @echo ' clang-tidy - Check with clang-tidy' >> +@echo ' clang-tidy-fix - Check and fix with clang-tidy' > A pity the ordering of the code below isn't the same as the above. Taken care thanks! Tom ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
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...@mail.gmail.com/ -- Kees Cook ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] MAINTAINERS tag for cleanup robot
On 11/22/20 6:56 AM, Matthew Wilcox wrote: > On Sun, Nov 22, 2020 at 06:46:46AM -0800, Tom Rix wrote: >> On 11/21/20 7:23 PM, Matthew Wilcox wrote: >>> On Sat, Nov 21, 2020 at 08:50:58AM -0800, t...@redhat.com wrote: The fixer review is https://reviews.llvm.org/D91789 A run over allyesconfig for x86_64 finds 62 issues, 5 are false positives. The false positives are caused by macros passed to other macros and by some macro expansions that did not have an extra semicolon. This cleans up about 1,000 of the current 10,000 -Wextra-semi-stmt warnings in linux-next. >>> Are any of them not false-positives? It's all very well to enable >>> stricter warnings, but if they don't fix any bugs, they're just churn. >>> >> While enabling additional warnings may be a side effect of this effort >> >> the primary goal is to set up a cleaning robot. After that a refactoring >> robot. > Why do we need such a thing? Again, it sounds like more churn. > It's really annoying when I'm working on something important that gets > derailed by pointless churn. Churn also makes it harder to backport > patches to earlier kernels. > A refactoring example on moving to treewide, consistent use of a new api may help. Consider 2efc459d06f1630001e3984854848a5647086232 sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs output A new api for printing in the sysfs. How do we use it treewide ? Done manually, it would be a heroic effort requiring high level maintainers pushing and likely only get partially done. If a refactoring programatic fixit is done and validated on a one subsystem, it can run on all the subsystems. The effort is a couple of weeks to write and validate the fixer, hours to run over the tree. It won't be perfect but will be better than doing it manually. Tom ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] MAINTAINERS tag for cleanup robot
On Sun, Nov 22, 2020 at 06:46:46AM -0800, Tom Rix wrote: > > On 11/21/20 7:23 PM, Matthew Wilcox wrote: > > On Sat, Nov 21, 2020 at 08:50:58AM -0800, t...@redhat.com wrote: > >> The fixer review is > >> https://reviews.llvm.org/D91789 > >> > >> A run over allyesconfig for x86_64 finds 62 issues, 5 are false positives. > >> The false positives are caused by macros passed to other macros and by > >> some macro expansions that did not have an extra semicolon. > >> > >> This cleans up about 1,000 of the current 10,000 -Wextra-semi-stmt > >> warnings in linux-next. > > Are any of them not false-positives? It's all very well to enable > > stricter warnings, but if they don't fix any bugs, they're just churn. > > > While enabling additional warnings may be a side effect of this effort > > the primary goal is to set up a cleaning robot. After that a refactoring > robot. Why do we need such a thing? Again, it sounds like more churn. It's really annoying when I'm working on something important that gets derailed by pointless churn. Churn also makes it harder to backport patches to earlier kernels. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] MAINTAINERS tag for cleanup robot
On 11/21/20 7:23 PM, Matthew Wilcox wrote: > On Sat, Nov 21, 2020 at 08:50:58AM -0800, t...@redhat.com wrote: >> The fixer review is >> https://reviews.llvm.org/D91789 >> >> A run over allyesconfig for x86_64 finds 62 issues, 5 are false positives. >> The false positives are caused by macros passed to other macros and by >> some macro expansions that did not have an extra semicolon. >> >> This cleans up about 1,000 of the current 10,000 -Wextra-semi-stmt >> warnings in linux-next. > Are any of them not false-positives? It's all very well to enable > stricter warnings, but if they don't fix any bugs, they're just churn. > While enabling additional warnings may be a side effect of this effort the primary goal is to set up a cleaning robot. After that a refactoring robot. Tom ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
