Makefile: tell gcc optimizer to never introduce new data races

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: Jiri 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: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Makefile: enable -Werror=implicit-int and -Werror=strict-prototypes by default

The common error found in forward-ported/backported patches is missing
headers.  One recent example (files and function names are mangled):

    void foo(){}
    EXPORT_SYMBOL(foo);

gave only warning

    foo.c:12345678:5: warning: function declaration isn't a prototype [-Wstrict-prototypes]
    void foo(){}
         ^

    foo.c:12345679:5: warning: data definition has no type or storage class [enabled by default]
    EXPORT_SYMBOL(foo);
    foo.c:12345679:5: warning: type defaults to 'int' in declaration of 'EXORT_SYMBOL' [-Werror=implicit-int]

Now it's a fatal error. Tested on x86_64 allyesconfig.

[akpm@linux-foundation.org: fix typos in comments]
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
kernel: use the gnu89 standard explicitly

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: Sasha Levin <sasha.levin@oracle.com>
Singed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
alucard_hotplug: now nr_run_avg calculation is correct.
Kernel 9.0
Added OPEN BUMP to build script. now we dont need LOKI any more.

Big Thanks to @cybojenix and to original BUMP dev team! :)
Added Recovery BUMP scripts in auto mode. READ MORE.

Just add your recovery model zip. and run recovery_bump.sh

Only ONE zip file can be in RECOVERY folder. it's must be not bumped yet.

find your ready recovery in RECOVERY/READY_RECOVERY/
alucard_hotplug: Use INIT_DELAYED_WORK for RQ_AVG calculation.
 intelli_hotplug: Remove unused cur_max percpu variable

* We removed its usage long since we dont want hotplug
  drivers to play with frequencies.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
staging: binder: Change binder mutex to rtmutex

Surfaceflinger uses binder heavily to receive/send frames from applications
while compositing the screen. Change the binder mutex to an rt mutex to minimize
instances where high priority surfaceflinger binder work is blocked by lower
priority binder ipc.

Signed-off-by: Riley Andrews <riandrews@google.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
writeback: increase bdi_min_ratio to 5

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
thermal-sys: Fix to send correct trip type to get trip temperature

Fix the thermal sys code to pass the proper trip type
expected by tsens driver, to get the tsens trip
temperature.

Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
GPU POWER LEVEL: set default init gpu pwr level to 320Mhz and 200 as default.
Linaro 2014.11 GCC 4.9.3 custom compiled for LG G2
TOUCH DRIVER: use the mutex lock for all models here, it's a FIX.
alucard_hotplug:
* Use TIMER DEFERRABLE workqueue.
* Disabled rq calc when phone is suspended.
* Use mod_delayed_work for RQ calc.
* Optimized code
Alucard HotPlug: code style cleanup. @Alucard24 please full sync.

from:
cleanfile: arch/arm/mach-msm/alucard_hotplug.c
arch/arm/mach-msm/alucard_hotplug.c:223: line exceeds 79 characters (86)
arch/arm/mach-msm/alucard_hotplug.c:236: line exceeds 79 characters (80)
arch/arm/mach-msm/alucard_hotplug.c:270: line exceeds 79 characters (84)
arch/arm/mach-msm/alucard_hotplug.c:281: line exceeds 79 characters (94)
arch/arm/mach-msm/alucard_hotplug.c:306: line exceeds 79 characters (189)
arch/arm/mach-msm/alucard_hotplug.c:316: line exceeds 79 characters (83)
arch/arm/mach-msm/alucard_hotplug.c:320: line exceeds 79 characters (191)
arch/arm/mach-msm/alucard_hotplug.c:322: line exceeds 79 characters (81)
arch/arm/mach-msm/alucard_hotplug.c:323: line exceeds 79 characters (83)
arch/arm/mach-msm/alucard_hotplug.c:324: line exceeds 79 characters (85)
arch/arm/mach-msm/alucard_hotplug.c:347: line exceeds 79 characters (89)
arch/arm/mach-msm/alucard_hotplug.c:416: line exceeds 79 characters (86)
arch/arm/mach-msm/alucard_hotplug.c:420: line exceeds 79 characters (93)
arch/arm/mach-msm/alucard_hotplug.c:431: line exceeds 79 characters (108)
arch/arm/mach-msm/alucard_hotplug.c:490: line exceeds 79 characters (89)
arch/arm/mach-msm/alucard_hotplug.c:530: line exceeds 79 characters (89)
arch/arm/mach-msm/alucard_hotplug.c:531: line exceeds 79 characters (105)
arch/arm/mach-msm/alucard_hotplug.c:532: line exceeds 79 characters (81)
arch/arm/mach-msm/alucard_hotplug.c:533: line exceeds 79 characters (105)
arch/arm/mach-msm/alucard_hotplug.c:534: line exceeds 79 characters (105)
arch/arm/mach-msm/alucard_hotplug.c:535: line exceeds 79 characters (129)
arch/arm/mach-msm/alucard_hotplug.c:537: line exceeds 79 characters (121)
arch/arm/mach-msm/alucard_hotplug.c:541: line exceeds 79 characters (81)
arch/arm/mach-msm/alucard_hotplug.c:748: line exceeds 79 characters (92)
arch/arm/mach-msm/alucard_hotplug.c:750: line exceeds 79 characters (101)
arch/arm/mach-msm/alucard_hotplug.c:889: line exceeds 79 characters (86)

to NONE...
qseecom: Just check current bus scaling mode in qseecom_suspend

In current qseecom_suspend function, qseecom will scale down bus
bandwidth if both of accumultive mode and current mode are not
INACTIVE. But if device goes into suspend before bus scaling timeout
happens, the accumulative mode may be zero but current mode is
still not INACTIVE. This may prevent the device going to suspend,
thus, make a change to just check current bus scaling mode in
qseecom_suspend.

Signed-off-by: Zhen Kong <zkong@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
qseecom: Add boundary checks for offset within message.

Qseecom driver does not have boundary checks for offset within the
message. So this patch add checks to validate the offsets sent by
client to modify data within the command request message and it
should not exceed the memory allocated for that message.

Signed-off-by: Mona Hossain <mhossain@codeaurora.org>
Signed-off-by: Mallikarjuna Reddy Amireddy <mamire@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Kernel 9.1