stweaks: add arch_power switch + lowmemorykiller profiles
random: back to stock
Revert "GE: back to normal IR"

This reverts commit 6c636a657d6e1f8faea2f3368b870701d837d2b5.
block: Fix computation of merged request priority

commit ece9c72accdc45c3a9484dacb1125ce572647288 upstream. Priority of a
merged request is computed by ioprio_best(). If one of the requests has
undefined priority (IOPRIO_CLASS_NONE) and another request has priority
from IOPRIO_CLASS_BE, the function will return the undefined priority
which is wrong. Fix the function to properly return priority of a
request with the defined priority. Fixes:
d58cdfb89ce0c6bd5f81ae931a984ef298dbda20 Signed-off-by: Jan Kara
<jack@suse.cz> Reviewed-by: Jeff Moyer <jmoyer@redhat.com> Signed-off-
by: Jens Axboe <axboe@fb.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>
OOM, PM: OOM killed task shouldn't escape PM suspend

PM freezer relies on having all tasks frozen by the time devices are
getting frozen so that no task will touch them while they are getting
frozen. But OOM killer is allowed to kill an already frozen task in
order to handle OOM situtation. In order to protect from late wake ups
OOM killer is disabled after all tasks are frozen. This, however, still
keeps a window open when a killed task didn't manage to die by the time
freeze_processes finishes.

Reduce the race window by checking all tasks after OOM killer has been
disabled. This is still not race free completely unfortunately because
oom_killer_disable cannot stop an already ongoing OOM killer so a task
might still wake up from the fridge and get killed without
freeze_processes noticing. Full synchronization of OOM and freezer is,
however, too heavy weight for this highly unlikely case.

Introduce and check oom_kills counter which gets incremented early when
the allocator enters __alloc_pages_may_oom path and only check all the
tasks if the counter changes during the freezing attempt. The counter
is updated so early to reduce the race window since allocator checked
oom_killer_disabled which is set by PM-freezing code. A false positive
will push the PM-freezer into a slow path but that is not a big deal.

Changes since v1
- push the re-check loop out of freeze_processes into
check_frozen_processes and invert the condition to make the code more
readable as per Rafael

Fixes: f660daac474c6f (oom: thaw threads if oom killed thread is frozen
before deferring)
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
cpufreq: expose scaling_cur_freq sysfs file for set_policy() drivers

Currently the core does not expose scaling_cur_freq for set_policy()
drivers this breaks some userspace monitoring tools.
Change the core to expose this file for all drivers and if the
set_policy() driver supports the get() callback use it to retrieve the
current frequency.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=73741
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
block: fix alignment_offset math that assumes io_min is a power-of-2

The math in both blk_stack_limits() and queue_limit_alignment_offset()
assume that a block device's io_min (aka minimum_io_size) is always a
power-of-2.  Fix the math such that it works for non-power-of-2 io_min.

This issue (of alignment_offset != 0) became apparent when testing
dm-thinp with a thinp blocksize that matches a RAID6 stripesize of
1280K.  Commit fdfb4c8c1 ("dm thin: set minimum_io_size to pool's data
block size") unlocked the potential for alignment_offset != 0 due to
the dm-thin-pool's io_min possibly being a non-power-of-2.

Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
cpufreq: Avoid crash in resume on SMP without OPP

When resuming from s2ram on an SMP system without cpufreq operating
points (e.g. there's no "operating-points" property for the CPU node in
DT, or the platform doesn't use DT yet), the kernel crashes when
bringing CPU 1 online:

    Enabling non-boot CPUs ...
    CPU1: Booted secondary processor
    Unable to handle kernel NULL pointer dereference at virtual address
0000003c
    pgd = ee5e6b00
    [0000003c] *pgd=6e579003, *pmd=6e588003, *pte=00000000
    Internal error: Oops: a07 [#1] SMP ARM
    Modules linked in:
    CPU: 0 PID: 1246 Comm: s2ram Tainted: G        W
3.18.0-rc3-koelsch-01614-g0377af242bb175c8-dirty #589
    task: eeec5240 ti: ee704000 task.ti: ee704000
    PC is at __cpufreq_add_dev.isra.24+0x24c/0x77c
    LR is at __cpufreq_add_dev.isra.24+0x244/0x77c
    pc : [<c0298efc>]    lr : [<c0298ef4>]    psr: 60000153
    sp : ee705d48  ip : ee705d48  fp : ee705d84
    r10: c04e0450  r9 : 00000000  r8 : 00000001
    r7 : c05426a8  r6 : 00000001  r5 : 00000001  r4 : 00000000
    r3 : 00000000  r2 : 00000000  r1 : 20000153  r0 : c0542734

Verify that policy is not NULL before dereferencing it to fix this.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Fixes: 8414809c6a1e (cpufreq: Preserve policy structure across
suspend/resume)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert "OOM, PM: OOM killed task shouldn't escape PM suspend"

This reverts commit 988cf30191e63e7910c18090081ae040d946656f.
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>
arch/arm : some changes from 3.14 kernel
buildenv
arch/arm : compile with hardfloat + neon-vfpv4
ramfs: arch_power off by default