- 16 4月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 07 4月, 2018 4 次提交
-
-
由 Masahiro Yamada 提交于
The __FILE__ macro is used everywhere in the kernel to locate the file printing the log message, such as WARN_ON(), etc. If the kernel is built out of tree, this can be a long absolute path, like this: WARNING: CPU: 1 PID: 1 at /path/to/build/directory/arch/arm64/kernel/foo.c:... This is because Kbuild runs in the objtree instead of the srctree, then __FILE__ is expanded to a file path prefixed with $(srctree)/. Commit 9da0763b ("kbuild: Use relative path when building in a subdir of the source tree") improved this to some extent; $(srctree) becomes ".." if the objtree is a child of the srctree. For other cases of out-of-tree build, __FILE__ is still the absolute path. It also means the kernel image depends on where it was built. A brand-new option from GCC, -fmacro-prefix-map, solves this problem. If your compiler supports it, __FILE__ is the relative path from the srctree regardless of O= option. This provides more readable log and more reproducible builds. Please note __FILE__ is always an absolute path for external modules. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
Our convention is to distinguish file types by suffixes with a period as a separator. *-asn1.[ch] is a different pattern from other generated sources such as *.lex.c, *.tab.[ch], *.dtb.S, etc. More confusing, files with '-asn1.[ch]' are generated files, but '_asn1.[ch]' are checked-in files: net/netfilter/nf_conntrack_h323_asn1.c include/linux/netfilter/nf_conntrack_h323_asn1.h include/linux/sunrpc/gss_asn1.h Rename generated files to *.asn1.[ch] for consistency. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
Clean up these patterns from the top Makefile to omit 'clean-files' in each Makefile. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
Files suffixed by .lex.c, .tab.[ch] are generated lexers, parsers, respectively. Clean them up globally from the top Makefile. Some of the final host programs those lexer/parser are linked into are necessary for building external modules, but the intermediates are unneeded. They can be cleaned away by 'make clean' instead of 'make mrproper'. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Acked-by: NFrank Rowand <frowand.list@gmail.com>
-
- 02 4月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 26 3月, 2018 11 次提交
-
-
由 Linus Torvalds 提交于
-
由 Masahiro Yamada 提交于
The variable 'PYTHON' allows users to specify a proper executable name in case the default 'python' does not work. However, this does not address the case where both Python 2.x and 3.x scripts are used in one source tree. PEP 394 (https://www.python.org/dev/peps/pep-0394/) provides a convention for Python scripts portability. Here is a quotation: In order to tolerate differences across platforms, all new code that needs to invoke the Python interpreter should not specify 'python', but rather should specify either 'python2' or 'python3'. This distinction should be made in shebangs, when invoking from a shell script, when invoking via the system() call, or when invoking in any other context. One exception to this is scripts that are deliberately written to be source compatible with both Python 2.x and 3.x. Such scripts may continue to use python on their shebang line without affecting their portability. To meet this requirement, this commit adds new variables 'PYTHON2' and 'PYTHON3'. arch/ia64/scripts/unwcheck.py is the only script that has ever used $(PYTHON). Recent commit bd5edbe6 ("ia64: convert unwcheck.py to python3") converted it to be compatible with both Python 2.x and 3.x, so this is the exceptional case where the use of 'python' is allowed. So, I did not touch arch/ia64/Makefile. tools/perf/Makefile.config sets PYTHON and PYTHON2 by itself, so it is not affected by this commit. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
As commit cedd55d4 ("kconfig: Remove silentoldconfig from help and docs; fix kconfig/conf's help") mentioned, 'silentoldconfig' is a historical misnomer. That commit removed it from help and docs since it is an internal interface. If so, it should be allowed to rename it to something more intuitive. 'syncconfig' is the one I came up with because it updates the .config if necessary, then synchronize include/generated/autoconf.h and include/config/* with it. You should not manually invoke 'silentoldcofig'. Display warning if used in case existing scripts are doing wrong. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: NUlf Magnusson <ulfalizer@gmail.com>
-
由 Masahiro Yamada 提交于
If CONFIG_TRIM_UNUSED_KSYMS is enabled and the kernel is built from a pristine state, the vmlinux is linked twice. [1] A user runs 'make' [2] First build with empty autoksyms.h [3] adjust_autoksyms.sh updates autoksyms.h and recurses 'make vmlinux' --------(begin sub-make)-------- [4] Second build with new autoksyms.h [5] link-vmlinux.sh is invoked because vmlinux is missing ---------(end sub-make)--------- [6] link-vmlinux.sh is invoked again despite vmlinux is up-to-date. The reason of [6] is probably because Make already decided to update vmlinux at the time of [2] because vmlinux was missing when Make built up the dependency graph. Because if_changed is implemented based on $?, this issue can be narrowed down to how Make handles $?. You can test it with the following simple code: [Test Makefile] A: B @echo newer prerequisite: $? cp B A B: C cp C B touch A [Result] $ rm -f A B $ touch C $ make cp C B touch A newer prerequisite: B cp B A Here, 'A' has been touched in the recipe of 'B'. So, the dependency 'A: B' has already been met before the recipe of 'A' is executed. However, Make does not notice the fact that the recipe of 'B' also updates 'A' as a side-effect. The situation is similar in this case; the vmlinux has actually been updated in the vmlinux_prereq target. Make cannot predict this, so judges the vmlinux is old. link-vmlinux.sh is costly, so it is better to not run it when unneeded. Split CONFIG_TRIM_UNUSED_KSYMS recursion to a dedicated target. The reason of commit 2441e78b ("kbuild: better abstract vmlinux sequential prerequisites") was to cater to CONFIG_BUILD_DOCSRC, but it was later removed by commit 18489292 ("samples: move blackfin gptimers-example from Documentation"). Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Acked-by: NNicolas Pitre <nico@linaro.org>
-
由 Masahiro Yamada 提交于
The idea of using fixdep was inspired by Kconfig, but autoksyms belongs to a different group. So, I want to move those touched files under include/config/ksym/ to include/ksym/. The directory include/ksym/ can be removed by 'make clean' because it is meaningless for the external module building. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Acked-by: NNicolas Pitre <nico@linaro.org>
-
由 Masahiro Yamada 提交于
The external module building does not need to parse this code because KBUILD_MODULES is always set anyway. Move this code inside the "ifeq ($(KBUILD_EXTMOD),) ... endif" block. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Acked-by: NNicolas Pitre <nico@linaro.org>
-
由 Masahiro Yamada 提交于
Commit d3fc425e ("kbuild: make sure autoksyms.h exists early") moved the code that touches autoksyms.h to scripts/kconfig/Makefile with obscure reason. From Nicolas' comment [1], he did not seem to be sure about the root cause. I guess I figured it out, so here is a fix-up I think is more correct. According to the error log in the original post [2], the build failed in scripts/mod/devicetable-offsets.c scripts/mod/Makefile is descended from scripts/Makefile, which is invoked from the top-level Makefile by the 'scripts' target. To build vmlinux and/or modules, Kbuild descend into $(vmlinux-dirs). This depends on 'prepare' and 'scripts' as follows: $(vmlinux-dirs): prepare scripts Because there is no dependency between 'prepare' and 'scripts', the parallel building can execute them simultaneously. 'prepare' depends on 'prepare1', which touched autoksyms.h, while 'scripts' descends into script/, then scripts/mod/, which needs <generated/autoksyms.h> if CONFIG_TRIM_UNUSED_KSYMS. It was the reason of the race. I am not happy to have unrelated code in the Kconfig Makefile, so getting it back to the top Makefile. I removed the standalone test target because I want to use it to create an empty autoksyms.h file. Here is a little improvement; unnecessary autoksyms.h is not created when CONFIG_TRIM_UNUSED_KSYMS is disabled. [1] https://lkml.org/lkml/2016/11/30/734 [2] https://lkml.org/lkml/2016/11/30/531Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Acked-by: NNicolas Pitre <nico@linaro.org>
-
由 Masahiro Yamada 提交于
Just a trivial change to prepare for the next commit. This target is still invisible from external module building. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
Currently LDFLAGS is not cleared, so same flags are accumulated in LDFLAGS when the top Makefile is recursively invoked. I found unneeded rebuild for ARCH=arm64 when CONFIG_TRIM_UNUSED_KSYMS is enabled. If include/generated/autoksyms.h is updated, the top Makefile is recursively invoked, then arch/arm64/Makefile adds one more '-maarch64linux'. Due to the command line change, modules are rebuilt needlessly. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Acked-by: NNicolas Pitre <nico@linaro.org>
-
由 Masahiro Yamada 提交于
Support parallel building of clean, config, and build targets in a single command. For example, make -j<N> clean all or make -j<N> mrproper defconfig all They should be handled one by one. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Nicholas Piggin 提交于
Incremental linking is gone, so rename built-in.o to built-in.a, which is the usual extension for archive files. This patch does two things, first is a simple search/replace: git grep -l 'built-in\.o' | xargs sed -i 's/built-in\.o/built-in\.a/g' The second is to invert nesting of nested text manipulations to avoid filtering built-in.a out from libs-y2: -libs-y2 := $(filter-out %.a, $(patsubst %/, %/built-in.a, $(libs-y))) +libs-y2 := $(patsubst %/, %/built-in.a, $(filter-out %.a, $(libs-y))) Signed-off-by: NNicholas Piggin <npiggin@gmail.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 21 3月, 2018 2 次提交
-
-
由 Stefan Agner 提交于
In order to make sure compiler flag detection for ARM works correctly the no-integrated-as flags need to be set before including the arch specific Makefile. Fixes: cfe17c9b ("kbuild: move cc-option and cc-disable-warning after incl. arch Makefile") Signed-off-by: NStefan Agner <stefan@agner.ch> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Daniel Borkmann 提交于
Prasad reported that he has seen crashes in BPF subsystem with netd on Android with arm64 in the form of (note, the taint is unrelated): [ 4134.721483] Unable to handle kernel paging request at virtual address 800000001 [ 4134.820925] Mem abort info: [ 4134.901283] Exception class = DABT (current EL), IL = 32 bits [ 4135.016736] SET = 0, FnV = 0 [ 4135.119820] EA = 0, S1PTW = 0 [ 4135.201431] Data abort info: [ 4135.301388] ISV = 0, ISS = 0x00000021 [ 4135.359599] CM = 0, WnR = 0 [ 4135.470873] user pgtable: 4k pages, 39-bit VAs, pgd = ffffffe39b946000 [ 4135.499757] [0000000800000001] *pgd=0000000000000000, *pud=0000000000000000 [ 4135.660725] Internal error: Oops: 96000021 [#1] PREEMPT SMP [ 4135.674610] Modules linked in: [ 4135.682883] CPU: 5 PID: 1260 Comm: netd Tainted: G S W 4.14.19+ #1 [ 4135.716188] task: ffffffe39f4aa380 task.stack: ffffff801d4e0000 [ 4135.731599] PC is at bpf_prog_add+0x20/0x68 [ 4135.741746] LR is at bpf_prog_inc+0x20/0x2c [ 4135.751788] pc : [<ffffff94ab7ad584>] lr : [<ffffff94ab7ad638>] pstate: 60400145 [ 4135.769062] sp : ffffff801d4e3ce0 [...] [ 4136.258315] Process netd (pid: 1260, stack limit = 0xffffff801d4e0000) [ 4136.273746] Call trace: [...] [ 4136.442494] 3ca0: ffffff94ab7ad584 0000000060400145 ffffffe3a01bf8f8 0000000000000006 [ 4136.460936] 3cc0: 0000008000000000 ffffff94ab844204 ffffff801d4e3cf0 ffffff94ab7ad584 [ 4136.479241] [<ffffff94ab7ad584>] bpf_prog_add+0x20/0x68 [ 4136.491767] [<ffffff94ab7ad638>] bpf_prog_inc+0x20/0x2c [ 4136.504536] [<ffffff94ab7b5d08>] bpf_obj_get_user+0x204/0x22c [ 4136.518746] [<ffffff94ab7ade68>] SyS_bpf+0x5a8/0x1a88 Android's netd was basically pinning the uid cookie BPF map in BPF fs (/sys/fs/bpf/traffic_cookie_uid_map) and later on retrieving it again resulting in above panic. Issue is that the map was wrongly identified as a prog! Above kernel was compiled with clang 4.0, and it turns out that clang decided to merge the bpf_prog_iops and bpf_map_iops into a single memory location, such that the two i_ops could then not be distinguished anymore. Reason for this miscompilation is that clang has the more aggressive -fmerge-all-constants enabled by default. In fact, clang source code has a comment about it in lib/AST/ExprConstant.cpp on why it is okay to do so: Pointers with different bases cannot represent the same object. (Note that clang defaults to -fmerge-all-constants, which can lead to inconsistent results for comparisons involving the address of a constant; this generally doesn't matter in practice.) The issue never appeared with gcc however, since gcc does not enable -fmerge-all-constants by default and even *explicitly* states in it's option description that using this flag results in non-conforming behavior, quote from man gcc: Languages like C or C++ require each variable, including multiple instances of the same variable in recursive calls, to have distinct locations, so using this option results in non-conforming behavior. There are also various clang bug reports open on that matter [1], where clang developers acknowledge the non-conforming behavior, and refer to disabling it with -fno-merge-all-constants. But even if this gets fixed in clang today, there are already users out there that triggered this. Thus, fix this issue by explicitly adding -fno-merge-all-constants to the kernel's Makefile to generically disable this optimization, since potentially other places in the kernel could subtly break as well. Note, there is also a flag called -fmerge-constants (not supported by clang), which is more conservative and only applies to strings and it's enabled in gcc's -O/-O2/-O3/-Os optimization levels. In gcc's code, the two flags -fmerge-{all-,}constants share the same variable internally, so when disabling it via -fno-merge-all-constants, then we really don't merge any const data (e.g. strings), and text size increases with gcc (14,927,214 -> 14,942,646 for vmlinux.o). $ gcc -fverbose-asm -O2 foo.c -S -o foo.S -> foo.S lists -fmerge-constants under options enabled $ gcc -fverbose-asm -O2 -fno-merge-all-constants foo.c -S -o foo.S -> foo.S doesn't list -fmerge-constants under options enabled $ gcc -fverbose-asm -O2 -fno-merge-all-constants -fmerge-constants foo.c -S -o foo.S -> foo.S lists -fmerge-constants under options enabled Thus, as a workaround we need to set both -fno-merge-all-constants *and* -fmerge-constants in the Makefile in order for text size to stay as is. [1] https://bugs.llvm.org/show_bug.cgi?id=18538Reported-by: NPrasad Sodagudi <psodagud@codeaurora.org> Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Chenbo Feng <fengc@google.com> Cc: Richard Smith <richard-llvm@metafoo.co.uk> Cc: Chandler Carruth <chandlerc@gmail.com> Cc: linux-kernel@vger.kernel.org Tested-by: NPrasad Sodagudi <psodagud@codeaurora.org> Acked-by: NAlexei Starovoitov <ast@kernel.org> Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
-
- 20 3月, 2018 1 次提交
-
-
由 Peter Zijlstra 提交于
We want to start using asm-goto to guarantee the absence of dynamic branches (and thus speculation). A primary prerequisite for this is of course that the compiler supports asm-goto. This effecively lifts the minimum GCC version to build an x86 kernel to gcc-4.5. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Cc: torvalds@linux-foundation.org Link: https://lkml.kernel.org/r/20180319201327.GJ4043@hirez.programming.kicks-ass.net
-
- 19 3月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 16 3月, 2018 1 次提交
-
-
由 Arnd Bergmann 提交于
The Tile architecture port was added by Chris Metcalf in 2010, and maintained until early 2018 when he orphaned it due to his departure from Mellanox, and nobody else stepped up to maintain it. The product line is still around in the form of the BlueField SoC, but no longer uses the Tile architecture. There are also still products for sale with Tile-GX SoCs, notably the Mikrotik CCR router family. The products all use old (linux-3.3) kernels with lots of patches and won't be upgraded by their manufacturers. There have been efforts to port both OpenWRT and Debian to these, but both projects have stalled and are very unlikely to be continued in the future. Given that we are reasonably sure that nobody is still using the port with an upstream kernel any more, it seems better to remove it now while the port is in a good shape than to let it bitrot for a few years first. Cc: Chris Metcalf <chris.d.metcalf@gmail.com> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Link: http://www.mellanox.com/page/npu_multicore_overview Link: https://jenkins.debian.net/view/rebootstrap/job/rebootstrap_tilegx_gcc7/Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
- 12 3月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 05 3月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 02 3月, 2018 1 次提交
-
-
由 Masahiro Yamada 提交于
'--build-id' is passed to $(LD), so it should be tested by 'ld-option'. This seems a kind of misconversion when ld-option was renamed to cc-ldoption. Commit f86fd306 ("kbuild: rename ld-option to cc-ldoption") renamed all instances of 'ld-option' to 'cc-ldoption'. Then, commit 691ef3e7 ("kbuild: introduce ld-option") re-added 'ld-option' as a new implementation. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 01 3月, 2018 2 次提交
-
-
由 Luc Van Oostenryck 提交于
Currently, sparse issues warnings on code using an attribute it doesn't know about. One of the problem with this is that these warnings have no value for the developer, it's just noise for him. At best these warnings tell something about some deficiencies of sparse itself but not about a potential problem with code analyzed. A second problem with this is that sparse release are, alas, less frequent than new attributes are added to GCC. So, avoid the noise by asking sparse to not warn about attributes it doesn't know about. Reference: https://marc.info/?l=linux-sparse&m=151871600016790 Reference: https://marc.info/?l=linux-sparse&m=151871725417322Signed-off-by: NLuc Van Oostenryck <luc.vanoostenryck@gmail.com> Acked-by: NRandy Dunlap <rdunlap@infradead.org> Tested-by: NRandy Dunlap <rdunlap@infradead.org> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Ulf Magnusson 提交于
The comment above the silentoldconfig invocation is outdated. 'make oldconfig' updates just .config and doesn't touch the include/config/ tree. This came up in https://lkml.org/lkml/2018/2/12/415. While fixing the comment, make it more informative by explaining the purpose of the unfortunately named silentoldconfig. I can't make sense of the comment re. auto.conf.cmd and a cleaned tree. include/config/auto.conf and include/config/auto.conf.cmd are both created simultaneously by silentoldconfig (in scripts/kconfig/confdata.c, by conf_write_autoconf()), and nothing seems to remove auto.conf.cmd that wouldn't remove auto.conf. Remove that part of the comment rather than blindly copying it. It might be a leftover from an older way of doing things. The include/config/auto.conf.cmd prerequisite might be there to ensure that silentoldconfig gets rerun if conf_write_autoconf() fails between writing out auto.conf.cmd and auto.conf (a comment in the function indicates that auto.conf is deliberately written out last to mark completion of the operation). It seems the Makefile dependency between include/config/auto.conf and .config would already take care of that though, since include/config/auto.conf would still be out of date re. .config if the operation fails. Cop out and leave the prerequisite in for now. Signed-off-by: NUlf Magnusson <ulfalizer@gmail.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 26 2月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 21 2月, 2018 1 次提交
-
-
由 Peter Zijlstra 提交于
Disable retpoline validation in objtool if your compiler sucks, and otherwise select the validation stuff for CONFIG_RETPOLINE=y (most builds would already have it set due to ORC). Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Acked-by: NThomas Gleixner <tglx@linutronix.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
- 19 2月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 12 2月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 07 2月, 2018 5 次提交
-
-
由 Kees Cook 提交于
Nearly all modern compilers support a stack-protector option, and nearly all modern distributions enable the kernel stack-protector, so enabling this by default in kernel builds would make sense. However, Kconfig does not have knowledge of available compiler features, so it isn't safe to force on, as this would unconditionally break builds for the compilers or architectures that don't have support. Instead, this introduces a new option, CONFIG_CC_STACKPROTECTOR_AUTO, which attempts to discover the best possible stack-protector available, and will allow builds to proceed even if the compiler doesn't support any stack-protector. This option is made the default so that kernels built with modern compilers will be protected-by-default against stack buffer overflows, avoiding things like the recent BlueBorne attack. Selection of a specific stack-protector option remains available, including disabling it. Additionally, tiny.config is adjusted to use CC_STACKPROTECTOR_NONE, since that's the option with the least code size (and it used to be the default, so we have to explicitly choose it there now). Link: http://lkml.kernel.org/r/1510076320-69931-4-git-send-email-keescook@chromium.orgSigned-off-by: NKees Cook <keescook@chromium.org> Tested-by: NLaura Abbott <labbott@redhat.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Josh Triplett <josh@joshtriplett.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Kees Cook 提交于
Various portions of the kernel, especially per-architecture pieces, need to know if the compiler is building with the stack protector. This was done in the arch/Kconfig with 'select', but this doesn't allow a way to do auto-detected compiler support. In preparation for creating an on-if-available default, move the logic for the definition of CONFIG_CC_STACKPROTECTOR into the Makefile. Link: http://lkml.kernel.org/r/1510076320-69931-3-git-send-email-keescook@chromium.orgSigned-off-by: NKees Cook <keescook@chromium.org> Tested-by: NLaura Abbott <labbott@redhat.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Josh Triplett <josh@joshtriplett.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Kees Cook 提交于
In order to make stack-protector failures warn instead of unconditionally breaking the build, this moves the compiler output sanity-check earlier, and sets a flag for later testing. Future patches can choose to warn or fail, depending on the flag value. Link: http://lkml.kernel.org/r/1510076320-69931-2-git-send-email-keescook@chromium.orgSigned-off-by: NKees Cook <keescook@chromium.org> Tested-by: NLaura Abbott <labbott@redhat.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Josh Triplett <josh@joshtriplett.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Andrey Konovalov 提交于
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.comSigned-off-by: NAndrey Konovalov <andreyknvl@google.com> Acked-by: NNick 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: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Sodagudi Prasad 提交于
Currently, GCC disables -Wunused-const-variable, but not -Wunused-variable, so warns unused variables if they are non-constant. While, Clang does not warn unused variables at all regardless of the const qualifier because -Wno-unused-const-variable is implied by the stronger option -Wno-unused-variable. Disable -Wunused-const-variable instead of -Wunused-variable so that GCC and Clang work in the same way. Signed-off-by: NPrasad Sodagudi <psodagud@codeaurora.org> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 29 1月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 22 1月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 15 1月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 08 1月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-