- 22 9月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 15 9月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 08 9月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 01 9月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 26 8月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 17 8月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 08 8月, 2014 1 次提交
-
-
由 Shuah Khan 提交于
Add a new make target "kselftest" to enable kernel testing. This new target builds and runs kernel selftests. Running as root is recommended for a complete test run as some tests don't run when run by non-root user. Build, install, and boot kernel before running kselftest on it. Signed-off-by: NShuah Khan <shuah.kh@samsung.com> Acked-by: NSam Ravnborg <sam@ravnborg.org> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
- 07 8月, 2014 2 次提交
-
-
由 Jiri Kosina 提交于
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: NJiri 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: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Kees Cook 提交于
This adds a hopefully helpful comment above the (seemingly weird) compiler flag selection logic. Signed-off-by: NKees Cook <keescook@chromium.org> Suggested-by: NAndrew Morton <akpm@linux-foundation.org> Cc: Andi Kleen <ak@linux.intel.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Michal Marek <mmarek@suse.cz> Cc: Michal Hocko <mhocko@suse.cz> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 05 8月, 2014 1 次提交
-
-
由 Behan Webster 提交于
clang has more warnings enabled by default. Turn them off unless W is set. This patch fixes a logic bug where warnings in clang were disabled when W was set. Signed-off-by: NBehan Webster <behanw@converseincode.com> Signed-off-by: NJan-Simon Möller <dl9pf@gmx.de> Signed-off-by: NMark Charlebois <charlebm@gmail.com> Cc: bp@alien8.de Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
- 04 8月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 31 7月, 2014 2 次提交
-
-
由 Andi Kleen 提交于
I found that a lot of unresolvable variables when using gdb on the kernel become resolvable when dwarf4 is enabled. So add a Kconfig flag to enable it. It definitely increases the debug information size, but on the other hand this isn't so bad when debug fusion is used. v2: Use cc-option Signed-off-by: NAndi Kleen <ak@linux.intel.com> Acked-by: NSam Ravnborg <sam@ravnborg.org> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
由 Andi Kleen 提交于
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: NAndi Kleen <ak@linux.intel.com> Acked-by: NSam Ravnborg <sam@ravnborg.org> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
- 28 7月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 27 7月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
Michel Dänzer and a couple of other people reported inexplicable random oopses in the scheduler, and the cause turns out to be gcc mis-compiling the load_balance() function when debugging is enabled. The gcc bug apparently goes back to gcc-4.5, but slight optimization changes means that it now showed up as a problem in 4.9.0 and 4.9.1. The instruction scheduling problem causes gcc to schedule a spill operation to before the stack frame has been created, which in turn can corrupt the spilled value if an interrupt comes in. There may be other effects of this bug too, but that's the code generation problem seen in Michel's case. This is fixed in current gcc HEAD, but the workaround as suggested by Markus Trippelsdorf is pretty simple: use -fno-var-tracking-assignments when compiling the kernel, which disables the gcc code that causes the problem. This can result in slightly worse debug information for variable accesses, but that is infinitely preferable to actual code generation problems. Doing this unconditionally (not just for CONFIG_DEBUG_INFO) also allows non-debug builds to verify that the debug build would be identical: we can do export GCC_COMPARE_DEBUG=1 to make gcc internally verify that the result of the build is independent of the "-g" flag (it will make the compiler build everything twice, toggling the debug flag, and compare the results). Without the "-fno-var-tracking-assignments" option, the build would fail (even with 4.8.3 that didn't show the actual stack frame bug) with a gcc compare failure. See also gcc bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801Reported-by: NMichel Dänzer <michel@daenzer.net> Suggested-by: NMarkus Trippelsdorf <markus@trippelsdorf.de> Cc: Jakub Jelinek <jakub@redhat.com> Cc: stable@kernel.org Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 21 7月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 18 7月, 2014 1 次提交
-
-
由 Masahiro Yamada 提交于
The specification of Python 3 is largely different from that of Python 2. For example, arch/ia64/scripts/unwcheck.py seems to be written in Python 2, not compatible with Python 3. It is not a good idea to invoke python scripts with the hard-coded command name 'python'. The command 'python' could possibly be Python 3 on some systems. For that case, it is reasonable to allow to override the command name by giving 'PYTHON=python2' from the command line. The 'python' in arch/ia64/Makefile should be replaced with '$(PYTHON)'. Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com> Cc: linux-ia64@vger.kernel.org Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
- 14 7月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 11 7月, 2014 1 次提交
-
-
由 Michal Marek 提交于
If .config has been edited, there will be a silentoldconfig run: $ make defconfig ... $ make kernelrelease scripts/kconfig/conf --silentoldconfig Kconfig 3.16.0-rc1+ Recently, kbuild started to print the name of the build directory when using O= $ make O=build kernelrelease make[1]: Entering directory `/dev/shm/mmarek/linux-2.6/build' 3.16.0-rc1+ Since these targets are often used in scripts, add a hint to use make -s to the help text. Suggested-by: NRussell King <linux@arm.linux.org.uk> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
- 07 7月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 05 7月, 2014 1 次提交
-
-
由 Michal Marek 提交于
All other users of Makefile.build set $(obj) to the name of the subdirectory to build. Do the same for the packaging targets, otherwise the build fails if $(srctree) is a relative directory: $ make O=build tar-pkg make[1]: Entering directory `/home/mmarek/linux-2.6/build' CHK include/config/kernel.release ../scripts/Makefile.build:44: ../../scripts/package/Makefile: No such file or directory make[2]: *** No rule to make target `../../scripts/package/Makefile'. Stop. Fixes: 9da0763b ("kbuild: Use relative path when building in a subdir of the source tree") Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
- 04 7月, 2014 1 次提交
-
-
由 Michal Marek 提交于
Commit c2e28dc9 (kbuild: Print the name of the build directory) prints the name of the build directory for O= builds, but we should not be doing this in make -s mode, so that commands like make -s O=<dir> kernelrelease can be used by scripts. This matches the behavior of make itself, where the -s option implies --no-print-directory. Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
- 03 7月, 2014 1 次提交
-
-
由 Michal Marek 提交于
With commit 9da0763b (kbuild: Use relative path when building in a subdir of the source tree), the compiler messages include relative paths. These are however relative to the build directory, not the directory where make was started. Print the "Entering directory ..." message once, so that IDEs/editors can find the source files. Acked-by: NDavid Howells <dhowells@redhat.com> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
- 30 6月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 22 6月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 16 6月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 10 6月, 2014 3 次提交
-
-
由 Masahiro Yamada 提交于
The directory include/config is used only for silentoldconfig, localmodconfig, localyesconfig. Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
由 Masahiro Yamada 提交于
There are no generated files under include/linux directory. Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
由 Geert Uytterhoeven 提交于
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 e74fc973 ("Turn off -Wmaybe-uninitialized when building with -Os"), - commit 61163efa ("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: NGeert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
- 09 6月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 08 6月, 2014 1 次提交
-
-
由 Behan Webster 提交于
Both gcc (well, actually gnu as) and clang support the "-Wa,-gdwarf-2" option (though clang does not support "-Wa,--gdwarf-2"). Since these flags are equivalent in meaning, this patch uses the one which is better supported across compilers. Signed-off-by: NBehan Webster <behanw@converseincode.com>
-
- 02 6月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 26 5月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 22 5月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 15 5月, 2014 3 次提交
-
-
由 Michal Marek 提交于
When doing make O=<subdir>, use '..' to refer to the source tree. This allows for more readable compiler messages, and, more importantly, it sets the VPATH to '..', so filenames in WARN_ON() etc. will be shorter. Acked-by: NSam Ravnborg <sam@ravnborg.org> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
由 Michal Marek 提交于
When not using O=, $(srctree) refers to the same directory as $(objtree), so we can set it to '.' as well. This makes the default include path more compact and results in more readable messages from the compiler. The only case where we need the absolute path is when creating the 'source' symlink in /lib/modules. Acked-by: NSam Ravnborg <sam@ravnborg.org> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
由 Michal Marek 提交于
The main Makefile sets its working directory to the object tree and never changes it again. Therefore, we can use '.' instead of the absolute path. The only case where we need the absolute path is when creating the 'build' symlink in /lib/modules. Acked-by: NSam Ravnborg <sam@ravnborg.org> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
- 10 5月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 05 5月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 30 4月, 2014 1 次提交
-
-
由 Masahiro Yamada 提交于
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-