- 08 12月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 01 12月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 28 11月, 2014 3 次提交
-
-
由 Michal Marek 提交于
make ARCH=powerpc help-<board series> should not require a cofigured source tree. Also, sort the boards in the output. Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
由 Michal Marek 提交于
In 3.7, the file moved from include/linux/ to include/generated/uapi/linux/. The path in the #include directive remained the same for compatibility reasons, but this created a problem when bisecting. Commit 9c8cdb71 (kbuild: unconditionally clobber include/linux/version.h on distclean) fixes this, provided the user does make distclean between builds. Better not rely on the user and delete the stale file each time make is invoked. Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: David Howells <dhowells@redhat.com> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
由 Konstantin Khlebnikov 提交于
Without sorting this list is completely unreadable for ARCH=arm. Signed-off-by: NKonstantin Khlebnikov <k.khlebnikov@samsung.com> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
- 26 11月, 2014 1 次提交
-
-
由 Masahiro Yamada 提交于
The shorthand "clean" is defined in both the top Makefile and scripts/Makefile.clean. Likewise, the "hdr-inst" is defined in both the top Makefile and scripts/Makefile.headersinst. To reduce code duplication, this commit collects them into scripts/Kbuild.include like the "build" and "modbuiltin" shorthands. It requires scripts/Makefile.clean to include scripts/Kbuild.include, but its impact on the performance of "make clean" should be negligible. Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
- 24 11月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 17 11月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 16 11月, 2014 1 次提交
-
-
由 Kirill A. Shutemov 提交于
Sasha Levin reports: "gcc5 changes the default standard to c11, which makes kernel build unhappy Explicitly define the kernel standard to be gnu89 which should keep everything working exactly like it was before gcc5" There are multiple small issues with the new default, but the biggest issue seems to be that the old - and very useful - GNU extension to allow a cast in front of an initializer has gone away. Patch updated by Kirill: "I'm pretty sure all gcc versions you can build kernel with supports -std=gnu89. cc-option is redunrant. We also need to adjust HOSTCFLAGS otherwise allmodconfig fails for me" Note by Andrew Pinski: "Yes it was reported and both problems relating to this extension has been added to gnu99 and gnu11. Though there are other issues with the kernel dealing with extern inline have different semantics between gnu89 and gnu99/11" End result: we may be able to move up to a newer stdc model eventually, but right now the newer models have some annoying deficiencies, so the traditional "gnu89" model ends up being the preferred one. Signed-off-by: NSasha Levin <sasha.levin@oracle.com> Singed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 10 11月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 03 11月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 27 10月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 20 10月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 06 10月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 02 10月, 2014 5 次提交
-
-
由 Michal Marek 提交于
Kconfig options are either 'y', 'm', or undefined. Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
由 Masahiro Yamada 提交于
$(if $(KBUILD_SRC),$(srctree)/) was a useful strategy to omit a long absolute path for in-source-tree build prior to commit 890676c6 (kbuild: Use relative path when building in the source tree). Now $(srctree) is "." when building in the source tree. It would not be annoying to add "$(srctree)/" all the time. Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
由 Masahiro Yamada 提交于
This commit avoids processing C=... and M=... twice when O=... is also given. Besides, we can also remove KBUILD_EXTMOD="$(KBUILD_EXTMOD)" in the sub-make target. Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: NPeter Foley <pefoley2@pefoley.com> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
由 Masahiro Yamada 提交于
Since commit 066b7ed9 (kbuild: Do not print the build directory with make -s), "Q" is defined above the sub-make target. This commit takes advantage of that and replaces "$(if $(KBUILD_VERBOSE:1=),@)" with "$(Q)". Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: NPeter Foley <pefoley2@pefoley.com> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
由 Masahiro Yamada 提交于
Commit c2e28dc9 (kbuild: Print the name of the build directory) added a gimmick to show the "Entering directory ...". Instead of echoing the hard-coded message (that is, we need to know the exact message), moving --no-print-directory would be easier. Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: NPeter Foley <pefoley2@pefoley.com> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
- 29 9月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 26 9月, 2014 1 次提交
-
-
由 Peter Foley 提交于
Cc: rdunlap@infradead.org Cc: linux-doc@vger.kernel.org Cc: sudeep.dutt@intel.com Cc: nikhil.rao@intel.com Cc: ashutosh.dixit@intel.com Cc: akpm@linux-foundation.org Cc: gregkh@linuxfoundation.org Signed-off-by: NPeter Foley <pefoley2@pefoley.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 22 9月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 15 9月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 08 9月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 01 9月, 2014 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 27 8月, 2014 1 次提交
-
-
由 Bertrand Jacquin 提交于
Since module-init-tools (gzip) and kmod (gzip and xz) support compressed modules, it could be useful to include a support for compressing modules right after having them installed. Doing this in kbuild instead of per distro can permit to make this kind of usage more generic. This patch add a Kconfig entry to "Enable loadable module support" menu and let you choose to compress using gzip (default) or xz. Both gzip and xz does not used any extra -[1-9] option since Andi Kleen and Rusty Russell prove no gain is made using them. gzip is called with -n argument to avoid storing original filename inside compressed file, that way we can save some more bytes. On a v3.16 kernel, 'make allmodconfig' generated 4680 modules for a total of 378MB (no strip, no sign, no compress), the following table shows observed disk space gain based on the allmodconfig .config : | time | +-------------+-----------------+ | manual .ko | make | size | percent | compression | modules_install | | gain +-------------+-----------------+------+-------- - | | 18.61s | 378M | GZIP | 3m16s | 3m37s | 102M | 73.41% XZ | 5m22s | 5m39s | 77M | 79.83% The gain for restricted environnement seems to be interesting while uncompress can be time consuming but happens only while loading a module, that is generally done only once. This is fully compatible with signed modules while the signed module is compressed. module-init-tools or kmod handles decompression and provide to other layer the uncompressed but signed payload. Reviewed-by: NWilly Tarreau <w@1wt.eu> Signed-off-by: NBertrand Jacquin <beber@meleeweb.net> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
- 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 提交于
-