| Message ID | 20201121165058.1644182-1-trix@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC] MAINTAINERS tag for cleanup robot | expand |
On Sat, Nov 21, 2020 at 08:50:58AM -0800, trix@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.
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, trix@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.
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, trix@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
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, trix@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' -<commit_count> <subsystem_path> | \ perl -n -e 'print substr($_, 0, rindex($_, ":") + 1) . "\n";' | \ sort | uniq -c | sort -rn Using 10000 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:
diff --git a/Makefile b/Makefile index 47a8add4dd28..57756dbb767b 100644 --- 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' @echo '' @echo 'Tools:' @echo ' nsdeps - Generate missing symbol namespace dependencies' @echo '' @echo 'Kernel selftest:' @echo ' kselftest - Build and run kernel selftest' @echo ' Build, install, and boot kernel before' @echo ' running kselftest on it' @echo ' Run as root for full coverage' @echo ' kselftest-all - Build kernel selftest' @@ -1842,30 +1843,30 @@ nsdeps: modules quiet_cmd_gen_compile_commands = GEN $@ cmd_gen_compile_commands = $(PYTHON3) $< -a $(AR) -o $@ $(filter-out $<, $(real-prereqs)) $(extmod-prefix)compile_commands.json: scripts/clang-tools/gen_compile_commands.py \ $(if $(KBUILD_EXTMOD),,$(KBUILD_VMLINUX_OBJS) $(KBUILD_VMLINUX_LIBS)) \ $(if $(CONFIG_MODULES), $(MODORDER)) FORCE $(call if_changed,gen_compile_commands) targets += $(extmod-prefix)compile_commands.json -PHONY += clang-tidy clang-analyzer +PHONY += clang-tidy-fix clang-tidy clang-analyzer ifdef CONFIG_CC_IS_CLANG quiet_cmd_clang_tools = CHECK $< cmd_clang_tools = $(PYTHON3) $(srctree)/scripts/clang-tools/run-clang-tools.py $@ $< -clang-tidy clang-analyzer: $(extmod-prefix)compile_commands.json +clang-tidy-fix clang-tidy clang-analyzer: $(extmod-prefix)compile_commands.json $(call cmd,clang_tools) else -clang-tidy clang-analyzer: +clang-tidy-fix clang-tidy clang-analyzer: @echo "$@ requires CC=clang" >&2 @false endif # Scripts to check various things for consistency # --------------------------------------------------------------------------- PHONY += includecheck versioncheck coccicheck export_report includecheck: diff --git a/scripts/clang-tools/run-clang-tools.py b/scripts/clang-tools/run-clang-tools.py index fa7655c7cec0..c177ca822c56 100755 --- a/scripts/clang-tools/run-clang-tools.py +++ b/scripts/clang-tools/run-clang-tools.py @@ -22,43 +22,57 @@ def parse_arguments(): Returns: args: Dict of parsed args Has keys: [path, type] """ usage = """Run clang-tidy or the clang static-analyzer on a compilation database.""" parser = argparse.ArgumentParser(description=usage) type_help = "Type of analysis to be performed" parser.add_argument("type", - choices=["clang-tidy", "clang-analyzer"], + choices=["clang-tidy-fix", "clang-tidy", "clang-analyzer"], help=type_help) path_help = "Path to the compilation database to parse" parser.add_argument("path", type=str, help=path_help) return parser.parse_args() def init(l, a): global lock global args lock = l args = a def run_analysis(entry): # Disable all checks, then re-enable the ones we want checks = "-checks=-*," - if args.type == "clang-tidy": + fix = "" + header_filter = "" + if args.type == "clang-tidy-fix": + checks += "linuxkernel-macro-trailing-semi" + # + # Fix this + # #define M(a) a++; <-- clang-tidy fixes the problem here + # int f() { + # int v = 0; + # M(v); <-- clang reports problem here + # return v; + # } + fix += "-fix" + header_filter += "-header-filter=.*" + elif args.type == "clang-tidy": checks += "linuxkernel-*" else: checks += "clang-analyzer-*" - p = subprocess.run(["clang-tidy", "-p", args.path, checks, entry["file"]], + p = subprocess.run(["clang-tidy", "-p", args.path, checks, header_filter, fix, entry["file"]], stdout=subprocess.PIPE, stderr=subprocess.STDOUT, cwd=entry["directory"]) with lock: sys.stderr.buffer.write(p.stdout) def main(): args = parse_arguments()
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: Continuing with cleaning up clang's -Wextra-semi-stmt A significant number of warnings are caused by function like macros with a trailing semicolon. For example. #define FOO(a) a++; <-- extra, unneeded semicolon void bar() { int v = 0; FOO(a); } Clang will warn at the FOO(a); expansion location. Instead of removing the semicolon there, the fixer removes semicolon from the macro definition. After the fixer, the code will be: #define FOO(a) a++ void bar() { int v = 0; FOO(a); } 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. An update to [RFC] clang tooling cleanup This change adds the clang-tidy-fix as a top level target and uses it to do the cleaning. The next iteration will do a loop of cleaners. This will mean breaking clang-tidy-fix out into its own processing function 'run_fixers'. Makefile: Add toplevel target clang-tidy-fix to makefile Calls clang-tidy with -fix option for a set of checkers that programatically fixes the kernel source in place, treewide. Signed-off-by: Tom Rix <trix@redhat.com> --- Makefile | 7 ++++--- scripts/clang-tools/run-clang-tools.py | 20 +++++++++++++++++--- 2 files changed, 21 insertions(+), 6 deletions(-)