1. 19 Oct, 2014 1 commit
  2. 05 Oct, 2014 1 commit
  3. 02 Oct, 2014 2 commits
  4. 01 Oct, 2014 3 commits
  5. 28 Sep, 2014 1 commit
  6. 26 Sep, 2014 1 commit
  7. 21 Sep, 2014 1 commit
  8. 14 Sep, 2014 1 commit
  9. 07 Sep, 2014 1 commit
  10. 31 Aug, 2014 1 commit
  11. 27 Aug, 2014 1 commit
    • Bertrand Jacquin's avatar
      kbuild: handle module compression while running 'make modules_install'. · beb50df3
      Bertrand Jacquin authored
      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: default avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarBertrand Jacquin <beber@meleeweb.net>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
  12. 25 Aug, 2014 1 commit
  13. 16 Aug, 2014 1 commit
  14. 07 Aug, 2014 1 commit
  15. 06 Aug, 2014 2 commits
    • Jiri Kosina's avatar
      ./Makefile: tell gcc optimizer to never introduce new data races · 69102311
      Jiri Kosina authored
      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 ();
          return 0;
        /* EOF */
        $ ~/gcc/trunk/inst/bin/gcc cond_store.c -O2 --param allow-store-data-races=0
        $ ./a.out
        $ ~/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
      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
        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
               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
               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>
               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: default avatarJiri 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Kees Cook's avatar
      ./Makefile: explain stack-protector-strong CONFIG logic · 1332429b
      Kees Cook authored
      This adds a hopefully helpful comment above the (seemingly weird) compiler
      flag selection logic.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Suggested-by: default avatarAndrew 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  16. 05 Aug, 2014 1 commit
  17. 03 Aug, 2014 1 commit
  18. 30 Jul, 2014 2 commits
    • Andi Kleen's avatar
      Kbuild: Add a option to enable dwarf4 v2 · bfaf2dd3
      Andi Kleen authored
      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: default avatarAndi Kleen <ak@linux.intel.com>
      Acked-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
    • Andi Kleen's avatar
      kbuild: Support split debug info v4 · 866ced95
      Andi Kleen authored
      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
      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: default avatarAndi Kleen <ak@linux.intel.com>
      Acked-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
  19. 27 Jul, 2014 1 commit
  20. 26 Jul, 2014 1 commit
    • Linus Torvalds's avatar
      Fix gcc-4.9.0 miscompilation of load_balance() in scheduler · 2062afb4
      Linus Torvalds authored
      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: default avatarMichel Dänzer <michel@daenzer.net>
      Suggested-by: default avatarMarkus Trippelsdorf <markus@trippelsdorf.de>
      Cc: Jakub Jelinek <jakub@redhat.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  21. 20 Jul, 2014 1 commit
  22. 18 Jul, 2014 1 commit
    • Masahiro Yamada's avatar
      kbuild: allow to override Python command name · 011bf125
      Masahiro Yamada authored
      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: default avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
      Cc: linux-ia64@vger.kernel.org
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
  23. 13 Jul, 2014 1 commit
  24. 11 Jul, 2014 1 commit
  25. 06 Jul, 2014 1 commit
  26. 04 Jul, 2014 2 commits
    • Michal Marek's avatar
      kbuild: Fix packaging targets with relative $(srctree) · c79624c1
      Michal Marek authored
      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: default avatarMichal Marek <mmarek@suse.cz>
    • Michal Marek's avatar
      kbuild: Do not print the build directory with make -s · 066b7ed9
      Michal Marek authored
      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: default avatarMichal Marek <mmarek@suse.cz>
  27. 03 Jul, 2014 1 commit
  28. 29 Jun, 2014 1 commit
  29. 21 Jun, 2014 1 commit
  30. 15 Jun, 2014 1 commit
  31. 09 Jun, 2014 3 commits
  32. 08 Jun, 2014 1 commit