GitHub PushEvent at 2014-11-22 13:29:35
Repository: Dorimanx-LG-G2-D802-Kernel
Actor: dorimanx
Payload: {"shas":[["1886ca43a9b5394405ed6670a74fa050c4a1fd8b","ed58f755cc8caaf10c3e8c731a8b86fb8f13d6cb@suse.cz","Makefile: tell gcc optimizer to never introduce new data races\n\nWe have been chasing a memory corruption bug, which turned out to be\ncaused by very old gcc (4.3.4), which happily turned conditional load\ninto a non-conditional one, and that broke correctness (the condition\nwas met only if lock was held) and corrupted memory.\n\nThis particular problem with that particular code did not happen when\nnever gccs were used.  I've brought this up with our gcc folks, as I\nwanted to make sure that this can't really happen again, and it turns\nout it actually can.\n\nQuoting Martin Jambor <mjambor@suse.cz>:\n \"More current GCCs are more careful when it comes to replacing a\n  conditional load with a non-conditional one, most notably they check\n  that a store happens in each iteration of _a_ loop but they assume\n  loops are executed.  They also perform a simple check whether the\n  store cannot trap which currently passes only for non-const\n  variables.  A simple testcase demonstrating it on an x86_64 is for\n  example the following:\n\n  $ cat cond_store.c\n\n  int g_1 = 1;\n\n  int g_2[1024] __attribute__((section (\"safe_section\"), aligned (4096)));\n\n  int c = 4;\n\n  int __attribute__ ((noinline))\n  foo (void)\n  {\n    int l;\n    for (l = 0; (l != 4); l++) {\n      if (g_1)\n        return l;\n      for (g_2[0] = 0; (g_2[0] >= 26); ++g_2[0])\n        ;\n    }\n    return 2;\n  }\n\n  int main (int argc, char* argv[])\n  {\n    if (mprotect (g_2, sizeof(g_2), PROT_READ) == -1)\n      {\n        int e = errno;\n        error (e, e, \"mprotect error %i\", e);\n      }\n    foo ();\n    __builtin_printf(\"OK\\n\");\n    return 0;\n  }\n  /* EOF */\n  $ ~/gcc/trunk/inst/bin/gcc cond_store.c -O2 --param allow-store-data-races=0\n  $ ./a.out\n  OK\n  $ ~/gcc/trunk/inst/bin/gcc cond_store.c -O2 --param allow-store-data-races=1\n  $ ./a.out\n  Segmentation fault\n\n  The testcase fails the same at least with 4.9, 4.8 and 4.7.  Therefore\n  I would suggest building kernels with this parameter set to zero. I\n  also agree with Jikos that the default should be changed for -O2.  I\n  have run most of the SPEC 2k6 CPU benchmarks (gamess and dealII\n  failed, at -O2, not sure why) compiled with and without this option\n  and did not see any real difference between respective run-times\"\n\nHopefully the default will be changed in newer gccs, but let's force it\nfor kernel builds so that we are on a safe side even when older gcc are\nused.\n\nThe code in question was out-of-tree printk-in-NMI (yeah, surprise\nsuprise, once again) patch written by Petr Mladek, let me quote his\ncomment from our internal bugzilla:\n\n \"I have spent few days investigating inconsistent state of kernel ring buffer.\n  It went out that it was caused by speculative store generated by\n  gcc-4.3.4.\n\n  The problem is in assembly generated for make_free_space(). The functions is\n  called the following way:\n\n  + vprintk_emit();\n      + log = MAIN_LOG; // with logbuf_lock\n         or\n         log = NMI_LOG; // with nmi_logbuf_lock\n         cont_add(log, ...);\n          + cont_flush(log, ...);\n              + log_store(log, ...);\n                    + log_make_free_space(log, ...);\n\n  If called with log = NMI_LOG then only nmi_log_* global variables are safe to\n  modify but the generated code does store also into (main_)log_* global\n  variables:\n\n  <log_make_free_space>:\n         55                      push   %rbp\n         89 f6                   mov    %esi,%esi\n\n         48 8b 05 03 99 51 01    mov    0x1519903(%rip),%rax       # ffffffff82620868 <nmi_log_next_id>\n         44 8b 1d ec 98 51 01    mov    0x15198ec(%rip),%r11d      # ffffffff82620858 <log_next_idx>\n         8b 35 36 60 14 01       mov    0x1146036(%rip),%esi       # ffffffff8224cfa8 <log_buf_len>\n         44 8b 35 33 60 14 01    mov    0x1146033(%rip),%r14d      # ffffffff8224cfac <nmi_log_buf_len>\n         4c 8b 2d d0 98 51 01    mov    0x15198d0(%rip),%r13       # ffffffff82620850 <log_next_seq>\n         4c 8b 25 11 61 14 01    mov    0x1146111(%rip),%r12       # ffffffff8224d098 <log_buf>\n         49 89 c2                mov    %rax,%r10\n         48 21 c2                and    %rax,%rdx\n         48 8b 1d 0c 99 55 01    mov    0x155990c(%rip),%rbx       # ffffffff826608a0 <nmi_log_buf>\n         49 c1 ea 20             shr    $0x20,%r10\n         48 89 55 d0             mov    %rdx,-0x30(%rbp)\n         44 29 de                sub    %r11d,%esi\n         45 29 d6                sub    %r10d,%r14d\n         4c 8b 0d 97 98 51 01    mov    0x1519897(%rip),%r9\t# ffffffff82620840 <log_first_seq>\n         eb 7e                   jmp    ffffffff81107029\t<log_make_free_space+0xe9>\n  [...]\n         85 ff                   test   %edi,%edi                  # edi = 1 for NMI_LOG\n         4c 89 e8                mov    %r13,%rax\n         4c 89 ca                mov    %r9,%rdx\n         74 0a                   je     ffffffff8110703d\t<log_make_free_space+0xfd>\n         8b 15 27 98 51 01       mov    0x1519827(%rip),%edx       # ffffffff82620860 <nmi_log_first_id>\n         48 8b 45 d0             mov    -0x30(%rbp),%rax\n         48 39 c2                cmp    %rax,%rdx                  # end of loop\n         0f 84 da 00 00 00       je     ffffffff81107120 <log_make_free_space+0x1e0>\n  [...]\n         85 ff                   test   %edi,%edi                  # edi = 1 for NMI_LOG\n         4c 89 0d 17 97 51 01    mov    %r9,0x1519717(%rip)        # ffffffff82620840 <log_first_seq>\n                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^\n                                 KABOOOM\n         74 35                   je     ffffffff81107160\t\t <log_make_free_space+0x220>\n\n  It stores log_first_seq when edi == NMI_LOG. This instructions are used also\n  when edi == MAIN_LOG but the store is done speculatively before the condition\n  is decided.  It is unsafe because we do not have \"logbuf_lock\" in NMI context\n  and some other process migh modify \"log_first_seq\" in parallel\"\n\nI believe that the best course of action is both\n\n - building kernel (and anything multi-threaded, I guess) with that\n   optimization turned off\n - persuade gcc folks to change the default for future releases\n\nSigned-off-by: Jiri Kosina <jkosina@suse.cz>\nCc: Martin Jambor <mjambor@suse.cz>\nCc: Petr Mladek <pmladek@suse.cz>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Marek Polacek <polacek@redhat.com>\nCc: Jakub Jelinek <jakub@redhat.com>\nCc: Steven Noonan <steven@uplinklabs.net>\nCc: Richard Biener <richard.guenther@gmail.com>\nCc: Dan Carpenter <dan.carpenter@oracle.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","Jiri Kosina",true],["2ce9ca76b7fa846c27c3005da33ebd56ebb0d652","110fdadc76b6bce16977f568bdb4723eaed6fb3f@gentoo.org","Makefile: enable -Werror=implicit-int and -Werror=strict-prototypes by default\n\nThe common error found in forward-ported/backported patches is missing\nheaders.  One recent example (files and function names are mangled):\n\n    void foo(){}\n    EXPORT_SYMBOL(foo);\n\ngave only warning\n\n    foo.c:12345678:5: warning: function declaration isn't a prototype [-Wstrict-prototypes]\n    void foo(){}\n         ^\n\n    foo.c:12345679:5: warning: data definition has no type or storage class [enabled by default]\n    EXPORT_SYMBOL(foo);\n    foo.c:12345679:5: warning: type defaults to 'int' in declaration of 'EXORT_SYMBOL' [-Werror=implicit-int]\n\nNow it's a fatal error. Tested on x86_64 allyesconfig.\n\n[akpm@linux-foundation.org: fix typos in comments]\nSigned-off-by: Sergei Trofimovich <slyfox@gentoo.org>\nCc: Geert Uytterhoeven <geert@linux-m68k.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Michal Marek <mmarek@suse.cz>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","Sergei Trofimovich",true],["dc54869e15739c19a262513e634e1794002b4982","9b153e80bc985b32d577460a8a24e398d4182978@shutemov.name","kernel: use the gnu89 standard explicitly\n\nSasha Levin reports:\n \"gcc5 changes the default standard to c11, which makes kernel build\n  unhappy\n\n  Explicitly define the kernel standard to be gnu89 which should keep\n  everything working exactly like it was before gcc5\"\n\nThere are multiple small issues with the new default, but the biggest\nissue seems to be that the old - and very useful - GNU extension to\nallow a cast in front of an initializer has gone away.\n\nPatch updated by Kirill:\n \"I'm pretty sure all gcc versions you can build kernel with supports\n  -std=gnu89.  cc-option is redunrant.\n\n  We also need to adjust HOSTCFLAGS otherwise allmodconfig fails for me\"\n\nNote by Andrew Pinski:\n \"Yes it was reported and both problems relating to this extension has\n  been added to gnu99 and gnu11.  Though there are other issues with the\n  kernel dealing with extern inline have different semantics between\n  gnu89 and gnu99/11\"\n\nEnd result: we may be able to move up to a newer stdc model eventually,\nbut right now the newer models have some annoying deficiencies, so the\ntraditional \"gnu89\" model ends up being the preferred one.\n\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>\nSinged-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","Kirill A. Shutemov",true],["675179bff16de23b65fdbeb5d392818cb45265cb","6cb58b8f5386ab909543bfc6eef5a0bd2950ca0a@gmail.com","alucard_hotplug: now nr_run_avg calculation is correct.","alucard24",true],["1c8a908bc835bacdd80a875e8a2334217ee4a2a3","aaf6fd97230863eae371b8b6c4c40693d5d84b30@bynet.co.il","Kernel 9.0","Dorimanx",true]],"size":5,"ref":"refs/heads/NO-KNOCK-CODE-KK","head":"1c8a908bc835bacdd80a875e8a2334217ee4a2a3"}