aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-12-15lib/ubsan.c: mark type_check_kinds with static keywordZou Wei1-1/+1
Fix the following sparse warning: lib/ubsan.c:20:12: warning: symbol 'type_check_kinds' was not declared. Should it be static? [[email protected]: make it `static const char * const' while we're in there] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Zou Wei <[email protected]> Reviewed-by: Andrew Morton <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15kcov: don't instrument with UBSANDmitry Vyukov1-0/+3
Both KCOV and UBSAN use compiler instrumentation. If UBSAN detects a bug in KCOV, it may cause infinite recursion via printk and other common functions. We already don't instrument KCOV with KASAN/KCSAN for this reason, don't instrument it with UBSAN as well. As a side effect this also resolves the following gcc warning: conflicting types for built-in function '__sanitizer_cov_trace_switch'; expected 'void(long unsigned int, void *)' [-Wbuiltin-declaration-mismatch] It's only reported when kcov.c is compiled with any of the sanitizers enabled. Size of the arguments is correct, it's just that gcc uses 'long' on 64-bit arches and 'long long' on 32-bit arches, while kernel type is always 'long long'. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Dmitry Vyukov <[email protected]> Reported-by: Stephen Rothwell <[email protected]> Suggested-by: Marco Elver <[email protected]> Acked-by: Marco Elver <[email protected]> Reviewed-by: Andrey Konovalov <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15ubsan: expand tests and reportingKees Cook1-8/+66
Expand the UBSAN tests to include some additional UB cases. Notably the out-of-bounds enum loading appears not to work. Also include per-test reporting, including the relevant CONFIG_UBSAN... Kconfigs. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: George Popescu <[email protected]> Cc: Herbert Xu <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Marco Elver <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Michal Marek <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Peter Oberparleiter <[email protected]> Cc: Randy Dunlap <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15ubsan: remove UBSAN_MISC in favor of individual optionsKees Cook2-26/+57
Make each UBSAN option individually selectable and remove UBSAN_MISC which no longer has any purpose. Add help text for each Kconfig, and include a reference to the Clang sanitizer documentation. Disable unsigned overflow by default (not available with GCC and makes x86 unbootable with Clang). Disable unreachable when objtool is in use (redundant and confuses things: instrumentation appears at unreachable locations). Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: George Popescu <[email protected]> Cc: Herbert Xu <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Marco Elver <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Michal Marek <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Peter Oberparleiter <[email protected]> Cc: Randy Dunlap <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15ubsan: enable for all*config buildsKees Cook2-2/+5
With UBSAN_OBJECT_SIZE disabled for GCC, only UBSAN_ALIGNMENT remained a noisy UBSAN option. Disable it for COMPILE_TEST so the rest of UBSAN can be used for full all*config builds or other large combinations. [[email protected]: add .data..Lubsan_data*/.data..Lubsan_type* sections explicitly] Link: https://lkml.kernel.org/r/[email protected] Link: https://lore.kernel.org/lkml/CAHk-=wgXW=YLxGN0QVpp-1w5GDd2pf1W-FqY15poKzoVfik2qA@mail.gmail.com/ Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: George Popescu <[email protected]> Cc: Herbert Xu <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Marco Elver <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Michal Marek <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Peter Oberparleiter <[email protected]> Cc: Randy Dunlap <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15ubsan: disable UBSAN_TRAP for all*configKees Cook1-0/+1
Doing all*config builds attempts to build as much as possible. UBSAN_TRAP effectively short-circuits lib/usban.c, so it should be disabled for COMPILE_TEST so that the lib/ubsan.c code gets built. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: George Popescu <[email protected]> Cc: Herbert Xu <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Marco Elver <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Michal Marek <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Peter Oberparleiter <[email protected]> Cc: Randy Dunlap <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15ubsan: disable object-size sanitizer under GCCKees Cook1-0/+3
GCC's -fsanitize=object-size (as part of CONFIG_UBSAN_MISC) greatly increases stack utilization. Do not allow this under GCC. Link: https://lkml.kernel.org/r/[email protected] Link: https://lore.kernel.org/lkml/CAHk-=wjPasyJrDuwDnpHJS2TuQfExwe=px-SzLeN8GFMAQJPmQ@mail.gmail.com/ Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Suggested-by: Linus Torvalds <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: George Popescu <[email protected]> Cc: Herbert Xu <[email protected]> Cc: Marco Elver <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Michal Marek <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Peter Oberparleiter <[email protected]> Cc: Randy Dunlap <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15ubsan: move cc-option tests into KconfigKees Cook2-33/+73
Instead of doing if/endif blocks with cc-option calls in the UBSAN Makefile, move all the tests into Kconfig and use the Makefile to collect the results. Link: https://lkml.kernel.org/r/[email protected] Link: https://lore.kernel.org/lkml/CAHk-=wjPasyJrDuwDnpHJS2TuQfExwe=px-SzLeN8GFMAQJPmQ@mail.gmail.com/ Signed-off-by: Kees Cook <[email protected]> Suggested-by: Linus Torvalds <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: George Popescu <[email protected]> Cc: Herbert Xu <[email protected]> Cc: Marco Elver <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Michal Marek <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Peter Oberparleiter <[email protected]> Cc: Randy Dunlap <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15ubsan: remove redundant -Wno-maybe-uninitializedKees Cook2-8/+0
Patch series "Clean up UBSAN Makefile", v2. This series attempts to address the issues seen with UBSAN's object-size sanitizer causing problems under GCC. In the process, the Kconfig and Makefile are refactored to do all the cc-option calls in the Kconfig. Additionally start to detangle -Wno-maybe-uninitialized, disable UBSAN_TRAP under COMPILE_TEST for wider build coverage, and expand the libusan tests. This patch (of 7): In commit 78a5255ffb6a ("Stop the ad-hoc games with -Wno-maybe-initialized") -Wmaybe-uninitialized was disabled globally, so keeping the disabling logic here too doesn't make sense. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Michal Marek <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Marco Elver <[email protected]> Cc: Randy Dunlap <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: George Popescu <[email protected]> Cc: Herbert Xu <[email protected]> Cc: Peter Oberparleiter <[email protected]> Cc: Andrey Ryabinin <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15kernel/resource.c: fix kernel-doc markupsMauro Carvalho Chehab1-10/+14
Kernel-doc markups should use this format: identifier - description While here, fix a kernel-doc tag that was using, instead, a normal comment block. [[email protected]: coding style fixes] Link: https://lkml.kernel.org/r/c5e38e1070f8dbe2f9607a10b44afe2875bd966c.1605521731.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab <[email protected]> Cc: "Jonathan Corbet" <[email protected]> Cc: Matthew Wilcox <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15blktrace: make relay callbacks constJani Nikula1-1/+1
Now that relay_open() accepts const callbacks, make relay callbacks const. Link: https://lkml.kernel.org/r/7ff5ce0b735901eb4f10e13da2704f1d8c4a2507.1606153547.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Kalle Valo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15ath9k: make relay callbacks constJani Nikula1-1/+1
Now that relay_open() accepts const callbacks, make relay callbacks const. Link: https://lkml.kernel.org/r/7db0286c428f3a478dd7544afef04a3b131f1aa0.1606153547.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]> Acked-by: Kalle Valo <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Cc: Jens Axboe <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15ath11k: make relay callbacks constJani Nikula1-1/+1
Now that relay_open() accepts const callbacks, make relay callbacks const. Link: https://lkml.kernel.org/r/44e3d65b71025c462948d0c554061dc7b40ab488.1606153547.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]> Acked-by: Kalle Valo <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Cc: Jens Axboe <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15ath10k: make relay callbacks constJani Nikula1-1/+1
Now that relay_open() accepts const callbacks, make relay callbacks const. Link: https://lkml.kernel.org/r/85cabc6d4b0d0ca43d4e0fb94897ccd16e3b7930.1606153547.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]> Acked-by: Kalle Valo <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Cc: Jens Axboe <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15drm/i915: make relay callbacks constJani Nikula1-1/+1
Now that relay_open() accepts const callbacks, make relay callbacks const. Link: https://lkml.kernel.org/r/534d089f413db98aa0b94773fa49d5275d0d3c25.1606153547.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Kalle Valo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15relay: allow the use of const callback structsJani Nikula2-29/+12
None of the relay users require the use of mutable structs for callbacks, however the relay code does. Instead of assigning the default callback for subbuf_start, add a wrapper to conditionally call the client callback if available, and fall back to default behaviour otherwise. This lets all relay users make their struct rchan_callbacks const data. [[email protected]: cleanups, per Christoph] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/cc3ff292e4eb4fdc56bee3d690c7b8e39209cd37.1606153547.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Kalle Valo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15relay: make create_buf_file and remove_buf_file callbacks mandatoryJani Nikula2-25/+7
All clients provide create_buf_file and remove_buf_file callbacks, and they're required for relay to make sense. There is no point in them being optional. Also document whether each callback is mandatory/optional. Link: https://lkml.kernel.org/r/88003c1527386b93036e286e7917f1e33aec84ac.1606153547.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]> Suggested-by: Christoph Hellwig <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Kalle Valo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15relay: require non-NULL callbacks in relay_open()Jani Nikula1-12/+2
There are no clients passing NULL callbacks, which makes sense as it wouldn't even create a file. Require non-NULL callbacks, and throw away the handling for NULL callbacks. Link: https://lkml.kernel.org/r/e40642f3b027d2bb6bc851ddb60e0a61ea51f5f8.1606153547.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]> Suggested-by: Christoph Hellwig <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Kalle Valo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15relay: remove unused buf_mapped and buf_unmapped callbacksJani Nikula2-53/+0
Patch series "relay: cleanup and const callbacks", v2. None of the relay users require the use of mutable structs for callbacks, however the relay code does. Instead of assigning default callbacks when there is none, add callback wrappers to conditionally call the client callbacks if available, and fall back to default behaviour (typically no-op) otherwise. This lets all relay users make their struct rchan_callbacks const data. This series starts with a number of cleanups first based on Christoph's feedback. This patch (of 9): No relay client uses the buf_mapped or buf_unmapped callbacks. Remove them. This makes relay's vm_operations_struct close callback a dummy, remove it as well. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/c69fff6e0cd485563604240bbfcc028434983bec.1606153547.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]> Suggested-by: Christoph Hellwig <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Kalle Valo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15bfs: don't use WARNING: string when it's just info.Randy Dunlap1-1/+1
Make the printk() [bfs "printf" macro] seem less severe by changing "WARNING:" to "NOTE:". <asm-generic/bug.h> warns us about using WARNING or BUG in a format string other than in WARN() or BUG() family macros. bfs/inode.c is doing just that in a normal printk() call, so change the "WARNING" string to be "NOTE". Link: https://lkml.kernel.org/r/[email protected] Reported-by: [email protected] Signed-off-by: Randy Dunlap <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: Al Viro <[email protected]> Cc: "Tigran A. Aivazian" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15gcov: fix kernel-doc markup issueAlex Shi1-3/+3
Fix the following kernel-doc issue in gcov: kernel/gcov/gcc_4_7.c:238: warning: Function parameter or member 'dst' not described in 'gcov_info_add' kernel/gcov/gcc_4_7.c:238: warning: Function parameter or member 'src' not described in 'gcov_info_add' kernel/gcov/gcc_4_7.c:238: warning: Excess function parameter 'dest' description in 'gcov_info_add' kernel/gcov/gcc_4_7.c:238: warning: Excess function parameter 'source' description in 'gcov_info_add' Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Alex Shi <[email protected]> Acked-by: Peter Oberparleiter <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15gcov: remove support for GCC < 4.9Nick Desaulniers1-3/+1
Since commit 0bddd227f3dc ("Documentation: update for gcc 4.9 requirement") the minimum supported version of GCC is gcc-4.9. It's now safe to remove this code. Similar to commit 10415533a906 ("gcov: Remove old GCC 3.4 support") but that was for GCC 4.8 and this is for GCC 4.9. Link: https://github.com/ClangBuiltLinux/linux/issues/427 Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Nick Desaulniers <[email protected]> Reviewed-by: Peter Oberparleiter <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15rapidio: remove unused rio_get_asm() and rio_get_device()Sebastian Andrzej Siewior2-84/+0
The functions rio_get_asm() and rio_get_device() are globally exported but have almost no users in tree. The only user is rio_init_mports() which invokes it via rio_init(). rio_init() iterates over every registered device and invokes rio_fixup_device(). It looks like a fixup function which should perform a "change" to the device but does nothing. It has been like this since its introduction in commit 394b701ce4fbf ("[PATCH] RapidIO support: core base") which was merged into v2.6.15-rc1. Remove rio_init() because the performed fixup function (rio_fixup_device()) does nothing. Remove rio_get_asm() and rio_get_device() which have no callers now. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Cc: Matt Porter <[email protected]> Cc: Alexandre Bounine <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15kdump: append uts_namespace.name offset to VMCOREINFOAlexander Egorenkov2-0/+7
The offset of the field 'init_uts_ns.name' has changed since commit 9a56493f6942 ("uts: Use generic ns_common::count"). Make the offset of the field 'uts_namespace.name' available in VMCOREINFO because tools like 'crash-utility' and 'makedumpfile' must be able to read it from crash dumps. Link: https://lore.kernel.org/r/159644978167.604812.1773586504374412107.stgit@localhost.localdomain Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Alexander Egorenkov <[email protected]> Acked-by: lijiang <[email protected]> Acked-by: Baoquan He <[email protected]> Cc: Dave Young <[email protected]> Cc: Vivek Goyal <[email protected]> Cc: "Eric W . Biederman" <[email protected]> Cc: Kirill Tkhai <[email protected]> Cc: Kees Cook <[email protected]> Cc: Christian Brauner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15fs/nilfs2: remove some unused macros to tame gccAlex Shi1-5/+0
There some macros are unused and cause gcc warning. Remove them. fs/nilfs2/segment.c:137:0: warning: macro "nilfs_cnt32_gt" is not used [-Wunused-macros] fs/nilfs2/segment.c:144:0: warning: macro "nilfs_cnt32_le" is not used [-Wunused-macros] fs/nilfs2/segment.c:143:0: warning: macro "nilfs_cnt32_lt" is not used [-Wunused-macros] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ryusuke Konishi <[email protected]> Signed-off-by: Alex Shi <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15checkpatch: add printk_once and printk_ratelimit to prefer pr_<level> warningJoe Perches1-3/+10
Add the _once and _ratelimited variants to the test for printk(KERN_<LEVEL> that should prefer pr_<level>. Miscellanea: o Add comment description for the conversions [[email protected]: fixlet] Link: https://lkml.kernel.org/r/[email protected]: https://lkml.kernel.org/r/[email protected] Signed-off-by: Joe Perches <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15checkpatch: fix TYPO_SPELLING check for words with apostropheDwaipayan Ray1-2/+5
checkpatch reports a false TYPO_SPELLING warning for some words containing an apostrophe when run with --codespell option. A false positive is "doesn't". Occurrence of the word causes checkpatch to emit the following warning: "WARNING: 'doesn'' may be misspelled - perhaps 'doesn't'?" Modify the regex pattern to be more in line with the codespell default word matching regex. This fixes the word capture and avoids the false warning. In addition, highlight the misspelled word location by adding a caret below the word. [[email protected]: make matched misspelling more obvious, per Joe] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Dwaipayan Ray <[email protected]> Suggested-by: Joe Perches <[email protected]> Reported-by: Peilin Ye <[email protected]> Acked-by: Joe Perches <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15checkpatch: add warning for lines starting with a '#' in commit logDwaipayan Ray1-0/+9
Commit log lines starting with '#' are dropped by git as comments. Add a check to emit a warning for these lines. Also add a --fix option to insert a space before the leading '#' in such lines. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Dwaipayan Ray <[email protected]> Suggested-by: Joe Perches <[email protected]> Suggested-by: Peilin Ye <[email protected]> Tested-by: Peilin Ye <[email protected]> Acked-by: Joe Perches <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15checkpatch: add warning for unnecessary use of %h[xudi] and %hh[xudi]Dwaipayan Ray1-0/+22
Modifiers %h and %hh should never be used. Commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use of unnecessary %h[xudi] and %hh[xudi]") specifies that: "Standard integer promotion is already done and %hx and %hhx is useless so do not encourage the use of %hh[xudi] or %h[xudi]." "The "h" and "hh" things should never be used. The only reason for them being used if you have an "int", but you want to print it out as a "char" (and honestly, that is a really bad reason, you'd be better off just using a proper cast to make the code more obvious)." Add a new check to emit a warning on finding an unneeded use of %h or %hh modifier. Also add a fix option to the check. Link: https://lore.kernel.org/lkml/[email protected]/ Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Dwaipayan Ray <[email protected]> Suggested-by: Joe Perches <[email protected]> Suggested-by: Lukas Bulwahn <[email protected]> Acked-by: Joe Perches <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15checkpatch: add fix and improve warning msg for non-standard signatureAditya Srivastava1-2/+69
Currently checkpatch warns for BAD_SIGN_OFF on non-standard signature styles. A large number of these warnings occur because of typo mistakes in signature tags. An evaluation over v4.13..v5.8 showed that out of 539 warnings due to non-standard signatures, 87 are due to typo mistakes. Following are the standard signature tags which are often incorrectly used, along with their individual counts of incorrect use (over v4.13..v5.8): Reviewed-by: 42 Signed-off-by: 25 Reported-by: 6 Acked-by: 4 Tested-by: 4 Suggested-by: 4 Provide a fix by calculating levenshtein distance for the signature tag with all the standard signatures and suggest a fix with a signature, whose edit distance is less than or equal to 2 with the misspelled signature. Out of the 86 mispelled signatures fixed with this approach, 85 were found to be good corrections and 1 was bad correction. Following was found to be a bad correction: Tweeted-by (count: 1) => Tested-by Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Aditya Srivastava <[email protected]> Acked-by: Joe Perches <[email protected]> Cc: Lukas Bulwahn <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15checkpatch: add fix option for LOGICAL_CONTINUATIONSAditya Srivastava1-2/+10
Currently, checkpatch warns if logical continuations are placed at the start of a line and not at the end of previous line. E.g., running checkpatch on commit 3485507fc272 ("staging: bcm2835-camera: Reduce length of enum names") reports: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the previous line + if (!ret + && camera_port == Provide a simple fix by inserting logical operator at the last non-comment, non-whitespace char of the previous line and removing from current line, if both the lines are additions(ie start with '+') Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Aditya Srivastava <[email protected]> Acked-by: Joe Perches <[email protected]> Cc: Lukas Bulwahn <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15checkpatch: add fix option for ASSIGNMENT_CONTINUATIONSAditya Srivastava1-2/+8
Currently, checkpatch warns us if an assignment operator is placed at the start of a line and not at the end of previous line. E.g., running checkpatch on commit 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug") reports: CHECK: Assignment operator '=' should be on the previous line + struct netvsc_device *nvdev + = container_of(w, struct netvsc_device, subchan_work); Provide a simple fix by appending assignment operator to the previous line and removing from the current line, if both the lines are additions (ie start with '+') Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Aditya Srivastava <[email protected]> Acked-by: Joe Perches <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15checkpatch: fix unescaped left braceDwaipayan Ray1-1/+1
There is an unescaped left brace in a regex in OPEN_BRACE check. This throws a runtime error when checkpatch is run with --fix flag and the OPEN_BRACE check is executed. Fix it by escaping the left brace. Link: https://lkml.kernel.org/r/[email protected] Fixes: 8d1824780f2f ("checkpatch: add --fix option for a couple OPEN_BRACE misuses") Signed-off-by: Dwaipayan Ray <[email protected]> Acked-by: Joe Perches <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15checkpatch: avoid COMMIT_LOG_LONG_LINE warning for signature tagsAditya Srivastava1-2/+2
Currently checkpatch warns us for long lines in commits even for signature tag lines. Generally these lines exceed the 75-character limit because of: 1) long names and long email address 2) some comments on scoped review and acknowledgement, i.e., for a dedicated pointer on what was reported by the identity in 'Reported-by' 3) some additional comments on CC: [email protected] tags Exclude signature tag lines from this class of warning. There were 1896 COMMIT_LOG_LONG_LINE warnings in v5.6..v5.8 before this patch application and 1879 afterwards. A quick manual check found all the dropped warnings related to signature tags. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Aditya Srivastava <[email protected]> Acked-by: Joe Perches <[email protected]> Cc: Lukas Bulwahn <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15checkpatch: fix spelling errors and remove repeated wordDwaipayan Ray1-3/+3
Delete repeated word in scripts/checkpatch.pl: "are are" -> "are" Fix typos: "commments" -> "comments" "falsly" -> "falsely" Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Dwaipayan Ray <[email protected]> Acked-by: Joe Perches <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15checkpatch: improve email parsingDwaipayan Ray1-17/+91
checkpatch doesn't report warnings for many common mistakes in emails. Some of which are trailing commas and incorrect use of email comments. At the same time several false positives are reported due to incorrect handling of mail comments. The most common of which is due to the pattern: <[email protected]> # X.X Improve email parsing in checkpatch. Some general email rules are defined: - Multiple name comments should not be allowed. - Comments inside address should not be allowed. - In general comments should be enclosed within parentheses. Relaxation is given to comments beginning with #. - Stable addresses should not begin with a name. - Comments in stable addresses should begin only with a #. Improvements to parsing: - Detect and report unexpected content after email. - Quoted names are excluded from comment parsing. - Trailing dots, commas or quotes in email are removed during formatting. Correspondingly a BAD_SIGN_OFF warning is emitted. - Improperly quoted email like '"name <address>"' are now warned about. In addition, added fixes for all the possible rules. Link: https://lore.kernel.org/linux-kernel-mentees/[email protected]/ Link: https://lore.kernel.org/linux-kernel-mentees/[email protected]/ Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Dwaipayan Ray <[email protected]> Suggested-by: Joe Perches <[email protected]> Acked-by: Joe Perches <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15checkpatch: add __alias and __weak to suggested __attribute__ conversionsJoe Perches1-1/+3
Add __alias and __weak to the suggested __attribute__((<foo>)) conversions. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Joe Perches <[email protected]> Cc: Dwaipayan Ray <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15checkpatch: add fix option for GERRIT_CHANGE_IDAditya Srivastava1-2/+5
Currently, whenever a Gerrit Change-Id is present in a commit, checkpatch.pl warns to remove the Change-Id before submitting the patch. E.g., running checkpatch on commit adc311a5bbf6 ("iwlwifi: bump FW API to 53 for 22000 series") reports this error: ERROR: Remove Gerrit Change-Id's before submitting upstream Change-Id: I5725e46394f3f53c3069723fd513cc53c7df383d Provide a simple fix option by simply deleting the indicated line. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Aditya Srivastava <[email protected]> Acked-by: Joe Perches <[email protected]> Cc: Lukas Bulwahn <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15checkpatch: update __attribute__((section("name"))) quote removalJoe Perches1-32/+15
commit 33def8498fdd ("treewide: Convert macro and uses of __section(foo) to __section("foo")") removed the stringification of the section name and now requires quotes around the named section. Update checkpatch to not remove any quotes when suggesting conversion of __attribute__((section("name"))) to __section("name") Miscellanea: o Add section to the hash with __section replacement o Remove separate test for __attribute__((section o Remove the limitation on converting attributes containing only known, possible conversions. Any unknown attribute types are now left as-is and known types are converted and moved before __attribute__ and removed from within the __attribute__((list...)). [[email protected]: eliminate the separate test below the possible conversions loop] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Joe Perches <[email protected]> Cc: Dwaipayan Ray <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15checkpatch: add a fixer for missing newline at eofTom Rix1-2/+5
Remove the trailing error message from the fixed lines. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Tom Rix <[email protected]> Acked-by: Joe Perches <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15checkpatch: extend attributes check to handle more patternsDwaipayan Ray1-38/+71
It is generally preferred that the macros from include/linux/compiler_attributes.h are used, unless there is a reason not to. checkpatch currently checks __attribute__ for each of packed, aligned, section, printf, scanf, and weak. Other declarations in compiler_attributes.h are not handled. Add a generic test to check the presence of such attributes. Some attributes require more specific handling and are kept separate. Also add fixes to the generic attributes check to substitute the correct conversions. New attributes which are now handled are: __always_inline__ __assume_aligned__(a, ## __VA_ARGS__) __cold__ __const__ __copy__(symbol) __designated_init__ __externally_visible__ __gnu_inline__ __malloc__ __mode__(x) __no_caller_saved_registers__ __noclone__ __noinline__ __nonstring__ __noreturn__ __pure__ __unused__ __used__ Declarations which contain multiple attributes like __attribute__((__packed__, __cold__)) are also handled except when proper conversions for one or more attributes of the list cannot be determined. Link: https://lore.kernel.org/linux-kernel-mentees/[email protected]/ Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Dwaipayan Ray <[email protected]> Suggested-by: Joe Perches <[email protected]> Acked-by: Joe Perches <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15checkpatch: allow --fix removal of unnecessary break statementsJoe Perches1-4/+8
switch/case use of break after a return, goto or break is unnecessary. There is an existing warning for the return and goto uses, so add break and a --fix option too. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Joe Perches <[email protected]> Cc: Julia Lawall <[email protected]> Cc: Tom Rix <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15checkpatch: prefer static const declarationsJoe Perches1-0/+12
There are about 100,000 uses of 'static const <type>' but about 400 uses of 'static <type> const' in the kernel where type is not a pointer. The kernel almost always uses "static const" over "const static" as there is a compiler warning for that declaration style. But there is no compiler warning for "static <type> const". So add a checkpatch warning for the atypical declaration uses of. const static <type> <foo> and static <type> const <foo> For example: $ ./scripts/checkpatch.pl -f --emacs --quiet --nosummary -types=static_const arch/arm/crypto/aes-ce-glue.c arch/arm/crypto/aes-ce-glue.c:75: WARNING: Move const after static - use 'static const u8' #75: FILE: arch/arm/crypto/aes-ce-glue.c:75: + static u8 const rcon[] = { Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Joe Perches <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15checkpatch: ignore generated CamelCase defines and enum valuesŁukasz Stelmach1-0/+2
Ignore autogenerated CamelCase-like defines and enum values like DRM_MODE_CONNECTOR_Unknown or ETHTOOL_LINK_MODE_Asym_Pause_BIT. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Łukasz Stelmach <[email protected]> Suggested-by: Joe Perches <[email protected]> Acked-by: Joe Perches <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15checkpatch: fix false positives in REPEATED_WORD warningAditya Srivastava1-1/+15
Presence of hexadecimal address or symbol results in false warning message by checkpatch.pl. For example, running checkpatch on commit b8ad540dd4e4 ("mptcp: fix memory leak in mptcp_subflow_create_socket()") results in warning: WARNING:REPEATED_WORD: Possible repeated word: 'ff' 00 00 00 00 00 00 00 00 00 2f 30 0a 81 88 ff ff ........./0..... Similarly, the presence of list command output in commit results in an unnecessary warning. For example, running checkpatch on commit 899e5ffbf246 ("perf record: Introduce --switch-output-event") gives: WARNING:REPEATED_WORD: Possible repeated word: 'root' dr-xr-x---. 12 root root 4096 Apr 27 17:46 .. Here, it reports 'ff' and 'root' to be repeated, but it is in fact part of some address or code, where it has to be repeated. In these cases, the intent of the warning to find stylistic issues in commit messages is not met and the warning is just completely wrong in this case. To avoid these warnings, add an additional regex check for the directory permission pattern and avoid checking the line for this class of warning. Similarly, to avoid hex pattern, check if the word consists of hex symbols and skip this warning if it is not among the common english words formed using hex letters. A quick evaluation on v5.6..v5.8 showed that this fix reduces REPEATED_WORD warnings by the frequency of 1890. A quick manual check found all cases are related to hex output or list command outputs in commit messages. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Aditya Srivastava <[email protected]> Acked-by: Joe Perches <[email protected]> Cc: Dwaipayan Ray <[email protected]> Cc: Lukas Bulwahn <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15checkpatch: add new exception to repeated word checkDwaipayan Ray1-2/+13
Recently, commit 4f6ad8aa1eac ("checkpatch: move repeated word test") moved the repeated word test to check for more file types. But after this, if checkpatch.pl is run on MAINTAINERS, it generates several new warnings of the type: WARNING: Possible repeated word: 'git' For example: WARNING: Possible repeated word: 'git' +T: git git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git So, the pattern "git git://..." is a false positive in this case. There are several other combinations which may produce a wrong warning message, such as "@size size", ":Begin begin", etc. Extend repeated word check to compare the characters before and after the word matches. If there is a non whitespace character before the first word or a non whitespace character excluding punctuation characters after the second word, then the check is skipped and the warning is avoided. Also add case insensitive word matching to the repeated word check. Link: https://lore.kernel.org/linux-kernel-mentees/[email protected]/ Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Dwaipayan Ray <[email protected]> Suggested-by: Joe Perches <[email protected]> Suggested-by: Lukas Bulwahn <[email protected]> Acked-by: Joe Perches <[email protected]> Cc: Aditya Srivastava <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15lib/lz4: explicitly support in-place decompressionGao Xiang2-1/+6
LZ4 final literal copy could be overlapped when doing in-place decompression, so it's unsafe to just use memcpy() on an optimized memcpy approach but memmove() instead. Upstream LZ4 has updated this years ago [1] (and the impact is non-sensible [2] plus only a few bytes remain), this commit just synchronizes LZ4 upstream code to the kernel side as well. It can be observed as EROFS in-place decompression failure on specific files when X86_FEATURE_ERMS is unsupported, memcpy() optimization of commit 59daa706fbec ("x86, mem: Optimize memcpy by avoiding memory false dependece") will be enabled then. Currently most modern x86-CPUs support ERMS, these CPUs just use "rep movsb" approach so no problem at all. However, it can still be verified with forcely disabling ERMS feature... arch/x86/lib/memcpy_64.S: ALTERNATIVE_2 "jmp memcpy_orig", "", X86_FEATURE_REP_GOOD, \ - "jmp memcpy_erms", X86_FEATURE_ERMS + "jmp memcpy_orig", X86_FEATURE_ERMS We didn't observe any strange on arm64/arm/x86 platform before since most memcpy() would behave in an increasing address order ("copy upwards" [3]) and it's the correct order of in-place decompression but it really needs an update to memmove() for sure considering it's an undefined behavior according to the standard and some unique optimization already exists in the kernel. [1] https://github.com/lz4/lz4/commit/33cb8518ac385835cc17be9a770b27b40cd0e15b [2] https://github.com/lz4/lz4/pull/717#issuecomment-497818921 [3] https://sourceware.org/bugzilla/show_bug.cgi?id=12518 Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Gao Xiang <[email protected]> Reviewed-by: Nick Terrell <[email protected]> Cc: Yann Collet <[email protected]> Cc: Miao Xie <[email protected]> Cc: Chao Yu <[email protected]> Cc: Li Guifu <[email protected]> Cc: Guo Xuenan <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15lib: cleanup kstrto*() usageAlexey Dobriyan2-22/+13
Use proper conversion functions. kstrto*() variants exist for all standard types. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Alexey Dobriyan <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15drivers/misc/lkdtm/lkdtm.h: correct wrong filenames in commentFrancis Laniel1-7/+7
In lkdtm.h, files targeted in comments are named "lkdtm_file.c" while there are named "file.c" in directory. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Francis Laniel <[email protected]> Acked-by: Kees Cook <[email protected]> Cc: Daniel Axtens <[email protected]> Cc: Daniel Micay <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-15drivers/misc/lkdtm: add new file in LKDTM to test fortified strscpyFrancis Laniel5-0/+88
This new test ensures that fortified strscpy has the same behavior than vanilla strscpy (e.g. returning -E2BIG when src content is truncated). Finally, it generates a crash at runtime because there is a write overflow in destination string. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Francis Laniel <[email protected]> Reviewed-by: Kees Cook <[email protected]> Cc: Daniel Axtens <[email protected]> Cc: Daniel Micay <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.