max77693-private: Fix build with power sharing disabled
futex: Prevent attaching to kernel threads

We happily allow userspace to declare a random kernel thread to be the
owner of a user space PI futex.

Found while analysing the fallout of Dave Jones syscall fuzzer.

We also should validate the thread group for private futexes and find
some fast way to validate whether the "alleged" owner has RW access on
the file which backs the SHM, but that's a separate issue.

Change-Id: I03941dc5737bcb9d3ddd2ec88f7c263c27a1247d
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Dave Jones <davej@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Darren Hart <darren@dvhart.com>
Cc: Davidlohr Bueso <davidlohr@hp.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Clark Williams <williams@redhat.com>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Roland McGrath <roland@hack.frob.com>
Cc: Carlos ODonell <carlos@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: http://lkml.kernel.org/r/20140512201701.194824402@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
ext4: Speedup WB_SYNC_ALL pass called from sync(2)

When doing filesystem wide sync, there's no need to force transaction
commit (or synchronously write inode buffer) separately for each inode
because ext4_sync_fs() takes care of forcing commit at the end (VFS
takes care of flushing buffer cache, respectively). Most of the time
this slowness doesn't manifest because previous WB_SYNC_NONE writeback
doesn't leave much to write but when there are processes aggressively
creating new files and several filesystems to sync, the sync slowness
can be noticeable. In the following test script sync(1) takes around 6
minutes when there are two ext4 filesystems mounted on a standard SATA
drive. After this patch sync takes a couple of seconds so we have about
two orders of magnitude improvement.

      function run_writers
      {
        for (( i = 0; i < 10; i++ )); do
          mkdir $1/dir$i
          for (( j = 0; j < 40000; j++ )); do
            dd if=/dev/zero of=$1/dir$i/$j bs=4k count=4 &>/dev/null
          done &
        done
      }

      for dir in "$@"; do
        run_writers $dir
      done

      sleep 40
      time sync

Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Version 0.9 beta4

Changelog:

- removed 'freq_step' functionality as it never had any function in this governor. it was a left over from mialwes 'smoove' governor and also
  had no function in his governor back then. so yeah all the 'feelings' about it's influence were placebo :)
- introduced 'proportional scaling' for more 'connectivity' to current load, this should give more 'balanced' frequencies
  in general. when enabled all targeted frequencies in scaling logic will be compared with the ones from system table method and at the end
  the lowest of them both will be used. so all used scaling frequencies will be 'tentential' lower in both directions
- added support for exynos4 CPU temperature reading (patches available in zzmoove repositories: https://github.com/zanezam)
  this must be enabled via 'CONFIG_EXYNOS4_EXPORT_TEMP=y' in the config of a kernel which has exynos4 CPU temperature export implementation
  included. the default temp polling interval is 1000 ms and can be set with DEF_TMU_READ_DELAY. however the TMU driver has it's own polling
  interval which is 10 seconds, so leaving it at the default value of 1 second is recommended temperature reading will only be enabled if the
  tuneable 'scaling_block_temp' is set and will be disabled whenever early suspend is entered
- if exynos4 CPU temperature reading is enabled in the code use current CPU temperature in scaling block functionality to be able to 'hold' the cpu
  temperatue to the given one in 'scaling_block_temp'. this function is used in combination with the already existent tuneable 'scaling_block_freq'
  so u have to set both to enable it. the possible temperature range is 30°C to 80°C (lower temps are making no sense and higher temps would reach
  into exynos4 TMU driver trottling range)
- if exynos4 CPU temperature reading is enabled added current CPU temperature to debug info tuneable
- added auto adjustment of all available frequency thresholds when scaling max limit has changed
- improved sampling rate idle switching by making it scaling thresholds independent
- again some code style and comment changes/fixes

profile header file (Version 0.2 beta3):

- added scaling block temperature tuneable to all profiles if CONFIG_EXYNOS4_EXPORT_TEMP is defined
- use CPU temperature treshold of 65°C instead of 15 scaling block cycles in game profile if
  CONFIG_EXYNOS4_EXPORT_TEMP is defined
- added proportional frequency tuneable to all profiles
- added auto adjust freq thresholds to all profiles (disabled by default)
- enabled scaling proportional in ybat, ybatext, zzbat, zzbatp, zzmod and zzgame profile
- enabled scaling fast down over 1200MHz and resposiveness over 400Mhz with up threshold of 20
  in ybat, ybatext, zzbat, zzbatp, and zzmod profile
- added core macros to exclude not used code like it is in governor
- removed freq_step tuneable from all profiles
sync: don't block the flusher thread waiting on IO
sched_fair: Reduce latencies
ARM: cpu topology: Enable ARCH_POWER
fix camera crash in some cases
cpufreq: Fix policy stucking if user & kernel min/max don't overlap

Every __cpufreq_set_policy starts with checking the new policy min/max
has
some overlap with the current policy min/max. This works out fine until
we
end up with the policy min/max being set to a range that doesn't overlap
with the user policy min/max. Once we get into this situation, the check
at
the start of __cpufreq_set_policy fails and prevents us from getting out
of
this state.

This only happens when one of the CPUFREQ_ADJUST/CPUFREQ_INCOMPATIBLE
notifiers called inside __cpufreq_set_policy pick a min/max outside the
range of user policy min/max.

The real intent of the check at the start of __cpufreq_set_policy is to
make sure userspace can't set user policy min > user policy max. Since
__cpufreq_set_policy always gets called only with current user policy
min/max except when the actual user space policy min/max is changed, we
can
fix the issue by simply checking the new policy min/max against current
user policy min/max.

Change-Id: Iaac805825e64d7985c41fb9052bd96baacdf3d6f
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
mms_ts: Touchboost switch - improved sysfs input validation
tcp: Proportional Rate Reduction for TCP

credits to faux123
bcmdhd: Enable wifi mac address changing
Boeffla Sound: Improved sysfs input validation
Boeffla Sound: Fixed bug in improved sysfs input validation