smdk4412: futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == uaddr2 in futex_requeue(..., requeue_pi=1)

If uaddr == uaddr2, then we have broken the rule of only requeueing from
a non-pi futex to a pi futex with this call.  If we attempt this, then
dangling pointers may be left for rt_waiter resulting in an exploitable
condition.

This change brings futex_requeue() in line with futex_wait_requeue_pi()
which performs the same check as per commit 6f7b0a2a5c0f ("futex: Forbid
uaddr == uaddr2 in futex_wait_requeue_pi()")

[ tglx: Compare the resulting keys as well, as uaddrs might be
  	different depending on the mapping ]

Fixes CVE-2014-3153.

Change-Id: Ieeb5485c94d8b0074fc112302c81f39ff1e4bf75
Reported-by: Pinkie Pie
Signed-off-by: Will Drewry <wad@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
cpufreq: Update to zzmoove 0.9-beta2

Changelog:

- support for setting a default settings profile at governor start without the need of using the tuneable 'profile_number'
  a default profile can be set with the already available macro 'DEF_PROFILE_NUMBER' check zzmoove_profiles.h for details about
  which profile numbers are possible. this functionality was only half baken in previous versions, now any given profile will be really
  applied when the governor starts. the value '0' (=profile name 'none') in 'DEF_PROFILE_NUMBER' disables this profile hardcoding and
  that's also the default in the source. u still can (with or without enabling a default profile in the macro) as usual use the tuneable
  'profile_number' to switch to a desired profile via sysfs at any later time after governor has started
- added 'blocking' of sysfs in all tuneables during apply of a settings profile to avoid a possible and unwanted overwriting/double
  setting of tuneables mostly in combination with tuning apps where the tuneable apply order isn't influenceable
- added tuneable 'profile_list' for printing out a list of all profiles which are available in the profile header file
- fixed non setting of 'scaling_block_force_down' tuneable when applying profiles
- some documentation added and a little bit of source cleaning
Omnirom ramfs: Update to nightly of 17.06.2014
su: update su to version 2.00
earysuspend: speedup late resume (faster wakeup of the device)

credits to Yank555.lu

Thanx to _2bad4u_ for the hint and dsc-team's repo I got the code from (https://github.com/dsc-team/dsc-team-kernel-project)
slub.c: little tweak for performance improvements
lowmemorykiller: Lower default debug_level
sched_fair: Reduce latencies
writeback: Fix occasional slow sync

In case when system contains no dirty pages, wakeup_flusher_threads()
will submit WB_SYNC_NONE writeback for 0 pages so wb_writeback() exits
immediately without doing anything. Thus sync(1) will write all the
dirty inodes from a WB_SYNC_ALL writeback pass which is slow.

Fix the problem by using get_nr_dirty_pages() in
wakeup_flusher_threads() instead of calculating number of dirty pages
manually. That function also takes number of dirty inodes into account.
mach-midas: Slightly increase thermal throttling temperatures and frequency for step1
mali: update driver from r3p2 rel3 to r3p2 rel4 + set older mali api for compatibility reasons

credits to JustArchi
boeffla_defconfig: enable speedup_keyresume
Release tag: 2.3-beta7