- 06 Oct, 2016 9 commits
-
-
Linus Torvalds authored
commit 124a3d88 upstream. Newer versions of gcc warn about the use of __builtin_return_address() with a non-zero argument when "-Wall" is specified: kernel/trace/trace_irqsoff.c: In function ‘stop_critical_timings’: kernel/trace/trace_irqsoff.c:433:86: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe [-Wframe-address] stop_critical_timing(CALLER_ADDR0, CALLER_ADDR1); [ .. repeats a few times for other similar cases .. ] It is true that a non-zero argument is somewhat dangerous, and we do not actually have very many uses of that in the kernel - but the ftrace code does use it, and as Stephen Rostedt says: "We are well aware of the danger of using __builtin_return_address() of > 0. In fact that's part of the reason for having the "thunk" code in x86 (See arch/x86/entry/thunk_{64,32}.S). [..] it adds extra frames when tracking irqs off sections, to prevent __builtin_return_address() from accessing bad areas. In fact the thunk_32.S states: 'Trampoline to trace irqs off. (otherwise CALLER_ADDR1 might crash)'." For now, __builtin_return_address() with a non-zero argument is the best we can do, and the warning is not helpful and can end up making people miss other warnings for real problems. So disable the frame-address warning on compilers that need it. Acked-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Linus Torvalds authored
commit 6e8d666e upstream. Several build configurations had already disabled this warning because it generates a lot of false positives. But some had not, and it was still enabled for "allmodconfig" builds, for example. Looking at the warnings produced, every single one I looked at was a false positive, and the warnings are frequent enough (and big enough) that they can easily hide real problems that you don't notice in the noise generated by -Wmaybe-uninitialized. The warning is good in theory, but this is a classic case of a warning that causes more problems than the warning can solve. If gcc gets better at avoiding false positives, we may be able to re-enable this warning. But as is, we're better off without it, and I want to be able to see the *real* warnings. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Arnd Bergmann authored
commit e72e2dfe upstream. When gcov profiling is enabled, we see a lot of spurious warnings about possibly uninitialized variables being used: arch/arm/mm/dma-mapping.c: In function 'arm_coherent_iommu_map_page': arch/arm/mm/dma-mapping.c:1085:16: warning: 'start' may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/clk/st/clk-flexgen.c: In function 'st_of_flexgen_setup': drivers/clk/st/clk-flexgen.c:323:9: warning: 'num_parents' may be used uninitialized in this function [-Wmaybe-uninitialized] kernel/cgroup.c: In function 'cgroup_mount': kernel/cgroup.c:2119:11: warning: 'root' may be used uninitialized in this function [-Wmaybe-uninitialized] All of these are false positives, so it seems better to just disable the warnings whenever GCOV is enabled. Most users don't enable GCOV, and based on a prior patch, it is now also disabled for 'allmodconfig' builds, so there should be no downsides of doing this. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Peter Oberparleiter <oberpar@linux.vnet.ibm.com> Signed-off-by:
Michal Marek <mmarek@suse.com> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Arnd Bergmann authored
commit 815eb71e upstream. CONFIG_PROFILE_ALL_BRANCHES confuses gcc-5.x to the degree that it prints incorrect warnings about a lot of variables that it thinks can be used uninitialized, e.g.: i2c/busses/i2c-diolan-u2c.c: In function 'diolan_usb_xfer': i2c/busses/i2c-diolan-u2c.c:391:16: warning: 'byte' may be used uninitialized in this function iio/gyro/itg3200_core.c: In function 'itg3200_probe': iio/gyro/itg3200_core.c:213:6: warning: 'val' may be used uninitialized in this function leds/leds-lp55xx-common.c: In function 'lp55xx_update_bits': leds/leds-lp55xx-common.c:350:6: warning: 'tmp' may be used uninitialized in this function misc/bmp085.c: In function 'show_pressure': misc/bmp085.c:363:10: warning: 'pressure' may be used uninitialized in this function power/ds2782_battery.c: In function 'ds2786_get_capacity': power/ds2782_battery.c:214:17: warning: 'raw' may be used uninitialized in this function These are all false positives that either rob someone's time when trying to figure out whether they are real, or they get people to send wrong patches to shut up the warnings. Nobody normally wants to run a CONFIG_PROFILE_ALL_BRANCHES kernel in production, so disabling the whole class of warnings for this configuration has no serious downsides either. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by: Steven Rostedt <rostedtgoodmis.org> Signed-off-by:
Michal Marek <mmarek@suse.com> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Robert Jarzmik authored
commit 51193b76 upstream. When the kernel path contains a space or a colon somewhere in the path name, the modules_install target doesn't work anymore, as the path names are not enclosed in double quotes. It is also supposed that and O= build will suffer from the same weakness as modules_install. Instead of checking and improving kbuild to resist to directories including these characters, error out early to prevent any build if the kernel's main directory contains a space. Signed-off-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
Michal Marek <mmarek@suse.com> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Wang YanQing authored
commit 40ab87a4 upstream. Commit 62718979 ("Makefile: Document ability to make file.lst and file.S") document ability to make file.S, but there isn't such ability in kbuild, so revert it. Signed-off-by:
Wang YanQing <udknight@gmail.com> Signed-off-by:
Michal Marek <mmarek@suse.com> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Michal Marek authored
commit a85a41ed upstream. Based on a x86-only patch by Andy Lutomirski <luto@amacapital.net> With modular kernels, 'make install' is going to need the installed modules at some point to generate the initramfs. Signed-off-by:
Michal Marek <mmarek@suse.cz> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Ashish Samant authored
commit d21c353d upstream. If we punch a hole on a reflink such that following conditions are met: 1. start offset is on a cluster boundary 2. end offset is not on a cluster boundary 3. (end offset is somewhere in another extent) or (hole range > MAX_CONTIG_BYTES(1MB)), we dont COW the first cluster starting at the start offset. But in this case, we were wrongly passing this cluster to ocfs2_zero_range_for_truncate() to zero out. This will modify the cluster in place and zero it in the source too. Fix this by skipping this cluster in such a scenario. To reproduce: 1. Create a random file of say 10 MB xfs_io -c 'pwrite -b 4k 0 10M' -f 10MBfile 2. Reflink it reflink -f 10MBfile reflnktest 3. Punch a hole at starting at cluster boundary with range greater that 1MB. You can also use a range that will put the end offset in another extent. fallocate -p -o 0 -l 1048615 reflnktest 4. sync 5. Check the first cluster in the source file. (It will be zeroed out). dd if=10MBfile iflag=direct bs=<cluster size> count=1 | hexdump -C Link: http://lkml.kernel.org/r/1470957147-14185-1-git-send-email-ashish.samant@oracle.comSigned-off-by:
Ashish Samant <ashish.samant@oracle.com> Reported-by:
Saar Maoz <saar.maoz@oracle.com> Reviewed-by:
Srinivas Eeda <srinivas.eeda@oracle.com> Cc: Mark Fasheh <mfasheh@versity.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Joseph Qi <joseph.qi@huawei.com> Cc: Eric Ren <zren@suse.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Joseph Qi authored
commit e6f0c6e6 upstream. Commit ac7cf246 ("ocfs2/dlm: fix race between convert and recovery") checks if lockres master has changed to identify whether new master has finished recovery or not. This will introduce a race that right after old master does umount ( means master will change), a new convert request comes. In this case, it will reset lockres state to DLM_RECOVERING and then retry convert, and then fail with lockres->l_action being set to OCFS2_AST_INVALID, which will cause inconsistent lock level between ocfs2 and dlm, and then finally BUG. Since dlm recovery will clear lock->convert_pending in dlm_move_lockres_to_recovery_list, we can use it to correctly identify the race case between convert and recovery. So fix it. Fixes: ac7cf246 ("ocfs2/dlm: fix race between convert and recovery") Link: http://lkml.kernel.org/r/57CE1569.8010704@huawei.comSigned-off-by:
Joseph Qi <joseph.qi@huawei.com> Signed-off-by:
Jun Piao <piaojun@huawei.com> Cc: Mark Fasheh <mfasheh@versity.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
- 29 Sep, 2016 31 commits
-
-
Herbert Xu authored
commit acdb04d0 upstream. When we need to allocate a temporary blkcipher_walk_next and it fails, the code is supposed to take the slow path of processing the data block by block. However, due to an unrelated change we instead end up dereferencing the NULL pointer. This patch fixes it by moving the unrelated bsize setting out of the way so that we enter the slow path as inteded. Fixes: 7607bd8f ("[CRYPTO] blkcipher: Added blkcipher_walk_virt_block") Reported-by:
xiakaixu <xiakaixu@huawei.com> Reported-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Tested-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Jeff Mahoney authored
commit 0a11b9aa upstream. new_insert_key only makes any sense when it's associated with a new_insert_ptr, which is initialized to NULL and changed to a buffer_head when we also initialize new_insert_key. We can key off of that to avoid the uninitialized warning. Link: http://lkml.kernel.org/r/5eca5ffb-2155-8df2-b4a2-f162f105efed@suse.comSigned-off-by:
Jeff Mahoney <jeffm@suse.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Jan Kara <jack@suse.cz> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Arnd Bergmann authored
commit c87bf431 upstream. Enabling CONFIG_GCOV_PROFILE_ALL produces us a lot of warnings like lib/lz4/lz4hc_compress.c: In function 'lz4_compresshcctx': lib/lz4/lz4hc_compress.c:514:1: warning: the frame size of 1504 bytes is larger than 1024 bytes [-Wframe-larger-than=] After some investigation, I found that this behavior started with gcc-4.9, and opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69702. A suggested workaround for it is to use the -fno-tree-loop-im flag that turns off one of the optimization stages in gcc, so the code runs a little slower but does not use excessive amounts of stack. We could make this conditional on the gcc version, but I could not find an easy way to do this in Kbuild and the benefit would be fairly small, given that most of the gcc version in production are affected now. I'm marking this for 'stable' backports because it addresses a bug with code generation in gcc that exists in all kernel versions with the affected gcc releases. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Peter Oberparleiter <oberpar@linux.vnet.ibm.com> Signed-off-by:
Michal Marek <mmarek@suse.com> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Jiri Slaby authored
-
Guenter Roeck authored
commit 8e4b7205 upstream. Since commit acb2505d ("openrisc: fix copy_from_user()"), copy_from_user() returns the number of bytes requested, not the number of bytes not copied. Cc: Al Viro <viro@zeniv.linux.org.uk> Fixes: acb2505d ("openrisc: fix copy_from_user()") Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Guenter Roeck authored
commit 65c0044c upstream. avr32 builds fail with: arch/avr32/kernel/built-in.o: In function `arch_ptrace': (.text+0x650): undefined reference to `___copy_from_user' arch/avr32/kernel/built-in.o:(___ksymtab+___copy_from_user+0x0): undefined reference to `___copy_from_user' kernel/built-in.o: In function `proc_doulongvec_ms_jiffies_minmax': (.text+0x5dd8): undefined reference to `___copy_from_user' kernel/built-in.o: In function `proc_dointvec_minmax_sysadmin': sysctl.c:(.text+0x6174): undefined reference to `___copy_from_user' kernel/built-in.o: In function `ptrace_has_cap': ptrace.c:(.text+0x69c0): undefined reference to `___copy_from_user' kernel/built-in.o:ptrace.c:(.text+0x6b90): more undefined references to `___copy_from_user' follow Fixes: 8630c322 ("avr32: fix copy_from_user()") Cc: Al Viro <viro@zeniv.linux.org.uk> Acked-by:
Havard Skinnemoen <hskinnemoen@gmail.com> Acked-by:
Hans-Christian Noren Egtvedt <egtvedt@samfundet.no> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit a5e541f7 upstream. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit 22426465 upstream. should clear on access_ok() failures. Also remove the useless range truncation logics. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit 917400ce upstream. Acked-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit ae7cc577 upstream. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit acb2505d upstream. ... that should zero on faults. Also remove the <censored> helpful logics wrt range truncation copied from ppc32. Where it had ever been needed only in case of copy_from_user() *and* had not been merged into the mainline until a month after the need had disappeared. A decade before openrisc went into mainline, I might add... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit aace880f upstream. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit 8ae95ed4 upstream. Acked-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit 2561d309 upstream. it should clear the destination even when access_ok() fails. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit 2545e5da upstream. ... in all cases, including the failing access_ok() Note that some architectures using asm-generic/uaccess.h have __copy_from_user() not zeroing the tail on failure halfway through. This variant works either way. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit e69d7005 upstream. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit f35c1e06 upstream. It's -EFAULT, not -1 (and contrary to the comment in there, __strnlen_user() can return 0 - on faults). Acked-by:
Richard Kuo <rkuo@codeaurora.org> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit 6e050503 upstream. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit b615e3c7 upstream. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit 8f035983 upstream. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit eb47e029 upstream. * copy_from_user() on access_ok() failure ought to zero the destination * none of those primitives should skip the access_ok() check in case of small constant size. Acked-by:
Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit 3b8767a8 upstream. It should check access_ok(). Otherwise a bunch of places turn into trivially exploitable rootholes. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit 9ad18b75 upstream. both for access_ok() failures and for faults halfway through Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Vineet Gupta authored
commit 05d9d0b9 upstream. Al reported potential issue with ARC get_user() as it wasn't clearing out destination pointer in case of fault due to bad address etc. Verified using following | { | u32 bogus1 = 0xdeadbeef; | u64 bogus2 = 0xdead; | int rc1, rc2; | | pr_info("Orig values %x %llx\n", bogus1, bogus2); | rc1 = get_user(bogus1, (u32 __user *)0x40000000); | rc2 = get_user(bogus2, (u64 __user *)0x50000000); | pr_info("access %d %d, new values %x %llx\n", | rc1, rc2, bogus1, bogus2); | } | [ARCLinux]# insmod /mnt/kernel-module/qtn.ko | Orig values deadbeef dead | access -14 -14, new values 0 0 Reported-by:
Al Viro <viro@ZenIV.linux.org.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: linux-snps-arc@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit fd2d2b19 upstream. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit c2f18fa4 upstream. * should zero on any failure * __get_user() should use __copy_from_user(), not copy_from_user() Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit c6852389 upstream. It could be done in exception-handling bits in __get_user_b() et.al., but the surgery involved would take more knowledge of sh64 details than I have or _want_ to have. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit c90a3bc5 upstream. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit 43403eab upstream. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit 1c109fab upstream. get_user_ex(x, ptr) should zero x on failure. It's not a lot of a leak (at most we are leaking uninitialized 64bit value off the kernel stack, and in a fairly constrained situation, at that), but the fix is trivial, so... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> [ This sat in different branch from the uaccess fixes since mid-August ] Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Al Viro authored
commit d0cf3851 upstream. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-