- 26 Sep, 2019 40 commits
-
-
Andrey Konovalov authored
Patch series "arm64: untag user pointers passed to the kernel", v19. === Overview arm64 has a feature called Top Byte Ignore, which allows to embed pointer tags into the top byte of each pointer. Userspace programs (such as HWASan, a memory debugging tool [1]) might use this feature and pass tagged user pointers to the kernel through syscalls or other interfaces. Right now the kernel is already able to handle user faults with tagged pointers, due to these patches: 1. 81cddd65 ("arm64: traps: fix userspace cache maintenance emulation on a tagged pointer") 2. 7dcd9dd8 ("arm64: hw_breakpoint: fix watchpoint matching for tagged pointers") 3. 276e9327 ("arm64: entry: improve data abort handling of tagged pointers") This patchset extends tagged pointer support to syscall arguments. As per the proposed ABI change [3], tagged pointers are only allowed to be passed to syscalls when they point to memory ranges obtained by anonymous mmap() or sbrk() (see the patchset [3] for more details). For non-memory syscalls this is done by untaging user pointers when the kernel performs pointer checking to find out whether the pointer comes from userspace (most notably in access_ok). The untagging is done only when the pointer is being checked, the tag is preserved as the pointer makes its way through the kernel and stays tagged when the kernel dereferences the pointer when perfoming user memory accesses. The mmap and mremap (only new_addr) syscalls do not currently accept tagged addresses. Architectures may interpret the tag as a background colour for the corresponding vma. Other memory syscalls (mprotect, etc.) don't do user memory accesses but rather deal with memory ranges, and untagged pointers are better suited to describe memory ranges internally. Thus for memory syscalls we untag pointers completely when they enter the kernel. === Other approaches One of the alternative approaches to untagging that was considered is to completely strip the pointer tag as the pointer enters the kernel with some kind of a syscall wrapper, but that won't work with the countless number of different ioctl calls. With this approach we would need a custom wrapper for each ioctl variation, which doesn't seem practical. An alternative approach to untagging pointers in memory syscalls prologues is to inspead allow tagged pointers to be passed to find_vma() (and other vma related functions) and untag them there. Unfortunately, a lot of find_vma() callers then compare or subtract the returned vma start and end fields against the pointer that was being searched. Thus this approach would still require changing all find_vma() callers. === Testing The following testing approaches has been taken to find potential issues with user pointer untagging: 1. Static testing (with sparse [2] and separately with a custom static analyzer based on Clang) to track casts of __user pointers to integer types to find places where untagging needs to be done. 2. Static testing with grep to find parts of the kernel that call find_vma() (and other similar functions) or directly compare against vm_start/vm_end fields of vma. 3. Static testing with grep to find parts of the kernel that compare user pointers with TASK_SIZE or other similar consts and macros. 4. Dynamic testing: adding BUG_ON(has_tag(addr)) to find_vma() and running a modified syzkaller version that passes tagged pointers to the kernel. Based on the results of the testing the requried patches have been added to the patchset. === Notes This patchset is meant to be merged together with "arm64 relaxed ABI" [3]. This patchset is a prerequisite for ARM's memory tagging hardware feature support [4]. This patchset has been merged into the Pixel 2 & 3 kernel trees and is now being used to enable testing of Pixel phones with HWASan. Thanks! [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html [2] https://github.com/lucvoo/sparse-dev/commit/5f960cb10f56ec2017c128ef9d16060e0145f292 [3] https://lkml.org/lkml/2019/6/12/745 [4] https://community.arm.com/processors/b/blog/posts/arm-a-profile-architecture-2018-developments-armv85a This patch (of 11) This patch is a part of a series that extends kernel ABI to allow to pass tagged user pointers (with the top byte set to something else other than 0x00) as syscall arguments. strncpy_from_user and strnlen_user accept user addresses as arguments, and do not go through the same path as copy_from_user and others, so here we need to handle the case of tagged user addresses separately. Untag user pointers passed to these functions. Note, that this patch only temporarily untags the pointers to perform validity checks, but then uses them as is to perform user memory accesses. [andreyknvl@google.com: fix sparc4 build] Link: http://lkml.kernel.org/r/CAAeHK+yx4a-P0sDrXTUxMvO2H0CJZUFPffBrg_cU7oJOZyC7ew@mail.gmail.com Link: http://lkml.kernel.org/r/c5a78bcad3e94d6cda71fcaa60a423231ae71e4c.1563904656.git.andreyknvl@google.comSigned-off-by:
Andrey Konovalov <andreyknvl@google.com> Reviewed-by:
Vincenzo Frascino <vincenzo.frascino@arm.com> Reviewed-by:
Khalid Aziz <khalid.aziz@oracle.com> Acked-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Eric Auger <eric.auger@redhat.com> Cc: Felix Kuehling <Felix.Kuehling@amd.com> Cc: Jens Wiklander <jens.wiklander@linaro.org> Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Cc: Mike Rapoport <rppt@linux.ibm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Dave Rodgman authored
Fix an unaligned access which breaks on platforms where this is not permitted (e.g., Sparc). Link: http://lkml.kernel.org/r/20190912145502.35229-1-dave.rodgman@arm.comSigned-off-by:
Dave Rodgman <dave.rodgman@arm.com> Cc: Dave Rodgman <dave.rodgman@arm.com> Cc: Markus F.X.J. Oberhumer <markus@oberhumer.com> Cc: Minchan Kim <minchan@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Joel Fernandes (Google) authored
CONFIG_PROVE_RCU_LIST requires list_for_each_entry_rcu() to pass a lockdep expression if using srcu or locking for protection. It can only check regular RCU protection, all other protection needs to be passed as lockdep expression. Link: http://lkml.kernel.org/r/20190830231817.76862-2-joel@joelfernandes.orgSigned-off-by:
Joel Fernandes (Google) <joel@joelfernandes.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: "Gustavo A. R. Silva" <gustavo@embeddedor.com> Cc: Jonathan Derrick <jonathan.derrick@intel.com> Cc: Keith Busch <keith.busch@intel.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Signed-off-by:
-
Markus Elfring authored
Null pointers were assigned to local variables in a few cases as exception handling. The jump target “out” was used where no meaningful data processing actions should eventually be performed by branches of an if statement then. Use an additional jump target for calling dev_kfree_skb() directly. Return also directly after error conditions were detected when no extra clean-up is needed by this function implementation. Link: http://lkml.kernel.org/r/592ef10e-0b69-72d0-9789-fc48f638fdfd@web.deSigned-off-by:
Markus Elfring <elfring@users.sourceforge.net> Cc: Davidlohr Bueso <dave@stgolabs.net> Cc: Manfred Spraul <manfred@colorfullife.com> Signed-off-by:
-
Markus Elfring authored
dev_kfree_skb() input parameter validation, thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Link: http://lkml.kernel.org/r/07477187-63e5-cc80-34c1-32dd16b38e12@web.deSigned-off-by:
-
Kees Cook authored
The original clean up of "cut here" missed the WARN_ON() case (that does not have a printk message), which was fixed recently by adding an explicit printk of "cut here". This had the downside of adding a printk() to every WARN_ON() caller, which reduces the utility of using an instruction exception to streamline the resulting code. By making this a new BUGFLAG, all of these can be removed and "cut here" can be handled by the exception handler. This was very pronounced on PowerPC, but the effect can be seen on x86 as well. The resulting text size of a defconfig build shows some small savings from this patch: text data bss dec hex filename 19691167 5134320 1646664 26472151 193eed7 vmlinux.before 19676362 5134260 1663048 26473670 193f4c6 vmlinux.after This change also opens the door for creating something like BUG_MSG(), where a custom printk() before issuing BUG(), without confusing the "cut here" line. Link: http://lkml.kernel.org/r/201908200943.601DD59DCE@keescook Fixes: 6b15f678 ("include/asm-generic/bug.h: fix "cut here" for WARN_ON for __WARN_TAINT architectures") Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Drew Davenport <ddavenport@chromium.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: "Steven Rostedt (VMware)" <rostedt@goodmis.org> Cc: Feng Tang <feng.tang@intel.com> Cc: Petr Mladek <pmladek@suse.com> Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Cc: Borislav Petkov <bp@suse.de> Cc: YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
Kees Cook authored
Instead of having separate tests for __WARN_FLAGS, merge the two #ifdef blocks and replace the synonym WANT_WARN_ON_SLOWPATH macro. Link: http://lkml.kernel.org/r/20190819234111.9019-7-keescook@chromium.orgSigned-off-by:
-
Kees Cook authored
In preparation for cleaning up "cut here" even more, this removes the __WARN_*TAINT() helpers, as they limit the ability to add new BUGFLAG_* flags to call sites. They are removed by expanding them into full __WARN_FLAGS() calls. Link: http://lkml.kernel.org/r/20190819234111.9019-6-keescook@chromium.orgSigned-off-by:
-
Kees Cook authored
In preparation for cleaning up "cut here", move the "cut here" logic up out of __warn() and into callers that pass non-NULL args. For anyone looking closely, there are two callers that pass NULL args: one already explicitly prints "cut here". The remaining case is covered by how a WARN is built, which will be cleaned up in the next patch. Link: http://lkml.kernel.org/r/20190819234111.9019-5-keescook@chromium.orgSigned-off-by:
-
Kees Cook authored
Instead of having a separate helper for no printk output, just consolidate the logic into warn_slowpath_fmt(). Link: http://lkml.kernel.org/r/20190819234111.9019-4-keescook@chromium.orgSigned-off-by:
-
Kees Cook authored
This just renames the helper to improve readability. Link: http://lkml.kernel.org/r/20190819234111.9019-3-keescook@chromium.orgSigned-off-by:
-
Kees Cook authored
Patch series "Clean up WARN() "cut here" handling", v2. Christophe Leroy noticed that the fix for missing "cut here" in the WARN() case was adding explicit printk() calls instead of teaching the exception handler to add it. This refactors the bug/warn infrastructure to pass this information as a new BUGFLAG. Longer details repeated from the last patch in the series: bug: move WARN_ON() "cut here" into exception handler The original cleanup of "cut here" missed the WARN_ON() case (that does not have a printk message), which was fixed recently by adding an explicit printk of "cut here". This had the downside of adding a printk() to every WARN_ON() caller, which reduces the utility of using an instruction exception to streamline the resulting code. By making this a new BUGFLAG, all of these can be removed and "cut here" can be handled by the exception handler. This was very pronounced on PowerPC, but the effect can be seen on x86 as well. The resulting text size of a defconfig build shows some small savings from this patch: text data bss dec hex filename 19691167 5134320 1646664 26472151 193eed7 vmlinux.before 19676362 5134260 1663048 26473670 193f4c6 vmlinux.after This change also opens the door for creating something like BUG_MSG(), where a custom printk() before issuing BUG(), without confusing the "cut here" line. This patch (of 7): There's no reason to have specialized helpers for passing the warn taint down to __warn(). Consolidate and refactor helper macros, removing __WARN_printf() and warn_slowpath_fmt_taint(). Link: http://lkml.kernel.org/r/20190819234111.9019-2-keescook@chromium.orgSigned-off-by:
-
Douglas Anderson authored
Some systems (like Chrome OS) may use "split debug" for kernel modules. That means that the debug symbols are in a different file than the main elf file. Let's handle that by also searching for debug symbols that end in ".ko.debug". This is a packaging topic. You can take a normal elf file and split the debug out of it using objcopy. Try "man objcopy" and then take a look at the "--only-keep-debug" option. It'll give you a whole recipe for doing splitdebug. The suffix used for the debug symbols is arbitrary. If people have other another suffix besides ".ko.debug" then we could presumably support that too... For portage (which is the packaging system used by Chrome OS) split debug is supported by default (and the suffix is .ko.debug). ...and so in Chrome OS we always get the installed elf files stripped and then the symbols stashed away. At the moment we don't actually use the normal portage magic to do this for the kernel though since it affects our ability to get good stack dumps in the kernel. We instead pass a script as "strip" [1]. [1] https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/master/eclass/cros-kernel/strip_splitdebug Link: http://lkml.kernel.org/r/20190730234052.148744-1-dianders@chromium.orgSigned-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
Jan Kiszka <jan.kiszka@siemens.com> Cc: Kieran Bingham <kbingham@kernel.org> Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by:
-
Douglas Anderson authored
Right now kgdb/kdb hooks up to debug panics by registering for the panic notifier. This works OK except that it means that kgdb/kdb gets called _after_ the CPUs in the system are taken offline. That means that if anything important was happening on those CPUs (like something that might have contributed to the panic) you can't debug them. Specifically I ran into a case where I got a panic because a task was "blocked for more than 120 seconds" which was detected on CPU 2. I nicely got shown stack traces in the kernel log for all CPUs including CPU 0, which was running 'PID: 111 Comm: kworker/0:1H' and was in the middle of __mmc_switch(). I then ended up at the kdb prompt where switched over to kgdb to try to look at local variables of the process on CPU 0. I found that I couldn't. Digging more, I found that I had no info on any tasks running on CPUs other than CPU 2 and that asking kdb for help showed me "Error: no saved data for this cpu". This was because all the CPUs were offline. Let's move the entry of kdb/kgdb to a direct call from panic() and stop using the generic notifier. Putting a direct call in allows us to order things more properly and it also doesn't seem like we're breaking any abstractions by calling into the debugger from the panic function. Daniel said: : This patch changes the way kdump and kgdb interact with each other. : However it would seem rather odd to have both tools simultaneously armed : and, even if they were, the user still has the option to use panic_timeout : to force a kdump to happen. Thus I think the change of order is : acceptable. Link: http://lkml.kernel.org/r/20190703170354.217312-1-dianders@chromium.orgSigned-off-by:
Daniel Thompson <daniel.thompson@linaro.org> Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Kees Cook <keescook@chromium.org> Cc: Borislav Petkov <bp@suse.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Feng Tang <feng.tang@intel.com> Cc: YueHaibing <yuehaibing@huawei.com> Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> Cc: "Steven Rostedt (VMware)" <rostedt@goodmis.org> Signed-off-by:
-
Masahiro Yamada authored
Commit 9012d011 ("compiler: allow all arches to enable CONFIG_OPTIMIZE_INLINING") allowed all architectures to enable this option. A couple of build errors were reported by randconfig, but all of them have been ironed out. Towards the goal of removing CONFIG_OPTIMIZE_INLINING entirely (and it will simplify the 'inline' macro in compiler_types.h), this commit changes it to always-on option. Going forward, the compiler will always be allowed to not inline functions marked 'inline'. This is not a problem for x86 since it has been long used by arch/x86/configs/{x86_64,i386}_defconfig. I am keeping the config option just in case any problem crops up for other architectures. The code clean-up will be done after confirming this is solid. Link: http://lkml.kernel.org/r/20190830034304.24259-1-yamada.masahiro@socionext.comSigned-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
Nick Desaulniers <ndesaulniers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Signed-off-by:
-
Kees Cook authored
The usercopy implementation comments describe that callers of the copy_*_user() family of functions must always have their return values checked. This can be enforced at compile time with __must_check, so add it where needed. Link: http://lkml.kernel.org/r/201908251609.ADAD5CAAC1@keescookSigned-off-by:
-
Vasily Gorbik authored
arch_kexec_kernel_image_probe function declaration has been removed by commit 9ec4ecef ("kexec_file,x86,powerpc: factor out kexec_file_ops functions"). Still this function is overridden by couple of architectures and proper prototype declaration is therefore important, so bring it back. This fixes the following sparse warning on s390: arch/s390/kernel/machine_kexec_file.c:333:5: warning: symbol 'arch_kexec_kernel_image_probe' was not declared. Should it be static? Link: http://lkml.kernel.org/r/patch.git-ff1c9045ebdc.your-ad-here.call-01564402297-ext-5690@work.hoursSigned-off-by:
Vasily Gorbik <gor@linux.ibm.com> Acked-by:
Dave Young <dyoung@redhat.com> Reviewed-by:
Bhupesh Sharma <bhsharma@redhat.com> Cc: Eric Biederman <ebiederm@xmission.com> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org> Signed-off-by:
-
Tetsuo Handa authored
syzbot found that a thread can stall for minutes inside kexec_load() after that thread was killed by SIGKILL [1]. It turned out that the reproducer was trying to allocate 2408MB of memory using kimage_alloc_page() from kimage_load_normal_segment(). Let's check for SIGKILL before doing memory allocation. [1] https://syzkaller.appspot.com/bug?id=a0e3436829698d5824231251fad9d8e998f94f5e Link: http://lkml.kernel.org/r/993c9185-d324-2640-d061-bed2dd18b1f7@I-love.SAKURA.ne.jpSigned-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reported-by:
syzbot <syzbot+8ab2d0f39fb79fe6ca40@syzkaller.appspotmail.com> Cc: Eric Biederman <ebiederm@xmission.com> Reviewed-by:
-
Alexey Dobriyan authored
Mask arguments can be swapped without changing anything. Make arguments names reflect that: #define for_each_cpu_and(cpu, mask1, mask2) Link: http://lkml.kernel.org/r/20190724183350.GA15041@avx2Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Reviewed-by:
-
Sai Praneeth Prakhya authored
When a user process exits, the kernel cleans up the mm_struct of the user process and during cleanup, check_mm() checks the page tables of the user process for corruption (E.g: unexpected page flags set/cleared). For corrupted page tables, the error message printed by check_mm() isn't very clear as it prints the loop index instead of page table type (E.g: Resident file mapping pages vs Resident shared memory pages). The loop index in check_mm() is used to index rss_stat[] which represents individual memory type stats. Hence, instead of printing index, print memory type, thereby improving error message. Without patch: -------------- [ 204.836425] mm/pgtable-generic.c:29: bad p4d 0000000089eb4e92(800000025f941467) [ 204.836544] BUG: Bad rss-counter state mm:00000000f75895ea idx:0 val:2 [ 204.836615] BUG: Bad rss-counter state mm:00000000f75895ea idx:1 val:5 [ 204.836685] BUG: non-zero pgtables_bytes on freeing mm: 20480 With patch: ----------- [ 69.815453] mm/pgtable-generic.c:29: bad p4d 0000000084653642(800000025ca37467) [ 69.815872] BUG: Bad rss-counter state mm:00000000014a6c03 type:MM_FILEPAGES val:2 [ 69.815962] BUG: Bad rss-counter state mm:00000000014a6c03 type:MM_ANONPAGES val:5 [ 69.816050] BUG: non-zero pgtables_bytes on freeing mm: 20480 Also, change print function (from printk(KERN_ALERT, ..) to pr_alert()) so that it matches the other print statement. Link: http://lkml.kernel.org/r/da75b5153f617f4c5739c08ee6ebeb3d19db0fbc.1565123758.git.sai.praneeth.prakhya@intel.comSigned-off-by:
Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com> Reviewed-by:
Anshuman Khandual <anshuman.khandual@arm.com> Suggested-by:
Dave Hansen <dave.hansen@intel.com> Acked-by:
Michal Hocko <mhocko@suse.com> Acked-by:
Vlastimil Babka <vbabka@suse.cz> Acked-by:
-
Markus Elfring authored
brelse() tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Link: http://lkml.kernel.org/r/cfff3b81-fb5d-af26-7b5e-724266509045@web.deSigned-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by:
-
Jason Yan authored
Fix the following gcc warning: fs/reiserfs/do_balan.c: In function balance_leaf_insert_right: fs/reiserfs/do_balan.c:629:6: warning: variable ret set but not used [-Wunused-but-set-variable] Link: http://lkml.kernel.org/r/20190827032932.46622-2-yanaijie@huawei.comSigned-off-by:
Jason Yan <yanaijie@huawei.com> Cc: zhengbin <zhengbin13@huawei.com> Cc: Jan Kara <jack@suse.cz> Signed-off-by:
-
Jason Yan authored
Fix the following gcc warning: fs/reiserfs/journal.c: In function flush_used_journal_lists: fs/reiserfs/journal.c:1791:6: warning: variable ret set but not used [-Wunused-but-set-variable] Link: http://lkml.kernel.org/r/20190827032932.46622-1-yanaijie@huawei.comSigned-off-by:
-
zhengbin authored
fs/reiserfs/do_balan.c: In function balance_leaf_when_delete: fs/reiserfs/do_balan.c:245:20: warning: variable ih set but not used [-Wunused-but-set-variable] fs/reiserfs/do_balan.c: In function balance_leaf_insert_left: fs/reiserfs/do_balan.c:301:7: warning: variable version set but not used [-Wunused-but-set-variable] fs/reiserfs/do_balan.c: In function balance_leaf_insert_right: fs/reiserfs/do_balan.c:649:7: warning: variable version set but not used [-Wunused-but-set-variable] fs/reiserfs/do_balan.c: In function balance_leaf_new_nodes_insert: fs/reiserfs/do_balan.c:953:7: warning: variable version set but not used [-Wunused-but-set-variable] Link: http://lkml.kernel.org/r/1566379929-118398-8-git-send-email-zhengbin13@huawei.comSigned-off-by:
zhengbin <zhengbin13@huawei.com> Reported-by:
Hulk Robot <hulkci@huawei.com> Cc: Jan Kara <jack@suse.cz> Signed-off-by:
-
zhengbin authored
fs/reiserfs/fix_node.c: In function get_num_ver: fs/reiserfs/fix_node.c:379:6: warning: variable cur_free set but not used [-Wunused-but-set-variable] fs/reiserfs/fix_node.c: In function dc_check_balance_internal: fs/reiserfs/fix_node.c:1737:6: warning: variable maxsize set but not used [-Wunused-but-set-variable] Link: http://lkml.kernel.org/r/1566379929-118398-7-git-send-email-zhengbin13@huawei.comSigned-off-by:
-
zhengbin authored
Fixes gcc '-Wunused-but-set-variable' warning: fs/reiserfs/prints.c: In function check_internal_block_head: fs/reiserfs/prints.c:749:21: warning: variable blkh set but not used [-Wunused-but-set-variable] Link: http://lkml.kernel.org/r/1566379929-118398-6-git-send-email-zhengbin13@huawei.comSigned-off-by:
-
zhengbin authored
Fixes gcc '-Wunused-but-set-variable' warning: fs/reiserfs/objectid.c: In function reiserfs_convert_objectid_map_v1: fs/reiserfs/objectid.c:186:25: warning: variable new_objectid_map set but not used [-Wunused-but-set-variable] Link: http://lkml.kernel.org/r/1566379929-118398-5-git-send-email-zhengbin13@huawei.comSigned-off-by:
-
zhengbin authored
Fixes gcc '-Wunused-but-set-variable' warning: fs/reiserfs/lbalance.c: In function leaf_paste_entries: fs/reiserfs/lbalance.c:1325:9: warning: variable old_entry_num set but not used [-Wunused-but-set-variable] Link: http://lkml.kernel.org/r/1566379929-118398-4-git-send-email-zhengbin13@huawei.comSigned-off-by:
-
zhengbin authored
Fixes gcc '-Wunused-but-set-variable' warning: fs/reiserfs/stree.c: In function search_by_key: fs/reiserfs/stree.c:596:6: warning: variable right_neighbor_of_leaf_node set but not used [-Wunused-but-set-variable] Link: http://lkml.kernel.org/r/1566379929-118398-3-git-send-email-zhengbin13@huawei.comSigned-off-by:
-
zhengbin authored
Fixes gcc '-Wunused-but-set-variable' warning: fs/reiserfs/journal.c: In function flush_older_commits: fs/reiserfs/journal.c:894:15: warning: variable first_trans_id set but not used [-Wunused-but-set-variable] fs/reiserfs/journal.c: In function flush_journal_list: fs/reiserfs/journal.c:1354:38: warning: variable last set but not used [-Wunused-but-set-variable] fs/reiserfs/journal.c: In function do_journal_release: fs/reiserfs/journal.c:1916:6: warning: variable flushed set but not used [-Wunused-but-set-variable] fs/reiserfs/journal.c: In function do_journal_end: fs/reiserfs/journal.c:3993:6: warning: variable old_start set but not used [-Wunused-but-set-variable] Link: http://lkml.kernel.org/r/1566379929-118398-2-git-send-email-zhengbin13@huawei.comSigned-off-by:
-
Jia-Ju Bai authored
On lines 3430-3434, bh has been assured to be non-null: cn = get_journal_hash_dev(sb, journal->j_hash_table, blocknr); if (!cn || !cn->bh) { return ret; } bh = cn->bh; Thus, the check of bh on line 3447 is unnecessary and can be removed. Thank Andrew Morton for good advice. Link: http://lkml.kernel.org/r/20190727084019.11307-1-baijiaju1990@gmail.comSigned-off-by:Jia-Ju Bai <baijiaju1990@gmail.com> Reviewed-by:
Jan Kara <jack@suse.cz> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Hariprasad Kelam <hariprasad.kelam@gmail.com> Cc: Bharath Vedartham <linux.bhar@gmail.com> Signed-off-by:
-
Joe Perches authored
git output parsing depends on the language being en_US english. Make the backtick execution of all `git <foo>` commands set the LANGUAGE of the process to en_US.utf8 before executing the actual command using `export LANGUAGE=en_US.utf8; git <foo>`. Because the command is executed in a child process, the parent LANGUAGE is unchanged. Link: http://lkml.kernel.org/r/bb9f29988f3258281956680ff39c3e19e37dc0b8.camel@perches.comSigned-off-by:
Joe Perches <joe@perches.com> Reported-by:
Sean Christopherson <sean.j.christopherson@intel.com> Reviewed-by:
-
Sean Christopherson authored
Git dropped the period from its "ambiguous SHA1" error message in commit 0c99171ad2 ("get_short_sha1: mark ambiguity error for translation"), circa 2016. Drop the period from checkpatch's associated query so as to match both the old and new error messages. Link: http://lkml.kernel.org/r/20190830163103.15914-1-sean.j.christopherson@intel.comSigned-off-by: -
Joe Perches authored
checkpatch allows consecutive open braces, so it should also allow consecutive close braces. Link: http://lkml.kernel.org/r/bfdb49ae2c3fa7b52fa168769e38b48f959880e2.camel@perches.comSigned-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Joe Perches authored
Add another test for __attribute__((section("foo"))) uses that should be __section(foo) Link: http://lkml.kernel.org/r/2f374c3c27054b7f978115270d587c624d9962fc.camel@perches.comSuggested-by: -
Brendan Jackman authored
The arguments of sizeof are not evaluated so arguments are safe to re-use in that context. Excluding sizeof subexpressions means macros like ARRAY_SIZE can pass checkpatch. Link: http://lkml.kernel.org/r/20190806070833.24423-1-brendan.jackman@bluwireless.co.ukSigned-off-by:
Brendan Jackman <brendan.jackman@bluwireless.co.uk> Acked-by:
-
Matteo Croce authored
It can happen that a commit message refers to an invalid commit id, because the referenced hash changed following a rebase, or simply by mistake. Add a check in checkpatch.pl which checks that an hash referenced by a Fixes tag, or just cited in the commit message, is a valid commit id. $ scripts/checkpatch.pl <<'EOF' Subject: [PATCH] test commit Sample test commit to test checkpatch.pl Commit 1da177e4 ("Linux-2.6.12-rc2") really exists, commit 0bba044c4ce7 ("tree") is valid but not a commit, while commit b4cc0b1c0cca ("unknown") is invalid. Fixes: f0cacc14cade ("unknown") Fixes: 1da177e4 ("Linux-2.6.12-rc2") EOF WARNING: Unknown commit id '0bba044c4ce7', maybe rebased or not pulled? #8: commit 0bba044c4ce7 ("tree") is valid but not a commit, WARNING: Unknown commit id 'b4cc0b1c0cca', maybe rebased or not pulled? #9: while commit b4cc0b1c0cca ("unknown") is invalid. WARNING: Unknown commit id 'f0cacc14cade', maybe rebased or not pulled? #11: Fixes: f0cacc14cade ("unknown") total: 0 errors, 3 warnings, 4 lines checked Link: http://lkml.kernel.org/r/20190711001640.13398-1-mcroce@redhat.comSigned-off-by:Matteo Croce <mcroce@redhat.com> Cc: Joe Perches <joe@perches.com> Signed-off-by:
-
Joe Perches authored
Use perl's m@<match>@ match and not /<match>/ comparisons to avoid an error using c90's // comment style. Miscellanea: o Use normal tab indentation and alignment Link: http://lkml.kernel.org/r/5e4a8fa7901148fbcd77ab391e6dd0e6bf95777f.camel@perches.com Link: http://lkml.kernel.org/r/f08eb62458407a145cfedf959d1091af151cd665.1563575364.git.joe@perches.comSigned-off-by:
-
Joe Perches authored
Add more types of lines that appear to be stack dumps that also include hex lines that might otherwise be interpreted as commit IDs. Link: http://lkml.kernel.org/r/ff00208289224f0ca4eaf4ff7c9c6e087dad0a63.camel@perches.com Link: http://lkml.kernel.org/r/f7dc9727795db3802809a24162abe0b67e14123b.1563575364.git.joe@perches.comSigned-off-by:
-
Stephen Boyd authored
I'm seeing a bunch of debug prints from a user of print_hex_dump_bytes() in my kernel logs, but I don't have CONFIG_DYNAMIC_DEBUG enabled nor do I have DEBUG defined in my build. The problem is that print_hex_dump_bytes() calls a wrapper function in lib/hexdump.c that calls print_hex_dump() with KERN_DEBUG level. There are three cases to consider here 1. CONFIG_DYNAMIC_DEBUG=y --> call dynamic_hex_dum() 2. CONFIG_DYNAMIC_DEBUG=n && DEBUG --> call print_hex_dump() 3. CONFIG_DYNAMIC_DEBUG=n && !DEBUG --> stub it out Right now, that last case isn't detected and we still call print_hex_dump() from the stub wrapper. Let's make print_hex_dump_bytes() only call print_hex_dump_debug() so that it works properly in all cases. Case #1, print_hex_dump_debug() calls dynamic_hex_dump() and we get same behavior. Case #2, print_hex_dump_debug() calls print_hex_dump() with KERN_DEBUG and we get the same behavior. Case #3, print_hex_dump_debug() is a nop, changing behavior to what we want, i.e. print nothing. Link: http://lkml.kernel.org/r/20190816235624.115280-1-swboyd@chromium.orgSigned-off-by:
-
