Rename TARGET_PRODUCT to TARGET_KERNEL_PRODUCT

Change-Id: I2542c5e13d2a44c7580b9935084964d925f22332
Signed-off-by: olivieer <yves.olli@gmail.com>
ARM: 7668/1: fix memset-related crashes caused by recent GCC (4.7.2) optimizations

Recent GCC versions (e.g. GCC-4.7.2) perform optimizations based on
assumptions about the implementation of memset and similar functions.
The current ARM optimized memset code does not return the value of
its first argument, as is usually expected from standard implementations.

For instance in the following function:

void debug_mutex_lock_common(struct mutex *lock, struct mutex_waiter *waiter)
{
	memset(waiter, MUTEX_DEBUG_INIT, sizeof(*waiter));
	waiter->magic = waiter;
	INIT_LIST_HEAD(&waiter->list);
}

compiled as:

800554d0 <debug_mutex_lock_common>:
800554d0:       e92d4008        push    {r3, lr}
800554d4:       e1a00001        mov     r0, r1
800554d8:       e3a02010        mov     r2, #16 ; 0x10
800554dc:       e3a01011        mov     r1, #17 ; 0x11
800554e0:       eb04426e        bl      80165ea0 <memset>
800554e4:       e1a03000        mov     r3, r0
800554e8:       e583000c        str     r0, [r3, #12]
800554ec:       e5830000        str     r0, [r3]
800554f0:       e5830004        str     r0, [r3, #4]
800554f4:       e8bd8008        pop     {r3, pc}

GCC assumes memset returns the value of pointer 'waiter' in register r0; causing
register/memory corruptions.

This patch fixes the return value of the assembly version of memset.
It adds a 'mov' instruction and merges an additional load+store into
existing load/store instructions.
For ease of review, here is a breakdown of the patch into 4 simple steps:

Step 1
======
Perform the following substitutions:
ip -> r8, then
r0 -> ip,
and insert 'mov ip, r0' as the first statement of the function.
At this point, we have a memset() implementation returning the proper result,
but corrupting r8 on some paths (the ones that were using ip).

Step 2
======
Make sure r8 is saved and restored when (! CALGN(1)+0) == 1:

save r8:
-       str     lr, [sp, #-4]!
+       stmfd   sp!, {r8, lr}

and restore r8 on both exit paths:
-       ldmeqfd sp!, {pc}               @ Now <64 bytes to go.
+       ldmeqfd sp!, {r8, pc}           @ Now <64 bytes to go.
(...)
        tst     r2, #16
        stmneia ip!, {r1, r3, r8, lr}
-       ldr     lr, [sp], #4
+       ldmfd   sp!, {r8, lr}

Step 3
======
Make sure r8 is saved and restored when (! CALGN(1)+0) == 0:

save r8:
-       stmfd   sp!, {r4-r7, lr}
+       stmfd   sp!, {r4-r8, lr}

and restore r8 on both exit paths:
        bgt     3b
-       ldmeqfd sp!, {r4-r7, pc}
+       ldmeqfd sp!, {r4-r8, pc}
(...)
        tst     r2, #16
        stmneia ip!, {r4-r7}
-       ldmfd   sp!, {r4-r7, lr}
+       ldmfd   sp!, {r4-r8, lr}

Step 4
======
Rewrite register list "r4-r7, r8" as "r4-r8".

Change-Id: Id7ccd44188078c7952dd0e547b29bd719dfac17f
Signed-off-by: Ivan Djelic <ivan.djelic@parrot.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7670/1: fix the memset fix

Commit 455bd4c430b0 ("ARM: 7668/1: fix memset-related crashes caused by
recent GCC (4.7.2) optimizations") attempted to fix a compliance issue
with the memset return value.  However the memset itself became broken
by that patch for misaligned pointers.

This fixes the above by branching over the entry code from the
misaligned fixup code to avoid reloading the original pointer.

Also, because the function entry alignment is wrong in the Thumb mode
compilation, that fixup code is moved to the end.

While at it, the entry instructions are slightly reworked to help dual
issue pipelines.

Change-Id: Ie9e59226176e9fadbc0c9463a3b2f5f5dd2b4581
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Alexander Holler <holler@ahsoftware.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
futex: Validate atomic acquisition in futex_lock_pi_atomic()

We need to protect the atomic acquisition in the kernel against rogue
user space which sets the user space futex to 0, so the kernel side
acquisition succeeds while there is existing state in the kernel
associated to the real owner.

Verify whether the futex has waiters associated with kernel state. If
it has, return -EINVAL. The state is corrupted already, so no point in
cleaning it up. Subsequent calls will fail as well. Not our problem.

[ tglx: Use futex_top_waiter() and explain why we do not need to try
  	restoring the already corrupted user space state. ]

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Drewry <wad@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Change-Id: I6c19ae4a5e85fbc9c560723e672d5136c4786ab6
futex: Add another early deadlock detection check

Dave Jones trinity syscall fuzzer exposed an issue in the deadlock
detection code of rtmutex:
  http://lkml.kernel.org/r/20140429151655.GA14277@...hat.com

That underlying issue has been fixed with a patch to the rtmutex code,
but the futex code must not call into rtmutex in that case because
    - it can detect that issue early
    - it avoids a different and more complex fixup for backing out

If the user space variable got manipulated to 0x80000000 which means
no lock holder, but the waiters bit set and an active pi_state in the
kernel is found we can figure out the recursive locking issue by
looking at the pi_state owner. If that is the current task, then we
can safely return -EDEADLK.

The check should have been added in commit 59fa62451 (futex: Handle
futex_pi OWNER_DIED take over correctly) already, but I did not see
the above issue caused by user space manipulation back then.

Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Cc: Dave Jones <davej@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Darren Hart <darren@...art.com>
Cc: Davidlohr Bueso <davidlohr@...com>
Cc: Steven Rostedt <rostedt@...dmis.org>
Cc: Clark Williams <williams@...hat.com>
Cc: Paul McKenney <paulmck@...ux.vnet.ibm.com>
Cc: Lai Jiangshan <laijs@...fujitsu.com>
Cc: Roland McGrath <roland@...k.frob.com>
Cc: Carlos ODonell <carlos@...hat.com>
Cc: Jakub Jelinek <jakub@...hat.com>
Cc: Michael Kerrisk <mtk.manpages@...il.com>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Link: http://lkml.kernel.org/r/20140512201701.097349971@...utronix.de
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

Change-Id: I245f77622443435cf36bbd157b98798c235acdb0
futex: Always cleanup owner tid in unlock_pi

If the owner died bit is set at futex_unlock_pi, we currently do not
cleanup the user space futex. So the owner TID of the current owner
(the unlocker) persists. That's observable inconsistant state,
especially when the ownership of the pi state got transferred.

Clean it up unconditionally.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Drewry <wad@chromium.org>
Cc: Darren Hart <dvhart@linux.intel.com>
Cc: stable@vger.kernel.org

Change-Id: Ic84473a62bdf3e5702f46e04b266afa38e9ec40e
futex: Make lookup_pi_state more robust

The current implementation of lookup_pi_state has ambigous handling of
the TID value 0 in the user space futex. We can get into the kernel
even if the TID value is 0, because either there is a stale waiters
bit or the owner died bit is set or we are called from the requeue_pi
path or from user space just for fun.

The current code avoids an explicit sanity check for pid = 0 in case
that kernel internal state (waiters) are found for the user space
address. This can lead to state leakage and worse under some
circumstances.

Handle the cases explicit:

     Waiter | pi_state | pi->owner | uTID      | uODIED | ?

[1]  NULL   | ---      | ---       | 0         | 0/1    | Valid
[2]  NULL   | ---      | ---       | >0        | 0/1    | Valid

[3]  Found  | NULL     | --        | Any       | 0/1    | Invalid

[4]  Found  | Found    | NULL      | 0         | 1      | Valid
[5]  Found  | Found    | NULL      | >0        | 1      | Invalid

[6]  Found  | Found    | task      | 0         | 1      | Valid

[7]  Found  | Found    | NULL      | Any       | 0      | Invalid

[8]  Found  | Found    | task      | ==taskTID | 0/1    | Valid
[9]  Found  | Found    | task      | 0         | 0      | Invalid
[10] Found  | Found    | task      | !=taskTID | 0/1    | Invalid

[1]  Indicates that the kernel can acquire the futex atomically. We
     came came here due to a stale FUTEX_WAITERS/FUTEX_OWNER_DIED bit.

[2]  Valid, if TID does not belong to a kernel thread. If no matching
     thread is found then it indicates that the owner TID has died.

[3]  Invalid. The waiter is queued on a non PI futex

[4]  Valid state after exit_robust_list(), which sets the user space
     value to FUTEX_WAITERS | FUTEX_OWNER_DIED.

[5]  The user space value got manipulated between exit_robust_list()
     and exit_pi_state_list()

[6]  Valid state after exit_pi_state_list() which sets the new owner in
     the pi_state but cannot access the user space value.

[7]  pi_state->owner can only be NULL when the OWNER_DIED bit is set.

[8]  Owner and user space value match

[9]  There is no transient state which sets the user space TID to 0
     except exit_robust_list(), but this is indicated by the
     FUTEX_OWNER_DIED bit. See [4]

[10] There is no transient state which leaves owner and user space
     TID out of sync.

Backport to 3.13
  conflicts: kernel/futex.c

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Drewry <wad@chromium.org>
Cc: Darren Hart <dvhart@linux.intel.com>
Cc: stable@vger.kernel.org

Change-Id: I967e3bb07b239941ea51af6b09d61d7b08138f40
Optimized ARM RWSEM algorithm

RWSEM implementation for ARM using atomic functions.
Heavily based on arch/sh/include/asm/rwsem.h

Change-Id: I1a774e8521c8af955f1e98ad31c9de22163e6395
Signed-off-by: Ashwin Chaugule <ashwinc@codeaurora.org>
lib: Update RWSEM to Linux 3.10

Squashed commit of the following:

commit 28f9a942e4e1578c0e26e8211ba49bdf520de95c
Author: Davidlohr Bueso <davidlohr.bueso@hp.com>
Date:   Tue May 7 06:46:02 2013 -0700

    rwsem: no need for explicit signed longs

    Change explicit "signed long" declarations into plain "long" as suggested
    by Peter Hurley.

    Signed-off-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
    Reviewed-by: Michel Lespinasse <walken@google.com>
    Signed-off-by: Michel Lespinasse <walken@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 353ad88b6af95bc7bb127b3b5b1cfa36c72a7b67
Author: Michel Lespinasse <walken@google.com>
Date:   Tue May 7 06:46:00 2013 -0700

    rwsem: do not block readers at head of queue if other readers are active

    This change fixes a race condition where a reader might determine it
    needs to block, but by the time it acquires the wait_lock the rwsem has
    active readers and no queued waiters.

    In this situation the reader can run in parallel with the existing
    active readers; it does not need to block until the active readers
    complete.

    Thanks to Peter Hurley for noticing this possible race.

    Signed-off-by: Michel Lespinasse <walken@google.com>
    Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
    Acked-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit e9149aa93e4e6919da4fe9e77a27f9c6a0159463
Author: Michel Lespinasse <walken@google.com>
Date:   Tue May 7 06:45:59 2013 -0700

    rwsem: implement support for write lock stealing on the fastpath

    When we decide to wake up readers, we must first grant them as many read
    locks as necessary, and then actually wake up all these readers.  But in
    order to know how many read shares to grant, we must first count the
    readers at the head of the queue.  This might take a while if there are
    many readers, and we want to be protected against a writer stealing the
    lock while we're counting.  To that end, we grant the first reader lock
    before counting how many more readers are queued.

    We also require some adjustments to the wake_type semantics.

    RWSEM_WAKE_NO_ACTIVE used to mean that we had found the count to be
    RWSEM_WAITING_BIAS, in which case the rwsem was known to be free as
    nobody could steal it while we hold the wait_lock.  This doesn't make
    sense once we implement fastpath write lock stealing, so we now use
    RWSEM_WAKE_ANY in that case.

    Similarly, when rwsem_down_write_failed found that a read lock was
    active, it would use RWSEM_WAKE_READ_OWNED which signalled that new
    readers could be woken without checking first that the rwsem was
    available.  We can't do that anymore since the existing readers might
    release their read locks, and a writer could steal the lock before we
    wake up additional readers.  So, we have to use a new RWSEM_WAKE_READERS
    value to indicate we only want to wake readers, but we don't currently
    hold any read lock.

    Signed-off-by: Michel Lespinasse <walken@google.com>
    Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
    Acked-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 20addabcb540eb4b4e11d7e8af037543767e081d
Author: Michel Lespinasse <walken@google.com>
Date:   Tue May 7 06:45:58 2013 -0700

    rwsem: simplify __rwsem_do_wake

    This is mostly for cleanup value:

    - We don't need several gotos to handle the case where the first
      waiter is a writer. Two simple tests will do (and generate very
      similar code).

    - In the remainder of the function, we know the first waiter is a reader,
      so we don't have to double check that. We can use do..while loops
      to iterate over the readers to wake (generates slightly better code).

    Signed-off-by: Michel Lespinasse <walken@google.com>
    Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
    Acked-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit e56c8eea2628841a06a2420e2c6ca8b8c6bd4434
Author: Michel Lespinasse <walken@google.com>
Date:   Tue May 7 06:45:57 2013 -0700

    rwsem: skip initial trylock in rwsem_down_write_failed

    We can skip the initial trylock in rwsem_down_write_failed() if there
    are known active lockers already, thus saving one likely-to-fail
    cmpxchg.

    Signed-off-by: Michel Lespinasse <walken@google.com>
    Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
    Acked-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
    Acked-by: Rik van Riel <riel@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 286040cc550df96bef6e97a5bc0231ded9a0187b
Author: Michel Lespinasse <walken@google.com>
Date:   Tue May 7 06:45:56 2013 -0700

    rwsem: avoid taking wait_lock in rwsem_down_write_failed

    In rwsem_down_write_failed(), if there are active locks after we wake up
    (i.e.  the lock got stolen from us), skip taking the wait_lock and go
    back to sleep immediately.

    Signed-off-by: Michel Lespinasse <walken@google.com>
    Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
    Acked-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
    Acked-by: Rik van Riel <riel@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 6c7229b31a4c099157242c58f5d33ce728daff4b
Author: Michel Lespinasse <walken@google.com>
Date:   Tue May 7 06:45:55 2013 -0700

    rwsem: use cmpxchg for trying to steal write lock

    Using rwsem_atomic_update to try stealing the write lock forced us to
    undo the adjustment in the failure path.  We can have simpler and faster
    code by using cmpxchg instead.

    Signed-off-by: Michel Lespinasse <walken@google.com>
    Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
    Acked-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
    Acked-by: Rik van Riel <riel@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 85dcaeae08b5738f8ea0b08734ab97e57bb9e8e2
Author: Michel Lespinasse <walken@google.com>
Date:   Tue May 7 06:45:54 2013 -0700

    rwsem: more agressive lock stealing in rwsem_down_write_failed

    Some small code simplifications can be achieved by doing more agressive
    lock stealing:

    - When rwsem_down_write_failed() notices that there are no active locks
      (and thus no thread to wake us if we decided to sleep), it used to wake
      the first queued process. However, stealing the lock is also sufficient
      to deal with this case, so we don't need this check anymore.

    - In try_get_writer_sem(), we can steal the lock even when the first waiter
      is a reader. This is correct because the code path that wakes readers is
      protected by the wait_lock. As to the performance effects of this change,
      they are expected to be minimal: readers are still granted the lock
      (rather than having to acquire it themselves) when they reach the front
      of the wait queue, so we have essentially the same behavior as in
      rwsem-spinlock.

    Signed-off-by: Michel Lespinasse <walken@google.com>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
    Acked-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 082a2e9c40e01d70c59ca4e3a9b552b81d573332
Author: Michel Lespinasse <walken@google.com>
Date:   Tue May 7 06:45:53 2013 -0700

    rwsem: simplify rwsem_down_write_failed

    When waking writers, we never grant them the lock - instead, they have
    to acquire it themselves when they run, and remove themselves from the
    wait_list when they succeed.

    As a result, we can do a few simplifications in rwsem_down_write_failed():

    - We don't need to check for !waiter.task since __rwsem_do_wake() doesn't
      remove writers from the wait_list

    - There is no point releaseing the wait_lock before entering the wait loop,
      as we will need to reacquire it immediately. We can change the loop so
      that the lock is always held at the start of each loop iteration.

    - We don't need to get a reference on the task structure, since the task
      is responsible for removing itself from the wait_list. There is no risk,
      like in the rwsem_down_read_failed() case, that a task would wake up and
      exit (thus destroying its task structure) while __rwsem_do_wake() is
      still running - wait_lock protects against that.

    Signed-off-by: Michel Lespinasse <walken@google.com>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
    Acked-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 6b3306dccd59d5dcf22e55a27827bccf51a796e1
Author: Michel Lespinasse <walken@google.com>
Date:   Tue May 7 06:45:52 2013 -0700

    rwsem: simplify rwsem_down_read_failed

    When trying to acquire a read lock, the RWSEM_ACTIVE_READ_BIAS
    adjustment doesn't cause other readers to block, so we never have to
    worry about waking them back after canceling this adjustment in
    rwsem_down_read_failed().

    We also never want to steal the lock in rwsem_down_read_failed(), so we
    don't have to grab the wait_lock either.

    Signed-off-by: Michel Lespinasse <walken@google.com>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
    Acked-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit c6b315c32d1ffbb33c75ab5e0f8ee27c89d206c4
Author: Michel Lespinasse <walken@google.com>
Date:   Tue May 7 06:45:51 2013 -0700

    rwsem: move rwsem_down_failed_common code into rwsem_down_{read,write}_failed

    Remove the rwsem_down_failed_common function and replace it with two
    identical copies of its code in rwsem_down_{read,write}_failed.

    This is because we want to make different optimizations in
    rwsem_down_{read,write}_failed; we are adding this pure-duplication
    step as a separate commit in order to make it easier to check the
    following steps.

    Signed-off-by: Michel Lespinasse <walken@google.com>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
    Acked-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 7d2869248ccd7971fc1b79e4bf22cb4be446faf4
Author: Michel Lespinasse <walken@google.com>
Date:   Tue May 7 06:45:50 2013 -0700

    rwsem: shorter spinlocked section in rwsem_down_failed_common()

    This change reduces the size of the spinlocked and TASK_UNINTERRUPTIBLE
    sections in rwsem_down_failed_common():

    - We only need the sem->wait_lock to insert ourselves on the wait_list;
      the waiter node can be prepared outside of the wait_lock.

    - The task state only needs to be set to TASK_UNINTERRUPTIBLE immediately
      before checking if we actually need to sleep; it doesn't need to protect
      the entire function.

    Signed-off-by: Michel Lespinasse <walken@google.com>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
    Acked-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 8c163f8ddf5c0bd018706dbdd44fb96a073401d0
Author: Michel Lespinasse <walken@google.com>
Date:   Tue May 7 06:45:49 2013 -0700

    rwsem: make the waiter type an enumeration rather than a bitmask

    We are not planning to add some new waiter flags, so we can convert the
    waiter type into an enumeration.

    Background: David Howells suggested I do this back when I tried adding
    a new waiter type for unfair readers. However, I believe the cleanup
    applies regardless of that use case.

    Signed-off-by: Michel Lespinasse <walken@google.com>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
    Acked-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 9a126edbed8ccfedda04d5c3fe256cd139d4bcca
Author: Alex Shi <alex.shi@intel.com>
Date:   Tue Feb 5 21:11:55 2013 +0800

    rwsem: Implement writer lock-stealing for better scalability

    Commit 5a505085f043 ("mm/rmap: Convert the struct anon_vma::mutex
    to an rwsem") changed struct anon_vma::mutex to an rwsem, which
    caused aim7 fork_test performance to drop by 50%.

    Yuanhan Liu did the following excellent analysis:

        https://lkml.org/lkml/2013/1/29/84

    and found that the regression is caused by strict, serialized,
    FIFO sequential write-ownership of rwsems. Ingo suggested
    implementing opportunistic lock-stealing for the front writer
    task in the waitqueue.

    Yuanhan Liu implemented lock-stealing for spinlock-rwsems,
    which indeed recovered much of the regression - confirming
    the analysis that the main factor in the regression was the
    FIFO writer-fairness of rwsems.

    In this patch we allow lock-stealing to happen when the first
    waiter is also writer. With that change in place the
    aim7 fork_test performance is fully recovered on my
    Intel NHM EP, NHM EX, SNB EP 2S and 4S test-machines.

    Reported-by: lkp@linux.intel.com
    Reported-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
    Signed-off-by: Alex Shi <alex.shi@intel.com>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Michel Lespinasse <walken@google.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Anton Blanchard <anton@samba.org>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: paul.gortmaker@windriver.com
    Link: https://lkml.org/lkml/2013/1/29/84
    Link: http://lkml.kernel.org/r/1360069915-31619-1-git-send-email-alex.shi@intel.com
    [ Small stylistic fixes, updated changelog. ]
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

commit 77302ff69a93cfba32aaee98d2bb864ba8886e40
Author: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Date:   Fri Feb 1 18:59:16 2013 +0800

    rwsem-spinlock: Implement writer lock-stealing for better scalability

    We (Linux Kernel Performance project) found a regression
    introduced by commit:

      5a505085f043 mm/rmap: Convert the struct anon_vma::mutex to an rwsem

    which converted all anon_vma::mutex locks rwsem write locks.

    The semantics are the same, but the behavioral difference is
    quite huge in some cases. After investigating it we found the
    root cause: mutexes support lock stealing while rwsems don't.

    Here is the link for the detailed regression report:

      https://lkml.org/lkml/2013/1/29/84

    Ingo suggested adding write lock stealing to rwsems:

        "I think we should allow lock-steal between rwsem writers - that
         will not hurt fairness as most rwsem fairness concerns relate to
         reader vs. writer fairness"

    And here is the rwsem-spinlock version.

    With this patch, we got a double performance increase in one
    test box with following aim7 workfile:

        FILESIZE: 1M
        POOLSIZE: 10M
        10 fork_test

     /usr/bin/time output w/o patch                       /usr/bin/time_output with patch
     -- Percent of CPU this job got: 369%                 Percent of CPU this job got: 537%
     Voluntary context switches: 640595016                Voluntary context switches: 157915561

    We got a 45% increase in CPU usage and saved about 3/4 voluntary context switches.

    Reported-by: LKP project <lkp@linux.intel.com>
    Suggested-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
    Cc: Alex Shi <alex.shi@intel.com>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Michel Lespinasse <walken@google.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Anton Blanchard <anton@samba.org>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: paul.gortmaker@windriver.com
    Link: http://lkml.kernel.org/r/1359716356-23865-1-git-send-email-yuanhan.liu@linux.intel.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

commit 95f8b6683b3f83e40a8ab0d93a9d155954b64396
Author: Andrei F <luxneb@gmail.com>
Date:   Wed Aug 21 21:49:39 2013 +0400

    ARM: rwsem: Update header from initial implementation

    Cleanup due to:

    c16a87ce063f79e0ec7d25ce2950e1bc6db03c72 rwsem: Cleanup includes
    1c8ed640d918290ddc1de5ada02ef6686a733c9f rwsem: Move duplicate struct rwsem declaration to linux/rwsem.h
    12249b34414dba7f386aadcf6be7ca36c6878300 rwsem: Move duplicate init macros and functions to linux/rwsem.h
    41e5887fa39ab272d9266a09cbefdef270e28b93 rwsem: Unify the duplicate rwsem_is_locked() inlines
    aac72277fda6ef788bb8d5deaa502ce9b9b6e472 rwsem: Move duplicate function prototypes to linux/rwsem.h

Change-Id: I9e3b911dae1eff816c9440fffeddaae58fd1d66f
net: guard tcp_set_keepalive() to tcp sockets

Its possible to use RAW sockets to get a crash in
tcp_set_keepalive() / sk_reset_timer()

Fix is to make sure socket is a SOCK_STREAM one.

Change-Id: Ieeb498a3e623cfcb54e1c865a3c0229e4acf1e87
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove '+' symbol from kernel version string

Change-Id: Ie4179b59ac6e503b4003ba24f6ba3d753c3da49c
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
SELinux: Fix kernel BUG on empty security contexts.

Setting an empty security context (length=0) on a file will
lead to incorrectly dereferencing the type and other fields
of the security context structure, yielding a kernel BUG.
As a zero-length security context is never valid, just reject
all such security contexts whether coming from userspace
via setxattr or coming from the filesystem upon a getxattr
request by SELinux.

Setting a security context value (empty or otherwise) unknown to
SELinux in the first place is only possible for a root process
(CAP_MAC_ADMIN), and, if running SELinux in enforcing mode, only
if the corresponding SELinux mac_admin permission is also granted
to the domain by policy.  In Fedora policies, this is only allowed for
specific domains such as livecd for setting down security contexts
that are not defined in the build host policy.

[On Android, this can only be set by root/CAP_MAC_ADMIN processes,
and if running SELinux in enforcing mode, only if mac_admin permission
is granted in policy.  In Android 4.4, this would only be allowed for
root/CAP_MAC_ADMIN processes that are also in unconfined domains. In current
AOSP master, mac_admin is not allowed for any domains except the recovery
console which has a legitimate need for it.  The other potential vector
is mounting a maliciously crafted filesystem for which SELinux fetches
xattrs (e.g. an ext4 filesystem on a SDcard).  However, the end result is
only a local denial-of-service (DOS) due to kernel BUG.  This fix is
queued for 3.14.]

Reproducer:
su
setenforce 0
touch foo
setfattr -n security.selinux foo

Caveat:
Relabeling or removing foo after doing the above may not be possible
without booting with SELinux disabled.  Any subsequent access to foo
after doing the above will also trigger the BUG.

BUG output from Matthew Thode:
[  473.893141] ------------[ cut here ]------------
[  473.962110] kernel BUG at security/selinux/ss/services.c:654!
[  473.995314] invalid opcode: 0000 [#6] SMP
[  474.027196] Modules linked in:
[  474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G      D   I
3.13.0-grsec #1
[  474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
07/29/10
[  474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
ffff8805f50cd488
[  474.183707] RIP: 0010:[<ffffffff814681c7>]  [<ffffffff814681c7>]
context_struct_compute_av+0xce/0x308
[  474.219954] RSP: 0018:ffff8805c0ac3c38  EFLAGS: 00010246
[  474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
0000000000000100
[  474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
ffff8805e8aaa000
[  474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
0000000000000006
[  474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
0000000000000006
[  474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
0000000000000000
[  474.453816] FS:  00007f2e75220800(0000) GS:ffff88061fc00000(0000)
knlGS:0000000000000000
[  474.489254] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
00000000000207f0
[  474.556058] Stack:
[  474.584325]  ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
ffff8805f1190a40
[  474.618913]  ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
ffff8805e8aac860
[  474.653955]  ffff8805c0ac3cb8 000700068113833a ffff880606c75060
ffff8805c0ac3d94
[  474.690461] Call Trace:
[  474.723779]  [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a
[  474.778049]  [<ffffffff81468824>] security_compute_av+0xf4/0x20b
[  474.811398]  [<ffffffff8196f419>] avc_compute_av+0x2a/0x179
[  474.843813]  [<ffffffff8145727b>] avc_has_perm+0x45/0xf4
[  474.875694]  [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31
[  474.907370]  [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e
[  474.938726]  [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22
[  474.970036]  [<ffffffff811b057d>] vfs_getattr+0x19/0x2d
[  475.000618]  [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91
[  475.030402]  [<ffffffff811b063b>] vfs_lstat+0x19/0x1b
[  475.061097]  [<ffffffff811b077e>] SyS_newlstat+0x15/0x30
[  475.094595]  [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3
[  475.148405]  [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b
[  475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
[  475.255884] RIP  [<ffffffff814681c7>]
context_struct_compute_av+0xce/0x308
[  475.296120]  RSP <ffff8805c0ac3c38>
[  475.328734] ---[ end trace f076482e9d754adc ]---

[sds:  commit message edited to note Android implications and
to generate a unique Change-Id for gerrit]

Change-Id: I4d5389f0cfa72b5f59dada45081fa47e03805413
Reported-by:  Matthew Thode <mthode@mthode.org>
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Cc: stable@vger.kernel.org
Signed-off-by: Paul Moore <pmoore@redhat.com>
SELinux: include definition of new capabilities

The kernel has added CAP_WAKE_ALARM and CAP_EPOLLWAKEUP.  We need to
define these in SELinux so they can be mediated by policy.

Change-Id: I8a3e0db15ec5f4eb05d455a57e8446a8c2b484c2
Signed-off-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
[sds: rename epollwakeup to block_suspend to match upstream merge]
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
SELinux: Fix possible NULL pointer dereference in selinux_inode_permission()

While running stress tests on adding and deleting ftrace instances I hit
this bug:

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
  IP: selinux_inode_permission+0x85/0x160
  PGD 63681067 PUD 7ddbe067 PMD 0
  Oops: 0000 [#1] PREEMPT
  CPU: 0 PID: 5634 Comm: ftrace-test-mki Not tainted 3.13.0-rc4-test-00033-gd2a6dde-dirty #20
  Hardware name:                  /DG965MQ, BIOS MQ96510J.86A.0372.2006.0605.1717 06/05/2006
  task: ffff880078375800 ti: ffff88007ddb0000 task.ti: ffff88007ddb0000
  RIP: 0010:[<ffffffff812d8bc5>]  [<ffffffff812d8bc5>] selinux_inode_permission+0x85/0x160
  RSP: 0018:ffff88007ddb1c48  EFLAGS: 00010246
  RAX: 0000000000000000 RBX: 0000000000800000 RCX: ffff88006dd43840
  RDX: 0000000000000001 RSI: 0000000000000081 RDI: ffff88006ee46000
  RBP: ffff88007ddb1c88 R08: 0000000000000000 R09: ffff88007ddb1c54
  R10: 6e6576652f6f6f66 R11: 0000000000000003 R12: 0000000000000000
  R13: 0000000000000081 R14: ffff88006ee46000 R15: 0000000000000000
  FS:  00007f217b5b6700(0000) GS:ffffffff81e21000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033^M
  CR2: 0000000000000020 CR3: 000000006a0fe000 CR4: 00000000000007f0
  Call Trace:
    security_inode_permission+0x1c/0x30
    __inode_permission+0x41/0xa0
    inode_permission+0x18/0x50
    link_path_walk+0x66/0x920
    path_openat+0xa6/0x6c0
    do_filp_open+0x43/0xa0
    do_sys_open+0x146/0x240
    SyS_open+0x1e/0x20
    system_call_fastpath+0x16/0x1b
  Code: 84 a1 00 00 00 81 e3 00 20 00 00 89 d8 83 c8 02 40 f6 c6 04 0f 45 d8 40 f6 c6 08 74 71 80 cf 02 49 8b 46 38 4c 8d 4d cc 45 31 c0 <0f> b7 50 20 8b 70 1c 48 8b 41 70 89 d9 8b 78 04 e8 36 cf ff ff
  RIP  selinux_inode_permission+0x85/0x160
  CR2: 0000000000000020

Investigating, I found that the inode->i_security was NULL, and the
dereference of it caused the oops.

in selinux_inode_permission():

	isec = inode->i_security;

	rc = avc_has_perm_noaudit(sid, isec->sid, isec->sclass, perms, 0, &avd);

Note, the crash came from stressing the deletion and reading of debugfs
files.  I was not able to recreate this via normal files.  But I'm not
sure they are safe.  It may just be that the race window is much harder
to hit.

What seems to have happened (and what I have traced), is the file is
being opened at the same time the file or directory is being deleted.
As the dentry and inode locks are not held during the path walk, nor is
the inodes ref counts being incremented, there is nothing saving these
structures from being discarded except for an rcu_read_lock().

The rcu_read_lock() protects against freeing of the inode, but it does
not protect freeing of the inode_security_struct.  Now if the freeing of
the i_security happens with a call_rcu(), and the i_security field of
the inode is not changed (it gets freed as the inode gets freed) then
there will be no issue here.  (Linus Torvalds suggested not setting the
field to NULL such that we do not need to check if it is NULL in the
permission check).

Note, this is a hack, but it fixes the problem at hand.  A real fix is
to restructure the destroy_inode() to call all the destructor handlers
from the RCU callback.  But that is a major job to do, and requires a
lot of work.  For now, we just band-aid this bug with this fix (it
works), and work on a more maintainable solution in the future.

Link: http://lkml.kernel.org/r/20140109101932.0508dec7@gandalf.local.home
Link: http://lkml.kernel.org/r/20140109182756.17abaaa8@gandalf.local.home

Change-Id: I9fc03e450558d84e9ffb277ceb9035c21a7eb080
Cc: stable@vger.kernel.org
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>