- 16 Dec, 2020 40 commits
-
-
Zou Wei authored
Fix the following sparse warning: lib/ubsan.c:20:12: warning: symbol 'type_check_kinds' was not declared. Should it be static? [akpm@linux-foundation.org: make it `static const char * const' while we're in there] Link: https://lkml.kernel.org/r/1607602638-79584-1-git-send-email-zou_wei@huawei.comSigned-off-by:
Zou Wei <zou_wei@huawei.com> Reviewed-by:
Andrew Morton <akpm@linux-foundation.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Dmitry Vyukov authored
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/20201209100152.2492072-1-dvyukov@google.comSigned-off-by:
Dmitry Vyukov <dvyukov@google.com> Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Suggested-by:
Marco Elver <elver@google.com> Acked-by:
Andrey Konovalov <andreyknvl@google.com> Reviewed-by:
-
Kees Cook authored
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/20201203004437.389959-8-keescook@chromium.orgSigned-off-by:
-
Kees Cook authored
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/20201203004437.389959-7-keescook@chromium.orgSigned-off-by:
-
Kees Cook authored
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. [sfr@canb.auug.org.au: add .data..Lubsan_data*/.data..Lubsan_type* sections explicitly] Link: https://lkml.kernel.org/r/20201208230157.42c42789@canb.auug.org.au Link: https://lore.kernel.org/lkml/CAHk-=wgXW=YLxGN0QVpp-1w5GDd2pf1W-FqY15poKzoVfik2qA@mail.gmail.com/ Link: https://lkml.kernel.org/r/20201203004437.389959-6-keescook@chromium.orgSigned-off-by:
-
Kees Cook authored
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/20201203004437.389959-5-keescook@chromium.orgSigned-off-by:
Nathan Chancellor <natechancellor@gmail.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: George Popescu <georgepope@android.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Marco Elver <elver@google.com> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Michal Marek <michal.lkml@markovi.net> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Peter Oberparleiter <oberpar@linux.ibm.com> Cc: Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Kees Cook authored
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/20201203004437.389959-4-keescook@chromium.org Link: https://lore.kernel.org/lkml/CAHk-=wjPasyJrDuwDnpHJS2TuQfExwe=px-SzLeN8GFMAQJPmQ@mail.gmail.com/Signed-off-by:
-
Kees Cook authored
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/20201203004437.389959-3-keescook@chromium.org Link: https://lore.kernel.org/lkml/CAHk-=wjPasyJrDuwDnpHJS2TuQfExwe=px-SzLeN8GFMAQJPmQ@mail.gmail.com/Signed-off-by:
-
Kees Cook authored
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 78a5255f ("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/20201203004437.389959-1-keescook@chromium.org Link: https://lkml.kernel.org/r/20201203004437.389959-2-keescook@chromium.orgSigned-off-by:
-
Mauro Carvalho Chehab authored
Kernel-doc markups should use this format: identifier - description While here, fix a kernel-doc tag that was using, instead, a normal comment block. [akpm@linux-foundation.org: coding style fixes] Link: https://lkml.kernel.org/r/c5e38e1070f8dbe2f9607a10b44afe2875bd966c.1605521731.git.mchehab+huawei@kernel.orgSigned-off-by:Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Cc: "Jonathan Corbet" <corbet@lwn.net> Cc: Matthew Wilcox <willy@infradead.org> Signed-off-by:
-
Jani Nikula authored
Now that relay_open() accepts const callbacks, make relay callbacks const. Link: https://lkml.kernel.org/r/7ff5ce0b735901eb4f10e13da2704f1d8c4a2507.1606153547.git.jani.nikula@intel.comSigned-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Cc: Jens Axboe <axboe@kernel.dk> Cc: Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Jani Nikula authored
Now that relay_open() accepts const callbacks, make relay callbacks const. Link: https://lkml.kernel.org/r/7db0286c428f3a478dd7544afef04a3b131f1aa0.1606153547.git.jani.nikula@intel.comSigned-off-by:
Kalle Valo <kvalo@codeaurora.org> Reviewed-by:
-
Jani Nikula authored
Now that relay_open() accepts const callbacks, make relay callbacks const. Link: https://lkml.kernel.org/r/44e3d65b71025c462948d0c554061dc7b40ab488.1606153547.git.jani.nikula@intel.comSigned-off-by:
-
Jani Nikula authored
Now that relay_open() accepts const callbacks, make relay callbacks const. Link: https://lkml.kernel.org/r/85cabc6d4b0d0ca43d4e0fb94897ccd16e3b7930.1606153547.git.jani.nikula@intel.comSigned-off-by:
-
Jani Nikula authored
Now that relay_open() accepts const callbacks, make relay callbacks const. Link: https://lkml.kernel.org/r/534d089f413db98aa0b94773fa49d5275d0d3c25.1606153547.git.jani.nikula@intel.comSigned-off-by:
-
Jani Nikula authored
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. [jani.nikula@intel.com: cleanups, per Christoph] Link: https://lkml.kernel.org/r/20201124115412.32402-1-jani.nikula@intel.com Link: https://lkml.kernel.org/r/cc3ff292e4eb4fdc56bee3d690c7b8e39209cd37.1606153547.git.jani.nikula@intel.comSigned-off-by:
-
Jani Nikula authored
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.comSigned-off-by:
Christoph Hellwig <hch@infradead.org> Reviewed-by:
-
Jani Nikula authored
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.comSigned-off-by:
-
Jani Nikula authored
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/cover.1606153547.git.jani.nikula@intel.com Link: https://lkml.kernel.org/r/c69fff6e0cd485563604240bbfcc028434983bec.1606153547.git.jani.nikula@intel.comSigned-off-by:
-
Randy Dunlap authored
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/20201203212634.17278-1-rdunlap@infradead.org Reported-by: syzbot+3fd34060f26e766536ff@syzkaller.appspotmail.com Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Al Viro <viro@ZenIV.linux.org.uk> Cc: "Tigran A. Aivazian" <aivazian.tigran@gmail.com> Signed-off-by:
-
Alex Shi authored
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/1605252352-63983-1-git-send-email-alex.shi@linux.alibaba.comSigned-off-by:
Alex Shi <alex.shi@linux.alibaba.com> Acked-by:
Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by:
-
Nick Desaulniers authored
Since commit 0bddd227 ("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 10415533 ("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/20201111030557.2015680-1-ndesaulniers@google.comSigned-off-by:
Nick Desaulniers <ndesaulniers@google.com> Reviewed-by:
-
Sebastian Andrzej Siewior authored
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 394b701c ("[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/20201116170004.420143-1-bigeasy@linutronix.deSigned-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Alexandre Bounine <alex.bou9@gmail.com> Signed-off-by:
-
Alexander Egorenkov authored
The offset of the field 'init_uts_ns.name' has changed since commit 9a56493f ("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/20200930102328.396488-1-egorenar@linux.ibm.comSigned-off-by:
Alexander Egorenkov <egorenar@linux.ibm.com> Acked-by:
lijiang <lijiang@redhat.com> Acked-by:
Baoquan He <bhe@redhat.com> Cc: Dave Young <dyoung@redhat.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: "Eric W . Biederman" <ebiederm@xmission.com> Cc: Kirill Tkhai <ktkhai@virtuozzo.com> Cc: Kees Cook <keescook@chromium.org> Cc: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by:
-
Alex Shi authored
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/1607552733-24292-1-git-send-email-konishi.ryusuke@gmail.comSigned-off-by:
Ryusuke Konishi <konishi.ryusuke@gmail.com> Signed-off-by:
-
Joe Perches authored
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 [joe@perches.com: fixlet] Link: https://lkml.kernel.org/r/32260871d4718ba7f48a8e9e07452bb76de300db.camel@perches.comLink: https://lkml.kernel.org/r/993b72b2ef91a57c5e725b52971ce3fd31375061.camel@perches.comSigned-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Dwaipayan Ray authored
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. [akpm@linux-foundation.org: make matched misspelling more obvious, per Joe] Link: https://lkml.kernel.org/r/09c24ef1aa2f1c4fe909d76f5426f08780b9d81c.camel@perches.com Link: https://lkml.kernel.org/r/20201201190729.169733-1-dwaipayanray1@gmail.comSigned-off-by:
Dwaipayan Ray <dwaipayanray1@gmail.com> Suggested-by:
Peilin Ye <yepeilin.cs@gmail.com> Acked-by:
-
Dwaipayan Ray authored
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/20201202205740.127986-1-dwaipayanray1@gmail.comSigned-off-by:
-
Dwaipayan Ray authored
Modifiers %h and %hh should never be used. Commit cbacb5ab ("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/4910042649a4f3ab22fac93191b8c1fa0a2e17c3.camel@perches.com/ Link: https://lkml.kernel.org/r/20201128200046.78739-1-dwaipayanray1@gmail.comSigned-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Acked-by:
-
Aditya Srivastava authored
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/20201128204333.7054-1-yashsri421@gmail.comSigned-off-by:
Aditya Srivastava <yashsri421@gmail.com> Acked-by:
-
Aditya Srivastava authored
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 3485507f ("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/20201123102818.24364-1-yashsri421@gmail.comSigned-off-by:
-
Aditya Srivastava authored
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 8195b139 ("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/20201121120407.22942-1-yashsri421@gmail.comSigned-off-by:
-
Dwaipayan Ray authored
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/20201115202928.81955-1-dwaipayanray1@gmail.com Fixes: 8d182478 ("checkpatch: add --fix option for a couple OPEN_BRACE misuses") Signed-off-by:
-
Aditya Srivastava authored
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: stable@vger.org 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/20201116083754.10629-1-yashsri421@gmail.comSigned-off-by: -
Dwaipayan Ray authored
Delete repeated word in scripts/checkpatch.pl: "are are" -> "are" Fix typos: "commments" -> "comments" "falsly" -> "falsely" Link: https://lkml.kernel.org/r/20201113152316.62975-1-dwaipayanray1@gmail.comSigned-off-by:
-
Dwaipayan Ray authored
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: <stable@vger.kernel.org> # 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/6c275d95c3033422addfc256a30e6ae3dd37941d.camel@perches.com/ Link: https://lore.kernel.org/linux-kernel-mentees/20201105200857.GC1333458@kroah.com/ Link: https://lkml.kernel.org/r/20201108100632.75340-1-dwaipayanray1@gmail.comSigned-off-by:
-
Joe Perches authored
Add __alias and __weak to the suggested __attribute__((<foo>)) conversions. Link: https://lkml.kernel.org/r/7b74137743c58ce0633ec4d575b94e2210e4dbe7.camel@perches.comSigned-off-by:
-
Aditya Srivastava authored
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 adc311a5 ("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/20201030114447.24199-1-yashsri421@gmail.comSigned-off-by:
-
Joe Perches authored
commit 33def849 ("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...)). [joe@perches.com: eliminate the separate test below the possible conversions loop] Link: https://lkml.kernel.org/r/58e9d55e933dc8fdc6af489f2ad797fa8eb13e44.camel@perches.com Link: https://lkml.kernel.org/r/c04dd1c810e8d6a68e6a632e3191ae91651c8edf.camel@perches.comSigned-off-by:
-
Tom Rix authored
Remove the trailing error message from the fixed lines. Link: https://lkml.kernel.org/r/20201017142546.28988-1-trix@redhat.comSigned-off-by:
Tom Rix <trix@redhat.com> Acked-by:
-
