1. 02 2月, 2015 1 次提交
  2. 26 1月, 2015 1 次提交
  3. 18 1月, 2015 1 次提交
  4. 12 1月, 2015 1 次提交
  5. 09 1月, 2015 1 次提交
    • M
      Makefile: include arch/*/include/generated/uapi before .../generated · 90ac086b
      Michal Marek 提交于
      The introduction of the uapi directories in v3.7-rc1 moved some of the
      generated headers from arch/*/include/generated to the uapi directory,
      keeping the #include directives intact.
      
      This creates a problem when bisecting, because the unversioned files are
      not cleaned automatically by git and the compiler might include stale
      headers as a result.  Instead of cleaning them in the Makefiles, promote
      arch/*/include/generated/uapi in the search path.  Under normal
      circumstances, there is no overlap between this uapi subdirectory and
      its parent, so the include choices remain the same.  We keep
      arch/*/include/generated/uapi in the USERINCLUDE variable so that it is
      usable standalone.
      
      Note that we cannot completely swap the order of the uapi and
      kernel-only directories, since the headers in include/uapi/asm-generic
      are meant to be wrapped by their include/asm-generic counterparts when
      building kernel code.
      Reported-by: N"Nicholas A. Bellinger" <nab@linux-iscsi.org>
      Reported-by: NDavid Drysdale <dmd@lurklurk.org>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      90ac086b
  6. 06 1月, 2015 1 次提交
  7. 29 12月, 2014 1 次提交
  8. 21 12月, 2014 1 次提交
  9. 08 12月, 2014 1 次提交
  10. 01 12月, 2014 1 次提交
  11. 28 11月, 2014 3 次提交
  12. 26 11月, 2014 1 次提交
  13. 24 11月, 2014 1 次提交
  14. 17 11月, 2014 1 次提交
  15. 16 11月, 2014 1 次提交
    • K
      kernel: use the gnu89 standard explicitly · 51b97e35
      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>
      51b97e35
  16. 10 11月, 2014 1 次提交
  17. 03 11月, 2014 1 次提交
  18. 27 10月, 2014 1 次提交
  19. 20 10月, 2014 1 次提交
  20. 06 10月, 2014 1 次提交
  21. 02 10月, 2014 5 次提交
  22. 29 9月, 2014 1 次提交
  23. 26 9月, 2014 1 次提交
  24. 22 9月, 2014 1 次提交
  25. 15 9月, 2014 1 次提交
  26. 08 9月, 2014 1 次提交
  27. 01 9月, 2014 1 次提交
  28. 27 8月, 2014 1 次提交
    • B
      kbuild: handle module compression while running 'make modules_install'. · beb50df3
      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>
      beb50df3
  29. 26 8月, 2014 1 次提交
  30. 17 8月, 2014 1 次提交
  31. 08 8月, 2014 1 次提交
  32. 07 8月, 2014 2 次提交
    • J
      ./Makefile: tell gcc optimizer to never introduce new data races · 69102311
      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>
      69102311
    • K
      ./Makefile: explain stack-protector-strong CONFIG logic · 1332429b
      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>
      1332429b
  33. 05 8月, 2014 1 次提交