summaryrefslogtreecommitdiffstats
path: root/Makefile
Commit message (Collapse)AuthorAgeFilesLines
* Linux 4.9.141v4.9.141Greg Kroah-Hartman2018-11-271-1/+1
|
* Linux 4.9.140v4.9.140Greg Kroah-Hartman2018-11-231-1/+1
|
* Linux 4.9.139v4.9.139Greg Kroah-Hartman2018-11-231-1/+1
|
* Kbuild: use -fshort-wchar globallyArnd Bergmann2018-11-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 8c97023cf0518f172b8cb7a9fffc28b89401abbf upstream. Commit 971a69db7dc0 ("Xen: don't warn about 2-byte wchar_t in efi") added the --no-wchar-size-warning to the Makefile to avoid this harmless warning: arm-linux-gnueabi-ld: warning: drivers/xen/efi.o uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail Changing kbuild to use thin archives instead of recursive linking unfortunately brings the same warning back during the final link. The kernel does not use wchar_t string literals at this point, and xen does not use wchar_t at all (only efi_char16_t), so the flag has no effect, but as pointed out by Jan Beulich, adding a wchar_t string literal would be bad here. Since wchar_t is always defined as u16, independent of the toolchain default, always passing -fshort-wchar is correct and lets us remove the Xen specific hack along with fixing the warning. Link: https://patchwork.kernel.org/patch/9275217/ Fixes: 971a69db7dc0 ("Xen: don't warn about 2-byte wchar_t in efi") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* kbuild: clang: Disable 'address-of-packed-member' warningMatthias Kaehlcke2018-11-231-0/+1
| | | | | | | | | | | | | | commit bfb38988c51e440fd7062ddf3157f7d8b1dd5d70 upstream. clang generates plenty of these warnings in different parts of the code, to an extent that the warnings are little more than noise. Disable the 'address-of-packed-member' warning. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* kbuild: Add __cc-option macroMatthias Kaehlcke2018-11-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | commit 9f3f1fd299768782465cb32cdf0dd4528d11f26b upstream. cc-option uses KBUILD_CFLAGS and KBUILD_CPPFLAGS when it determines whether an option is supported or not. This is fine for options used to build the kernel itself, however some components like the x86 boot code use a different set of flags. Add the new macro __cc-option which is a more generic version of cc-option with additional parameters. One parameter is the compiler with which the check should be performed, the other the compiler options to be used instead KBUILD_C*FLAGS. Refactor cc-option and hostcc-option to use __cc-option and move hostcc-option to scripts/Kbuild.include. Suggested-by: Arnd Bergmann <arnd@arndb.de> Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Michal Marek <mmarek@suse.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* kbuild: Add support to generate LLVM assembly filesVinícius Tinti2018-11-231-0/+5
| | | | | | | | | | | | | | | | | commit 433db3e260bc8134d4a46ddf20b3668937e12556 upstream. Add rules to kbuild in order to generate LLVM assembly files with the .ll extension when using clang. # from c code make CC=clang kernel/pid.ll Signed-off-by: Vinícius Tinti <viniciustinti@gmail.com> Signed-off-by: Behan Webster <behanw@converseincode.com> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* kbuild: use -Oz instead of -Os when using clangBehan Webster2018-11-231-1/+2
| | | | | | | | | | | | commit 6748cb3c299de1ffbe56733647b01dbcc398c419 upstream. This generates smaller resulting object code when compiled with clang. Signed-off-by: Behan Webster <behanw@converseincode.com> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* kbuild: drop -Wno-unknown-warning-option from clang optionsMasahiro Yamada2018-11-231-1/+0
| | | | | | | | | | | | | | | | | | | commit a0ae981eba8f07dbc74bce38fd3a462b69a5bc8e upstream. Since commit c3f0d0bc5b01 ("kbuild, LLVMLinux: Add -Werror to cc-option to support clang"), cc-option and friends work nicely for clang. However, -Wno-unknown-warning-option makes clang happy with any unknown warning options even if -Werror is specified. Once -Wno-unknown-warning-option is added, any succeeding call of cc-disable-warning is evaluated positive, then unknown warning options are accepted. This should be dropped. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* kbuild: clang: add -no-integrated-as to KBUILD_[AC]FLAGSMichael Davidson2018-11-231-0/+2
| | | | | | | | | | | | | | | | | | commit a37c45cd82e62a361706b9688a984a3a63957321 upstream. The Linux Kernel relies on GCC's acceptance of inline assembly as an opaque object which will not have any validation performed on the content. The current behaviour in LLVM is to perform validation of the contents by means of parsing the input if the MC layer can handle it. Disable clangs integrated assembler and use the GNU assembler instead. Wording-mostly-from: Saleem Abdulrasool <compnerd@compnerd.org> Signed-off-by: Michael Davidson <md@google.com> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* kbuild: Add better clang cross build supportBehan Webster2018-11-231-0/+9
| | | | | | | | | | | | | | | | | | | | | | commit 785f11aa595bc3d4e74096cbd598ada54ecc0d81 upstream. Add cross target to CC if using clang. Also add custom gcc toolchain path for fallback gcc tools. Clang will fallback to using things like ld, as, and libgcc if (respectively) one of the llvm linkers isn't available, the integrated assembler is turned off, or an appropriately cross-compiled version of compiler-rt isn't available. To this end, you can specify the path to this fallback gcc toolchain with GCC_TOOLCHAIN. Signed-off-by: Behan Webster <behanw@converseincode.com> Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de> Reviewed-by: Mark Charlebois <charlebm@gmail.com> Signed-off-by: Greg Hackmann <ghackmann@google.com> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 4.9.138v4.9.138Greg Kroah-Hartman2018-11-211-1/+1
|
* Linux 4.9.137v4.9.137Greg Kroah-Hartman2018-11-131-1/+1
|
* Linux 4.9.136v4.9.136Greg Kroah-Hartman2018-11-101-1/+1
|
* Linux 4.9.135v4.9.135Greg Kroah-Hartman2018-10-201-1/+1
|
* Linux 4.9.134v4.9.134Greg Kroah-Hartman2018-10-181-1/+1
|
* Linux 4.9.133v4.9.133Greg Kroah-Hartman2018-10-131-1/+1
|
* Linux 4.9.132v4.9.132Greg Kroah-Hartman2018-10-101-1/+1
|
* Linux 4.9.131v4.9.131Greg Kroah-Hartman2018-10-031-1/+1
|
* Linux 4.9.130v4.9.130Greg Kroah-Hartman2018-09-291-1/+1
|
* Linux 4.9.129v4.9.129Greg Kroah-Hartman2018-09-261-1/+1
|
* Linux 4.9.128v4.9.128Greg Kroah-Hartman2018-09-191-1/+1
|
* Linux 4.9.127v4.9.127Greg Kroah-Hartman2018-09-151-1/+1
|
* Linux 4.9.126v4.9.126Greg Kroah-Hartman2018-09-091-1/+1
|
* Linux 4.9.125v4.9.125Greg Kroah-Hartman2018-09-051-1/+1
|
* Linux 4.9.124v4.9.124Greg Kroah-Hartman2018-08-241-1/+1
|
* Linux 4.9.123v4.9.123Greg Kroah-Hartman2018-08-221-1/+1
|
* Linux 4.9.122v4.9.122Greg Kroah-Hartman2018-08-181-1/+1
|
* Linux 4.9.121v4.9.121Greg Kroah-Hartman2018-08-171-1/+1
|
* kasan: don't emit builtin calls when sanitization is offAndrey Konovalov2018-08-171-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 0e410e158e5baa1300bdf678cea4f4e0cf9d8b94 upstream. With KASAN enabled the kernel has two different memset() functions, one with KASAN checks (memset) and one without (__memset). KASAN uses some macro tricks to use the proper version where required. For example memset() calls in mm/slub.c are without KASAN checks, since they operate on poisoned slab object metadata. The issue is that clang emits memset() calls even when there is no memset() in the source code. They get linked with improper memset() implementation and the kernel fails to boot due to a huge amount of KASAN reports during early boot stages. The solution is to add -fno-builtin flag for files with KASAN_SANITIZE := n marker. Link: http://lkml.kernel.org/r/8ffecfffe04088c52c42b92739c2bd8a0bcb3f5e.1516384594.git.andreyknvl@google.com Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Acked-by: Nick Desaulniers <ndesaulniers@google.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Michal Marek <michal.lkml@markovi.net> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> [ Sami: Backported to 4.9 avoiding c5caf21ab0cf8 and e7c52b84fb ] Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 4.9.120v4.9.120Greg Kroah-Hartman2018-08-151-1/+1
|
* Linux 4.9.119v4.9.119Greg Kroah-Hartman2018-08-091-1/+1
|
* Linux 4.9.118v4.9.118Greg Kroah-Hartman2018-08-061-1/+1
|
* Linux 4.9.117v4.9.117Greg Kroah-Hartman2018-08-031-1/+1
|
* Linux 4.9.116v4.9.116Greg Kroah-Hartman2018-07-281-1/+1
|
* turn off -Wattribute-aliasArnd Bergmann2018-07-281-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>
* Linux 4.9.115v4.9.115Greg Kroah-Hartman2018-07-251-1/+1
|
* Linux 4.9.114v4.9.114Greg Kroah-Hartman2018-07-221-1/+1
|
* Linux 4.9.113v4.9.113Greg Kroah-Hartman2018-07-171-1/+1
|
* Linux 4.9.112v4.9.112Greg Kroah-Hartman2018-07-111-1/+1
|
* Linux 4.9.111v4.9.111Greg Kroah-Hartman2018-07-031-1/+1
|
* Linux 4.9.110v4.9.110Greg Kroah-Hartman2018-06-261-1/+1
|
* Linux 4.9.109v4.9.109Greg Kroah-Hartman2018-06-161-1/+1
|
* Linux 4.9.108v4.9.108Greg Kroah-Hartman2018-06-131-1/+1
|
* Linux 4.9.107v4.9.107Greg Kroah-Hartman2018-06-061-1/+1
|
* Linux 4.9.106v4.9.106Greg Kroah-Hartman2018-06-051-1/+1
|
* Linux 4.9.105v4.9.105Greg Kroah-Hartman2018-05-301-1/+1
|
* Linux 4.9.104v4.9.104Greg Kroah-Hartman2018-05-301-1/+1
|
* Linux 4.9.103v4.9.103Greg Kroah-Hartman2018-05-251-1/+1
|
* Linux 4.9.102v4.9.102Greg Kroah-Hartman2018-05-221-1/+1
|