aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* ARM: 8158/1: LLVMLinux: use static inline in ARM ftrace.hBehan Webster2018-11-292-6/+1
| | | | | | | | | | | | | With compilers which follow the C99 standard (like modern versions of gcc and clang), "extern inline" does the wrong thing (emits code for an externally linkable version of the inline function). In this case using static inline and removing the NULL version of return_address in return_address.c does the right thing. Signed-off-by: Behan Webster <behanw@converseincode.com> Reviewed-by: Mark Charlebois <charlebm@gmail.com> Acked-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* USB: core: only clean up what we allocatedAndrey Konovalov2018-11-291-3/+6
| | | | | | | | | | | | | | | When cleaning up the configurations, make sure we only free the number of configurations and interfaces that we could have allocated. Change-Id: I07a2ddd088264030544284ad9680cd6d2b538d21 Reported-by: Andrey Konovalov <andreyknvl@google.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Git-commit: 32fd87b3bbf5f7a045546401dfe2894dbbf4d8c3 Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Signed-off-by: Srinivasa Rao Kuppala <srkupp@codeaurora.org> Signed-off-by: Dheeraj Kumar Chaudhary <dheech@codeaurora.org> Signed-off-by: Richard JK <rjk@codeaurora.org>
* genalloc: Correct nbytes calculation on long boundarySunil Khatri2018-11-291-1/+1
| | | | | | | | | | | | | | | | | | | In existing code we calculate nbytes based on the byte boundary, but genalloc uses bitmap for maintaining the memory allocation aligned to long. So while calculating nbytes we end up getting wrong nbytes. example: lets say nbytes comes to 9 bytes for 70 bits when bytes aligned,but if long aligned we will have 3 long words i.e 12 bytes. This difference may lead to choosing the wrong api for freeing the memory i.e Between kfree() and vfree(). Fix was inspired by an upstream commit eedce141cd2dad8d0cefc5468ef41898949a7031, bringing same fix into the gen_pool_detroy path. Change-Id: I942caf59e25515c780896b328b912604df9e10bf Signed-off-by: Hareesh Gundu <hareeshg@codeaurora.org> Signed-off-by: Sunil Khatri <sunilkh@codeaurora.org>
* lib: genalloc: Change chunk allocation to vmallocShubhraprakash Das2018-11-291-2/+14
| | | | | | | | | | | | | | | Change the chunk allocation from kmalloc to vmalloc for allocations greater than a page. This allows large chunks to be allocated from physically non-contiguous memory and increases the chance of the allocation succeeding. CRs-fixed: 387655 Signed-off-by: Shubhraprakash Das <sadas@codeaurora.org> (cherry picked from commit e461457b134e55c3ca68b91b70b8796e3f3dba69) Change-Id: I576fed3dd33fdfa9742f0c91bea72417c4f0086f Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
* lib/scatterlist: error handling in __sg_alloc_table()Dan Carpenter2018-11-291-2/+4
| | | | | | | | | | | | | | | | | | I was reviewing code which I suspected might allocate a zero size SG table. That will cause memory corruption. Also we can't return before doing the memset or we could end up using uninitialized memory in the cleanup path. Change-Id: Icee6be8ea22644d7f16264d9d2a0887c7145996b CRs-Fixed: 611562 Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: Akinobu Mita <akinobu.mita@gmail.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Tejun Heo <tj@kernel.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* lib/lzo: huge LZO decompression speedup on ARM by using unaligned accessMarkus F.X.J. Oberhumer2018-11-292-0/+10
| | | | | Change-Id: Ie9ded24e1e23580fdba479273f213ef65aff13fc Signed-off-by: Markus F.X.J. Oberhumer <markus@oberhumer.com>
* driver: ltr559 fix defineMoyster2018-11-291-2/+2
|
* drivers: meizu: fix meizu-sensors.c (warning: type qualifiers ignored)Moyster2018-11-291-1/+1
|
* include: remove redefine in fb.h (CONFIG_DMA_SHARED_BUFFER)Moyster2018-11-291-2/+0
|
* drivers: meizu: turn off meizu-sensors.c DEBUG flag (no more stupid ↵Moyster2018-11-291-2/+2
| | | | pr_*/dev_* redefine warnings)
* sound: core: fix warning: this 'if' clause does not guard...Moyster2018-11-291-2/+4
| | | | | | | | | | | | | | | | | | [-Wmisleading-indentation] in function 'snd_timer_user_read' /home/oyster/Github/android_kernel_m2note/sound/core/timer.c: In function 'snd_timer_user_read': /home/oyster/Github/android_kernel_m2note/sound/core/timer.c:1986:4: warning: this 'if' clause does not guard... [-Wmisleading-indentation] if (copy_to_user(buffer, &tu->tqueue[qhead], ^~ /home/oyster/Github/android_kernel_m2note/sound/core/timer.c:1989:5: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if' err = -EFAULT; ^~~ /home/oyster/Github/android_kernel_m2note/sound/core/timer.c:1991:4: warning: this 'if' clause does not guard... [-Wmisleading-indentation] if (copy_to_user(buffer, &tu->queue[qhead], ^~ /home/oyster/Github/android_kernel_m2note/sound/core/timer.c:1994:5: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if' err = -EFAULT; ^~~
* arm64: kuser32-bit helpers: dont include unistd32.hAmit Pundir2018-11-291-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While building lsk-3.10-android branch, we run into a series of build warnings for arm64 arch: ---------- In file included from arch/arm64/kernel/kuser32.S:32:0: arch/arm64/include/asm/unistd32.h:24:0: warning: "__NR_restart_syscall" redefined #define __NR_restart_syscall 0 ^ In file included from include/asm-generic/unistd.h:1:0, from arch/arm64/include/uapi/asm/unistd.h:16, from arch/arm64/include/asm/unistd.h:50, from arch/arm64/kernel/kuser32.S:31: include/uapi/asm-generic/unistd.h:390:0: note: this is the location of the previous definition #define __NR_restart_syscall 128 ^ In file included from arch/arm64/kernel/kuser32.S:32:0: arch/arm64/include/asm/unistd32.h:26:0: warning: "__NR_exit" redefined #define __NR_exit 1 ^ In file included from include/asm-generic/unistd.h:1:0, from arch/arm64/include/uapi/asm/unistd.h:16, from arch/arm64/include/asm/unistd.h:50, from arch/arm64/kernel/kuser32.S:31: include/uapi/asm-generic/unistd.h:292:0: note: this is the location of the previous definition #define __NR_exit 93 ^ ---------- This fix removes asm/unitstd32.h include to avoid duplication of "__NR_" syscall definitions. It is based on mainline commit: f3e5c847ec3d "arm64: Add __NR_* definitions for compat syscalls". The corresponding change in AOSP (commit: cfc7e99e9e39, "arm64: Add..") seem to be the early version or backport of the above mainline commit to aosp/android-3.10. The only difference between mainline and aosp commit is that the latter didn't have to deal with that problematic include because it is not present in aosp/android-3.10 unlike mainline or lsk-v3.10-android tree. Signed-off-by: Amit Pundir <amit.pundir@linaro.org> Signed-off-by: Kevin Hilman <khilman@linaro.org>
* GCC: Fix up for gcc 5+mydongistiny2018-11-2934-4/+61
| | | | | Signed-off-by: mydongistiny <jaysonedson@gmail.com> Signed-off-by: Mister Oyster <oysterized@gmail.com>
* ANDROID: HID: debug: check length in hid_debug_events_read() before ↵Daniel Rosenberg2018-11-291-1/+7
| | | | | | | | | | | copy_to_user() If our length is greater than the size of the buffer, we overflow the buffer Change-Id: I113a1955a2bac83c83084d5cd28d886175673219 Bug: 71361580 Signed-off-by: Daniel Rosenberg <drosen@google.com>
* makefile: Add --strip-debug flagWilli Ye2018-11-291-1/+1
| | | | This should fix the size of qcacld-2.0 module
* kbuild: Support split debug info v4Andi Kleen2018-11-292-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is an alternative approach to lower the overhead of debug info (as we discussed a few days ago) gcc 4.7+ and newer binutils have a new "split debug info" debug info model where the debug info is only written once into central ".dwo" files. This avoids having to copy it around multiple times, from the object files to the final executable. It lowers the disk space requirements. In addition it defaults to compressed debug data. More details here: http://gcc.gnu.org/wiki/DebugFission This patch adds a new option to enable it. It has to be an option, because it'll undoubtedly break everyone's debuginfo packaging scheme. gdb/objdump/etc. all still work, if you have new enough versions. I don't see big compile wins (maybe a second or two faster or so), but the object dirs with debuginfo get significantly smaller. My standard kernel config (slightly bigger than defconfig) shrinks from 2.9G disk space to 1.1G objdir (with non reduced debuginfo). I presume if you are IO limited the compile time difference will be larger. Only problem I've seen so far is that it doesn't play well with older versions of ccache (apparently fixed, see https://bugzilla.samba.org/show_bug.cgi?id=10005) v2: various fixes from Dirk Gouders. Improve commit message slightly. v3: Fix clean rules and improve Kconfig slightly v4: Fix merge error in last version (Sam Ravnborg) Clarify description that it mainly helps disk size. Cc: Dirk Gouders <dirk@gouders.net> Signed-off-by: Andi Kleen <ak@linux.intel.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Michal Marek <mmarek@suse.cz>
* kbuild: LLVMLinux: Add Kbuild support for building kernel with ClangBehan Webster2018-11-291-0/+29
| | | | | | | | | | | | | | | Add support to toplevel Makefile for compiling with clang, both for HOSTCC and CC. Use cc-option to prevent gcc option from breaking clang, and from clang options from breaking gcc. Clang 3.4 semantics are the same as gcc semantics for unsupported flags. For unsupported warnings clang 3.4 returns true but shows a warning and gcc shows a warning and returns false. Signed-off-by: Behan Webster <behanw@converseincode.com> Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de> Signed-off-by: Mark Charlebois <charlebm@gmail.com> Cc: PaX Team <pageexec@freemail.hu>
* ./Makefile: tell gcc optimizer to never introduce new data racesJiri Kosina2018-11-291-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have been chasing a memory corruption bug, which turned out to be caused by very old gcc (4.3.4), which happily turned conditional load into a non-conditional one, and that broke correctness (the condition was met only if lock was held) and corrupted memory. This particular problem with that particular code did not happen when never gccs were used. I've brought this up with our gcc folks, as I wanted to make sure that this can't really happen again, and it turns out it actually can. Quoting Martin Jambor <mjambor@suse.cz>: "More current GCCs are more careful when it comes to replacing a conditional load with a non-conditional one, most notably they check that a store happens in each iteration of _a_ loop but they assume loops are executed. They also perform a simple check whether the store cannot trap which currently passes only for non-const variables. A simple testcase demonstrating it on an x86_64 is for example the following: $ cat cond_store.c int g_1 = 1; int g_2[1024] __attribute__((section ("safe_section"), aligned (4096))); int c = 4; int __attribute__ ((noinline)) foo (void) { int l; for (l = 0; (l != 4); l++) { if (g_1) return l; for (g_2[0] = 0; (g_2[0] >= 26); ++g_2[0]) ; } return 2; } int main (int argc, char* argv[]) { if (mprotect (g_2, sizeof(g_2), PROT_READ) == -1) { int e = errno; error (e, e, "mprotect error %i", e); } foo (); __builtin_printf("OK\n"); return 0; } /* EOF */ $ ~/gcc/trunk/inst/bin/gcc cond_store.c -O2 --param allow-store-data-races=0 $ ./a.out OK $ ~/gcc/trunk/inst/bin/gcc cond_store.c -O2 --param allow-store-data-races=1 $ ./a.out Segmentation fault The testcase fails the same at least with 4.9, 4.8 and 4.7. Therefore I would suggest building kernels with this parameter set to zero. I also agree with Jikos that the default should be changed for -O2. I have run most of the SPEC 2k6 CPU benchmarks (gamess and dealII failed, at -O2, not sure why) compiled with and without this option and did not see any real difference between respective run-times" Hopefully the default will be changed in newer gccs, but let's force it for kernel builds so that we are on a safe side even when older gcc are used. The code in question was out-of-tree printk-in-NMI (yeah, surprise suprise, once again) patch written by Petr Mladek, let me quote his comment from our internal bugzilla: "I have spent few days investigating inconsistent state of kernel ring buffer. It went out that it was caused by speculative store generated by gcc-4.3.4. The problem is in assembly generated for make_free_space(). The functions is called the following way: + vprintk_emit(); + log = MAIN_LOG; // with logbuf_lock or log = NMI_LOG; // with nmi_logbuf_lock cont_add(log, ...); + cont_flush(log, ...); + log_store(log, ...); + log_make_free_space(log, ...); If called with log = NMI_LOG then only nmi_log_* global variables are safe to modify but the generated code does store also into (main_)log_* global variables: <log_make_free_space>: 55 push %rbp 89 f6 mov %esi,%esi 48 8b 05 03 99 51 01 mov 0x1519903(%rip),%rax # ffffffff82620868 <nmi_log_next_id> 44 8b 1d ec 98 51 01 mov 0x15198ec(%rip),%r11d # ffffffff82620858 <log_next_idx> 8b 35 36 60 14 01 mov 0x1146036(%rip),%esi # ffffffff8224cfa8 <log_buf_len> 44 8b 35 33 60 14 01 mov 0x1146033(%rip),%r14d # ffffffff8224cfac <nmi_log_buf_len> 4c 8b 2d d0 98 51 01 mov 0x15198d0(%rip),%r13 # ffffffff82620850 <log_next_seq> 4c 8b 25 11 61 14 01 mov 0x1146111(%rip),%r12 # ffffffff8224d098 <log_buf> 49 89 c2 mov %rax,%r10 48 21 c2 and %rax,%rdx 48 8b 1d 0c 99 55 01 mov 0x155990c(%rip),%rbx # ffffffff826608a0 <nmi_log_buf> 49 c1 ea 20 shr $0x20,%r10 48 89 55 d0 mov %rdx,-0x30(%rbp) 44 29 de sub %r11d,%esi 45 29 d6 sub %r10d,%r14d 4c 8b 0d 97 98 51 01 mov 0x1519897(%rip),%r9 # ffffffff82620840 <log_first_seq> eb 7e jmp ffffffff81107029 <log_make_free_space+0xe9> [...] 85 ff test %edi,%edi # edi = 1 for NMI_LOG 4c 89 e8 mov %r13,%rax 4c 89 ca mov %r9,%rdx 74 0a je ffffffff8110703d <log_make_free_space+0xfd> 8b 15 27 98 51 01 mov 0x1519827(%rip),%edx # ffffffff82620860 <nmi_log_first_id> 48 8b 45 d0 mov -0x30(%rbp),%rax 48 39 c2 cmp %rax,%rdx # end of loop 0f 84 da 00 00 00 je ffffffff81107120 <log_make_free_space+0x1e0> [...] 85 ff test %edi,%edi # edi = 1 for NMI_LOG 4c 89 0d 17 97 51 01 mov %r9,0x1519717(%rip) # ffffffff82620840 <log_first_seq> ^^^^^^^^^^^^^^^^^^^^^^^^^^ KABOOOM 74 35 je ffffffff81107160 <log_make_free_space+0x220> It stores log_first_seq when edi == NMI_LOG. This instructions are used also when edi == MAIN_LOG but the store is done speculatively before the condition is decided. It is unsafe because we do not have "logbuf_lock" in NMI context and some other process migh modify "log_first_seq" in parallel" I believe that the best course of action is both - building kernel (and anything multi-threaded, I guess) with that optimization turned off - persuade gcc folks to change the default for future releases Signed-off-by: Jiri Kosina <jkosina@suse.cz> Cc: Martin Jambor <mjambor@suse.cz> Cc: Petr Mladek <pmladek@suse.cz> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Marek Polacek <polacek@redhat.com> Cc: Jakub Jelinek <jakub@redhat.com> Cc: Steven Noonan <steven@uplinklabs.net> Cc: Richard Biener <richard.guenther@gmail.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* turn off -Wattribute-aliasArnd Bergmann2018-11-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Starting with gcc-8.1, we get a warning about all system call definitions, which use an alias between functions with incompatible prototypes, e.g.: In file included from ../mm/process_vm_access.c:19: ../include/linux/syscalls.h:211:18: warning: 'sys_process_vm_readv' alias between functions of incompatible types 'long int(pid_t, const struct iovec *, long unsigned int, const struct iovec *, long unsigned int, long unsigned int)' {aka 'long int(int, const struct iovec *, long unsigned int, const struct iovec *, long unsigned int, long unsigned int)'} and 'long int(long int, long int, long int, long int, long int, long int)' [-Wattribute-alias] asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \ ^~~ ../include/linux/syscalls.h:207:2: note: in expansion of macro '__SYSCALL_DEFINEx' __SYSCALL_DEFINEx(x, sname, __VA_ARGS__) ^~~~~~~~~~~~~~~~~ ../include/linux/syscalls.h:201:36: note: in expansion of macro 'SYSCALL_DEFINEx' #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__) ^~~~~~~~~~~~~~~ ../mm/process_vm_access.c:300:1: note: in expansion of macro 'SYSCALL_DEFINE6' SYSCALL_DEFINE6(process_vm_readv, pid_t, pid, const struct iovec __user *, lvec, ^~~~~~~~~~~~~~~ ../include/linux/syscalls.h:215:18: note: aliased declaration here asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \ ^~~ ../include/linux/syscalls.h:207:2: note: in expansion of macro '__SYSCALL_DEFINEx' __SYSCALL_DEFINEx(x, sname, __VA_ARGS__) ^~~~~~~~~~~~~~~~~ ../include/linux/syscalls.h:201:36: note: in expansion of macro 'SYSCALL_DEFINEx' #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__) ^~~~~~~~~~~~~~~ ../mm/process_vm_access.c:300:1: note: in expansion of macro 'SYSCALL_DEFINE6' SYSCALL_DEFINE6(process_vm_readv, pid_t, pid, const struct iovec __user *, lvec, This is really noisy and does not indicate a real problem. In the latest mainline kernel, this was addressed by commit bee20031772a ("disable -Wattribute-alias warning for SYSCALL_DEFINEx()"), which seems too invasive to backport. This takes a much simpler approach and just disables the warning across the kernel. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* disable new gcc-7.1.1 warnings for nowLinus Torvalds2018-11-291-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | commit bd664f6b3e376a8ef4990f87d08271cc2d01ba9a upstream. I made the mistake of upgrading my desktop to the new Fedora 26 that comes with gcc-7.1.1. There's nothing wrong per se that I've noticed, but I now have 1500 lines of warnings, mostly from the new format-truncation warning triggering all over the tree. We use 'snprintf()' and friends in a lot of places, and often know that the numbers are fairly small (ie a controller index or similar), but gcc doesn't know that, and sees an 'int', and thinks that it could be some huge number. And then complains when our buffers are not able to fit the name for the ten millionth controller. These warnings aren't necessarily bad per se, and we probably want to look through them subsystem by subsystem, but at least during the merge window they just mean that I can't even see if somebody is introducing any *real* problems when I pull. So warnings disabled for now. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Disable "frame-address" warningLinus Torvalds2018-11-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 124a3d88fa20e1869fc229d7d8c740cc81944264 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* kbuild: add -fno-PIESebastian Andrzej Siewior2018-11-291-1/+2
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit 8ae94224c9d72fc4d9aaac93b2d7833cf46d7141 ] Debian started to build the gcc with -fPIE by default so the kernel build ends before it starts properly with: |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Also add to KBUILD_AFLAGS due to: |gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d … -mfentry -DCC_USING_FENTRY … vdso/vdso32/note.S |arch/x86/entry/vdso/vdso32/note.S:1:0: sorry, unimplemented: -mfentry isn’t supported for 32-bit in combination with -fpic Tagging it stable so it is possible to compile recent stable kernels as well. Cc: stable@vger.kernel.org Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Michal Marek <mmarek@suse.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
* Makefile: Fix unrecognized cross-compiler command line optionsGeert Uytterhoeven2018-11-291-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | On architectures that setup CROSS_COMPILE in their arch/*/Makefile (arc, blackfin, m68k, mips, parisc, score, sh, tile, unicore32, xtensa), cc-option and cc-disable-warning may check against the wrong compiler, causing errors like cc1: error: unrecognized command line option "-Wno-maybe-uninitialized" if the host gcc supports a compiler option, while the cross compiler doesn't support that option. Move all logic using cc-option or cc-disable-warning below the inclusion of the arch's Makefile to fix this. Introduced by - commit e74fc973b6e531fef1fce8b101ffff05ecfb774c ("Turn off -Wmaybe-uninitialized when building with -Os"), - commit 61163efae02040f66a95c8ed17f4407951ba58fa ("kbuild: LLVMLinux: Add Kbuild support for building kernel with Clang"). As -Wno-maybe-uninitialized requires a quite recent gcc (gcc 4.6.3 on Ubuntu 12.04 LTS doesn't support it), this only showed up recently (gcc 4.8.2 on Ubuntu 14.04 LTS does support it). Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Michal Marek <mmarek@suse.cz>
* ARM: fix put_user() for gcc-8Arnd Bergmann2018-11-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Building kernels before linux-4.7 with gcc-8 results in many build failures when gcc triggers a check that was meant to catch broken compilers: /tmp/ccCGMQmS.s:648: Error: .err encountered According to the discussion in the gcc bugzilla, a local "register asm()" variable is still supposed to be the correct way to force an inline assembly to use a particular register, but marking it 'const' lets the compiler do optimizations that break that, i.e the compiler is free to treat the variable as either 'const' or 'register' in that case. Upstream commit 9f73bd8bb445 ("ARM: uaccess: remove put_user() code duplication") fixed this problem in linux-4.8 as part of a larger change, but seems a little too big to be backported to 4.4. Let's take the simplest fix and change only the one broken line in the same way as newer kernels. Suggested-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85745 Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86673 Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* FROMLIST: ANDROID: binder: Add BINDER_GET_NODE_INFO_FOR_REF ioctl.Martijn Coenen2018-11-292-0/+65
| | | | | | | | | | | | | | This allows the context manager to retrieve information about nodes that it holds a reference to, such as the current number of references to those nodes. Such information can for example be used to determine whether the servicemanager is the only process holding a reference to a node. This information can then be passed on to the process holding the node, which can in turn decide whether it wants to shut down to reduce resource usage. Signed-off-by: Martijn Coenen <maco@android.com>
* UPSTREAM: binder: replace "%p" with "%pK"Todd Kjos2018-11-291-4/+4
| | | | | | | | | | | | The format specifier "%p" can leak kernel addresses. Use "%pK" instead. There were 4 remaining cases in binder.c. Signed-off-by: Todd Kjos <tkjos@google.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 8ca86f1639ec5890d400fff9211aca22d0a392eb) Change-Id: I309241853c53bcdfa65c17cb05876e786597afdd
* UPSTREAM: binder: free memory on errorChristian Brauner2018-11-291-2/+6
| | | | | | | | | | | | | On binder_init() the devices string is duplicated and smashed into individual device names which are passed along. However, the original duplicated string wasn't freed in case binder_init() failed. Let's free it on error. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 22eb9476b5d80a393ac0ba235c42bccc90b82c76) Change-Id: I78fdeecf70c31ba4248b3de17130f97546288f84
* UPSTREAM: ANDROID: binder: change down_write to down_readMinchan Kim2018-11-292-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | binder_update_page_range needs down_write of mmap_sem because vm_insert_page need to change vma->vm_flags to VM_MIXEDMAP unless it is set. However, when I profile binder working, it seems every binder buffers should be mapped in advance by binder_mmap. It means we could set VM_MIXEDMAP in binder_mmap time which is already hold a mmap_sem as down_write so binder_update_page_range doesn't need to hold a mmap_sem as down_write. Please use proper API down_read. It would help mmap_sem contention problem as well as fixing down_write abuse. Ganesh Mahendran tested app launching and binder throughput test and he said he couldn't find any problem and I did binder latency test per Greg KH request(Thanks Martijn to teach me how I can do) I cannot find any problem, too. Cc: Ganesh Mahendran <opensource.ganesh@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Arve Hjønnevåg <arve@android.com> Cc: Todd Kjos <tkjos@google.com> Reviewed-by: Martijn Coenen <maco@android.com> Signed-off-by: Minchan Kim <minchan@kernel.org> Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 720c241924046aff83f5f2323232f34a30a4c281) Change-Id: I8358ceaaab4030f7122c95308dcad59557cad411
* UPSTREAM: ANDROID: binder: correct the cmd print for BINDER_WORK_RETURN_ERROR宋金时2018-11-291-0/+1
| | | | | | | | | | | | | | | When to execute binder_stat_br the e->cmd has been modifying as BR_OK instead of the original return error cmd, in fact we want to know the original return error, such as BR_DEAD_REPLY or BR_FAILED_REPLY, etc. instead of always BR_OK, in order to avoid the value of the e->cmd is always BR_OK, so we need assign the value of the e->cmd to cmd before e->cmd = BR_OK. Signed-off-by: songjinshi <songjinshi@xiaomi.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 838d5565669aa5bb7deb605684a5970d51d5eaf6) Change-Id: I425b32c5419a491c6b9ceee7c00dde6513e0421d
* UPSTREAM: ANDROID: binder: remove 32-bit binder interface.Martijn Coenen2018-11-292-18/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | New devices launching with Android P need to use the 64-bit binder interface, even on 32-bit SoCs [0]. This change removes the Kconfig option to select the 32-bit binder interface. We don't think this will affect existing userspace for the following reasons: 1) The latest Android common tree is 4.14, so we don't believe any Android devices are on kernels >4.14. 2) Android devices launch on an LTS release and stick with it, so we wouldn't expect devices running on <= 4.14 now to upgrade to 4.17 or later. But even if they did, they'd rebuild the world (kernel + userspace) anyway. 3) Other userspaces like 'anbox' are already using the 64-bit interface. Note that this change doesn't remove the 32-bit UAPI itself; the reason for that is that Android userspace always uses the latest UAPI headers from upstream, and userspace retains 32-bit support for devices that are upgrading. This will be removed as well in 2-3 years, at which point we can remove the code from the UAPI as well. Finally, this change introduces build errors on archs where 64-bit get_user/put_user is not supported, so make binder unavailable on m68k (which wouldn't want it anyway). [0]: https://android-review.googlesource.com/c/platform/build/+/595193 Signed-off-by: Martijn Coenen <maco@android.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 1190b4e38f97023154e6b3bef61b251aa5f970d0) Change-Id: I73dadf1d7b45a42bb18be5d5d3f5c090e61866de
* UPSTREAM: ANDROID: binder: re-order some conditionsDan Carpenter2018-11-291-2/+2
| | | | | | | | | | | | | | | | It doesn't make any difference to runtime but I've switched these two checks to make my static checker happy. The problem is that "buffer->data_size" is user controlled and if it's less than "sizeo(*hdr)" then that means "offset" can be more than "buffer->data_size". It's just cleaner to check it in the other order. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Martijn Coenen <maco@android.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 361f2ddbb0c9f9b4f336025a7bd0212cea4a34f0) Change-Id: I098d525ba63d125caa9840e6e1d5004bf70edc3c
* UPSTREAM: android: binder: use VM_ALLOC to get vm areaGanesh Mahendran2018-11-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VM_IOREMAP is used to access hardware through a mechanism called I/O mapped memory. Android binder is a IPC machanism which will not access I/O memory. And VM_IOREMAP has alignment requiement which may not needed in binder. __get_vm_area_node() { ... if (flags & VM_IOREMAP) align = 1ul << clamp_t(int, fls_long(size), PAGE_SHIFT, IOREMAP_MAX_ORDER); ... } This patch will save some kernel vm area, especially for 32bit os. In 32bit OS, kernel vm area is only 240MB. We may got below error when launching a app: <3>[ 4482.440053] binder_alloc: binder_alloc_mmap_handler: 15728 8ce67000-8cf65000 get_vm_area failed -12 <3>[ 4483.218817] binder_alloc: binder_alloc_mmap_handler: 15745 8ce67000-8cf65000 get_vm_area failed -12 Signed-off-by: Ganesh Mahendran <opensource.ganesh@gmail.com> Acked-by: Martijn Coenen <maco@android.com> Acked-by: Todd Kjos <tkjos@google.com> Cc: stable <stable@vger.kernel.org> ---- V3: update comments V2: update comments Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit aac6830ec1cb681544212838911cdc57f2638216) Change-Id: Ide458abc6a4d3ec07973733aa223c4247eef20e6
* UPSTREAM: android: binder: Use true and false for boolean valuesGustavo A. R. Silva2018-11-291-3/+3
| | | | | | | | | | | | | | | Assign true or false to boolean variables instead of an integer value. This issue was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Cc: Todd Kjos <tkjos@android.com> Cc: Martijn Coenen <maco@android.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 197410ad884eb18b31d48e9d8e64cb5a9e326f2f) Change-Id: I30bed831d6b6ff2e9e3e521ccc5d6836f0b30944 Signed-off-by: Moyster <oysterized@gmail.com>
* UPSTREAM: android: binder: Use octal permissionsHarsh Shandilya2018-11-291-8/+8
| | | | | | | | | | | | | | | | | | checkpatch warns against the use of symbolic permissions, this patch migrates all symbolic permissions in the binder driver to octal permissions. Test: debugfs nodes created by binder have the same unix permissions prior to and after this patch was applied. Signed-off-by: Harsh Shandilya <harsh@prjkt.io> Cc: "Arve Hjønnevåg" <arve@android.com> Cc: Todd Kjos <tkjos@android.com> Cc: Martijn Coenen <maco@android.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 21d02ddf716669e182a13b69b4dd928cf8ef5e0f) Change-Id: I8152fe280ead1d04d89593e813a722f9eb5def27
* UPSTREAM: android: binder: Prefer __func__ to using hardcoded function nameElad Wexler2018-11-291-2/+2
| | | | | | | | | | Coding style fixup Signed-off-by: Elad Wexler <elad.wexler@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 00c41cddebde8d1a635bf81a7b255b7e56fd0d15) Change-Id: I795e2a9f525c4a8df5cd0a81842a88529ba54f21
* UPSTREAM: ANDROID: binder: make binder_alloc_new_buf_locked static and ↵Xiongwei Song2018-11-291-5/+6
| | | | | | | | | | | | | | | | | | | indent its arguments The function binder_alloc_new_buf_locked() is only used in this file, so make it static. Also clean up sparse warning: drivers/android/binder_alloc.c:330:23: warning: no previous prototype for ‘binder_alloc_new_buf_locked’ [-Wmissing-prototypes] In addition, the line of the function name exceeds 80 characters when add static for this function, hence indent its arguments anew. Signed-off-by: Xiongwei Song <sxwjean@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 3f827245463a57f5ef64a665e1ca64eed0da00a5) Change-Id: I6b379df815d30f9b3e9f1dd50334375123b25bbc
* UPSTREAM: ANDROID: binder: prevent transactions into own process.Martijn Coenen2018-11-291-0/+8
| | | | | | | | | | | | | This can't happen with normal nodes (because you can't get a ref to a node you own), but it could happen with the context manager; to make the behavior consistent with regular nodes, reject transactions into the context manager by the process owning it. Reported-by: syzbot+09e05aba06723a94d43d@syzkaller.appspotmail.com Signed-off-by: Martijn Coenen <maco@android.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 7aa135fcf26377f92dc0680a57566b4c7f3e281b)
* UPSTREAM: ANDROID: binder: remove WARN() for redundant txn errorTodd Kjos2018-11-291-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | binder_send_failed_reply() is called when a synchronous transaction fails. It reports an error to the thread that is waiting for the completion. Given that the transaction is synchronous, there should never be more than 1 error response to that thread -- this was being asserted with a WARN(). However, when exercising the driver with syzbot tests, cases were observed where multiple "synchronous" requests were sent without waiting for responses, so it is possible that multiple errors would be reported to the thread. This testing was conducted with panic_on_warn set which forced the crash. This is easily reproduced by sending back-to-back "synchronous" transactions without checking for any response (eg, set read_size to 0): bwr.write_buffer = (uintptr_t)&bc1; bwr.write_size = sizeof(bc1); bwr.read_buffer = (uintptr_t)&br; bwr.read_size = 0; ioctl(fd, BINDER_WRITE_READ, &bwr); sleep(1); bwr2.write_buffer = (uintptr_t)&bc2; bwr2.write_size = sizeof(bc2); bwr2.read_buffer = (uintptr_t)&br; bwr2.read_size = 0; ioctl(fd, BINDER_WRITE_READ, &bwr2); sleep(1); The first transaction is sent to the servicemanager and the reply fails because no VMA is set up by this client. After binder_send_failed_reply() is called, the BINDER_WORK_RETURN_ERROR is sitting on the thread's todo list since the read_size was 0 and the client is not waiting for a response. The 2nd transaction is sent and the BINDER_WORK_RETURN_ERROR has not been consumed, so the thread's reply_error.cmd is still set (normally cleared when the BINDER_WORK_RETURN_ERROR is handled). Therefore when the servicemanager attempts to reply to the 2nd failed transaction, the error is already set and it triggers this warning. This is a user error since it is not waiting for the synchronous transaction to complete. If it ever does check, it will see an error. Changed the WARN() to a pr_warn(). Signed-off-by: Todd Kjos <tkjos@android.com> Reported-by: syzbot <syzkaller@googlegroups.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit e46a3b3ba7509cb7fda0e07bc7c63a2cd90f579b) Change-Id: I3365b0775ceee37bdb1d868e3ce066c260aa88ea
* UPSTREAM: ANDROID: binder: synchronize_rcu() when using POLLFREE.Martijn Coenen2018-11-291-0/+9
| | | | | | | | | | | | | To prevent races with ep_remove_waitqueue() removing the waitqueue at the same time. Reported-by: syzbot+a2a3c4909716e271487e@syzkaller.appspotmail.com Signed-off-by: Martijn Coenen <maco@android.com> Cc: stable <stable@vger.kernel.org> # 4.14+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 5eeb2ca02a2f6084fc57ae5c244a38baab07033a) Change-Id: Ia0089448079c78d0ab0b57303faf838e9e5ee797
* UPSTREAM: ANDROID: binder: remove waitqueue when thread exits.Martijn Coenen2018-11-291-0/+12
| | | | | | | | | | | | | | | | | | | | | binder_poll() passes the thread->wait waitqueue that can be slept on for work. When a thread that uses epoll explicitly exits using BINDER_THREAD_EXIT, the waitqueue is freed, but it is never removed from the corresponding epoll data structure. When the process subsequently exits, the epoll cleanup code tries to access the waitlist, which results in a use-after-free. Prevent this by using POLLFREE when the thread exits. (cherry picked from commit f5cb779ba16334b45ba8946d6bfa6d9834d1527f) Change-Id: Ib34b1cbb8ab2192d78c3d9956b2f963a66ecad2e Signed-off-by: Martijn Coenen <maco@android.com> Reported-by: syzbot <syzkaller@googlegroups.com> Cc: stable <stable@vger.kernel.org> # 4.14 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* wmt:fix an invalid condition checkdanielhk2018-11-271-1/+1
| | | | Signed-off-by: Moyster <oysterized@gmail.com>
* Input: gtco - fix potential out-of-bound accessDmitry Torokhov2018-11-271-7/+10
| | | | | | | | | | | | | | | | commit a50829479f58416a013a4ccca791336af3c584c7 upstream. parse_hid_report_descriptor() has a while (i < length) loop, which only guarantees that there's at least 1 byte in the buffer, but the loop body can read multiple bytes which causes out-of-bounds access. Bug: 69916367 Change-Id: Ic6a2fda77685b90d7642c09b20f5d57d6d48b726 Reported-by: Andrey Konovalov <andreyknvl@google.com> Reviewed-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Siqi Lin <siqilin@google.com>
* Security Patch: WLAN Gen2: Security Vulnerability Issue 72312071David Chu2018-11-272-2/+10
| | | | | | | | | | | | | | | [Detail] Multiple Kernel Memory Corruption Issues in Mediatek cfg80211 Subsystem [Solution] In mtk_cfg80211_vendor_set_config the value num_buckets must be validated to ensure it is not greater than size of the buckets array. CVE-2018-9395 Change-Id: If07b758108922dd12ac4eb5d93ce2eab0ce06dae Signed-off-by: Ben Fennema <fennema@google.com> Signed-off-by: Moyster <oysterized@gmail.com>
* Security Patch: fix ioctl vulnerability for WMT_IOCTL_SET_PATCH_INFODavid Chu2018-11-271-4/+5
| | | | | | | | | | | | | [Detail] If dowloadSeq is 0, it'll pass the error handle and cause KE issue. [Solution] Add condition that downloadSeq can not equal to zero. CVE-2018-9397 Change-Id: I68a2d501c873c4d665634893066b6c0f03e1537c Signed-off-by: Ben Fennema <fennema@google.com>
* netfilter: ebtables: CONFIG_COMPAT: don't trust userland offsetsFlorian Westphal2018-11-271-1/+12
| | | | | | | | | | | | | | | | | | | | | commit b71812168571fa55e44cdd0254471331b9c4c4c6 upstream. We need to make sure the offsets are not out of range of the total size. Also check that they are in ascending order. The WARN_ON triggered by syzkaller (it sets panic_on_warn) is changed to also bail out, no point in continuing parsing. Briefly tested with simple ruleset of -A INPUT --limit 1/s' --log plus jump to custom chains using 32bit ebtables binary. Change-Id: I20f5a2f604ed8a7767cfe4f0d4c4e73914f072b3 Reported-by: <syzbot+845a53d13171abf8bf29@syzkaller.appspotmail.com> Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: replace %p with %pKManu Gautam2018-11-27104-620/+620
| | | | | | | | | | | | | | | Format specifier %p can leak kernel addresses while not valuing the kptr_restrict system settings. When kptr_restrict is set to (1), kernel pointers printed using the %pK format specifier will be replaced with 0's. Debugging Note : &pK prints only Zeros as address. If you need actual address information, write 0 to kptr_restrict. echo 0 > /proc/sys/kernel/kptr_restrict CRs-fixed: 1052849 Change-Id: I0e98145730380ea983fa8f46a28d15dd6c2c31df Signed-off-by: Manu Gautam <mgautam@codeaurora.org> Signed-off-by: Yasir Malik <ymalik@codeaurora.org> Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
* lib: vsprintf: default kptr_restrict to the maximum valueDave Weinstein2018-11-271-1/+1
| | | | | | | | | | | Set the initial value of kptr_restrict to the maximum setting rather than the minimum setting, to ensure that early boot logging is not leaking information. BUG: 30368199 Change-Id: If738e3b2ff85b737127daf16f2f3a722e616f389 Signed-off-by: Dave Weinstein <olorin@google.com> Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
* ANDROID: sdcardfs: Change current->fs under lockDaniel Rosenberg2018-11-271-2/+13
| | | | | | | | bug: 111641492 Change-Id: I79e9894f94880048edaf0f7cfa2d180f65cbcf3b Reported-by: Jann Horn <jannh@google.com> Signed-off-by: Daniel Rosenberg <drosen@google.com>
* ANDROID: sdcardfs: Don't use OVERRIDE_CRED macroDaniel Rosenberg2018-11-274-191/+66
| | | | | | | | | | | The macro hides some control flow, making it easier to run into bugs. bug: 111642636 Change-Id: I37ec207c277d97c4e7f1e8381bc9ae743ad78435 Reported-by: Jann Horn <jannh@google.com> Signed-off-by: Daniel Rosenberg <drosen@google.com>
* ANDROID: Revert "net: increase fragment memory usage limits"Greg Hackmann2018-11-272-17/+9
| | | | | | | | | This reverts commit c2a936600f78aea00d3312ea4b66a79a4619f9b4. Bug: 111983486 Change-Id: Ibc7a3076d7ec928dac27c2fd2d1bdaff6cb8c349 Signed-off-by: Greg Hackmann <ghackmann@google.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-03-16 12:33:12 +0000