hrtimer: Don't reinitialize a cpu_base's lock on CPU_UP

The current code makes the assumption that a cpu_base lock cannot
be held if a CPU is offline, which is tragically wrong.

If a hrtimer is not queued, then it will not be migrated by
migrate_hrtimers() when a CPU is offlined. Therefore, the
hrtimer's cpu_base may still point to a CPU which has
subsequently gone offline if the timer wasn't enqueued at the
time the CPU went down.

Normally this wouldn't be a problem, but a cpu_base's lock is
blindly reinitialized each time a CPU is brought up. If a CPU is
brought online during the period that another thread is
performing a hrtimer operation on a stale hrtimer, then the lock
will be reinitialized under its feet, and a SPIN_BUG() like the
following will be observed:

 [  448.212369] BUG: spinlock already unlocked on CPU#3,
 swapper/3/0
[  448.217368]  lock: 0xc47b1a40, .magic: dead4ead, .owner:
swapper/3/0, .owner_cpu: -1
[  448.217398] [<c0014398>] (unwind_backtrace+0x0/0x120) from
[<c0269ab0>] (do_raw_spin_unlock+0x44/0xdc)
[  448.217419] [<c0269ab0>] (do_raw_spin_unlock+0x44/0xdc) from
[<c071bbb0>] (_raw_spin_unlock_irqrestore+0xc/0x38)
[  448.217438] [<c071bbb0>]
(_raw_spin_unlock_irqrestore+0xc/0x38) from [<c00aa498>]
(hrtimer_try_to_cancel+0xf8/0x10c)
[  448.217455] [<c00aa498>] (hrtimer_try_to_cancel+0xf8/0x10c)
from [<c00aa4bc>] (hrtimer_cancel+0x10/0x20)
[  448.217475] [<c00aa4bc>] (hrtimer_cancel+0x10/0x20) from
[<c00e6934>] (rcu_idle_exit_common+0x5c/0xe0)
[  448.217494] [<c00e6934>] (rcu_idle_exit_common+0x5c/0xe0) from
[<c00e6ae8>] (rcu_idle_exit+0x9c/0xb4)
[  448.217514] [<c00e6ae8>] (rcu_idle_exit+0x9c/0xb4) from
[<c000f2dc>] (cpu_idle+0x98/0xf0)
[  448.217529] [<c000f2dc>] (cpu_idle+0x98/0xf0) from
[<000081ac>] (0x81ac)

CRs-Fixed: 460670
Change-Id: I588f6a864054abe6d4c249aad815c6d2f5a54077
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Merge "hrtimer: Don't reinitialize a cpu_base's lock on CPU_UP"
msm: camera: Fix camera crash in msm_open_config

Add proper check before accessing mctl handle to
avoid camera crash.

Change-Id: I1413f086ab7d94fe223a814bb16867d1dcc0a4bf
CRs-Fixed: 481757
Signed-off-by: Aditya Jonnalagadda <ajonnala@codeaurora.org>
signal: always clear sa_restorer on execve

When the new signal handlers are set up, the location of sa_restorer is
not cleared, leaking a parent process's address space location to
children.  This allows for a potential bypass of the parent's ASLR by
examining the sa_restorer value returned when calling sigaction().

Based on what should be considered "secret" about addresses, it only
matters across the exec not the fork (since the VMAs haven't changed
until the exec).  But since exec sets SIG_DFL and keeps sa_restorer,
this is where it should be fixed.

Given the few uses of sa_restorer, a "set" function was not written
since this would be the only use.  Instead, we use
__ARCH_HAS_SA_RESTORER, as already done in other places.

Example of the leak before applying this patch:

  $ cat /proc/$$/maps
  ...
  7fb9f3083000-7fb9f3238000 r-xp 00000000 fd:01 404469 .../libc-2.15.so
  ...
  $ ./leak
  ...
  7f278bc74000-7f278be29000 r-xp 00000000 fd:01 404469 .../libc-2.15.so
  ...
  1 0 (nil) 0x7fb9f30b94a0
  2 4000000 (nil) 0x7f278bcaa4a0
  3 4000000 (nil) 0x7f278bcaa4a0
  4 0 (nil) 0x7fb9f30b94a0
  ...

[akpm@linux-foundation.org: use SA_RESTORER for backportability]
Signed-off-by: Kees Cook <keescook@chromium.org>
Reported-by: Emese Revfy <re.emese@gmail.com>
Cc: Emese Revfy <re.emese@gmail.com>
Cc: PaX Team <pageexec@freemail.hu>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Serge Hallyn <serge.hallyn@canonical.com>
Cc: Julien Tinnes <jln@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Change-Id: I7ae396ee90c2339c86f7b773d15f5571f8fd54c5
Signed-off-by: Akhila Musunuri <makhila@codeaurora.org>
msm_fb: display: issue completion when disabling vsync irq

When vsync irq is disabled, vsync_wait_cnt is reset to zero and
completion is issued out as they are done in isr to make sure all
wait_for_completion is released.

Change-Id: I689f0c8cde43404d0caf5bb4644efa6385798d0e
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
Merge "signal: always clear sa_restorer on execve"
Merge "msm_fb: display: issue completion when disabling vsync irq"
Merge "msm: camera: Fix camera crash in msm_open_config"
msm: audio: qdsp6v2: Add size safety check to ACDB driver

Check that the size sent by userspace is not larger
then the internal amount allowed. This protects
against overflowing the stack due to an invalid size.

Change-Id: I8230fdb00a7b57d398929e8ab0eb6587476f3db1
CRs-fixed: 470222
Signed-off-by: Ben Romberger <bromberg@codeaurora.org>
Merge "msm: audio: qdsp6v2: Add size safety check to ACDB driver"
power: pm8921-bms: fix SOC jumps while entering suspend/resume

The last_soc is being set to -EINVAL when entering suspend. This
causes SOC to jump while coming out of resume.

Instead remember
If we are reporting for the first time after suspend.
The calculated_soc at the time we went to suspend.

Soc should not increase because we cannot suspend while
charging. If the calculated_soc has increased continue reporting
the lower last_soc.

If the calculated soc has dropped check if it has dropped since
suspend. If so decrease the reported soc by the amount it dropped
since suspend.

If the calculated soc has dropped but it has increased since suspend
continue to report the last_soc.

Change-Id: I9040feceaa3e829d11bec0b21e61951f2ed1180b
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: Xiaozhe Shi <xiaozhes@codeaurora.org>
power: pm8921-bms: Cancel/schedule work across suspend/resume

Clean up the work before going into suspend to avoid any
race during resume.

While at it, fix the timing comparison during resume
and use the de-referenced chip pointer.

Change-Id: I9e6dbe49e6ad5ebf1cdf9a3cd0ec7f57aa6495c6
Signed-off-by: Anirudh Ghayal <aghayal@codeaurora.org>
power: pm8921-bms: Fine tune SOC reporting during suspend/resume

Report SOC based on the time for which the system was suspended.

Remember -
1. If we recalculated the SOC in resume
2. The last_soc before going into suspend

Two cases arise - if we had a short suspend or if the suspend
was significant to case a drop in SOC. For the former do not
report a change in SOC and for the latter, report the
newly calculated_soc. In either of the cases, soc should not
increase because we cannot suspend while charging.

There is a possibility that the report_soc may be called
before BMS resume (update_power_supply), causing the driver
to report the old SOC. Handle this case by setting state
variables before recalculating the soc in resume.

CRs-Fixed: 482611
Change-Id: Ic21a24a1126800011f5e7e4531c1953436812811
Signed-off-by: Anirudh Ghayal <aghayal@codeaurora.org>
Merge "power: pm8921-bms: fix SOC jumps while entering suspend/resume"
Merge "power: pm8921-bms: Cancel/schedule work across suspend/resume"
Merge "power: pm8921-bms: Fine tune SOC reporting during suspend/resume"
msm:rq_stats: Register for Cpufreq policy notification

Currently the load of the system is calculated using the max
frequency that is read during startup(It does not get updated
when the policy changes). As a result, the average load of the
system is incorrectly calculated and the system might not bring
the cpus online to manage the additional load. This
reduces the performance of the system.

To fix this issue, register rq_stats to receive cpufreq policy
notifications. Update the policy's max frequency when a
notification is received and use that value to calculate the load.

Change-Id: Icc78e28c736c170e198f723fd96c13dfb2dafe8a
Signed-off-by: Archana Sathyakumar <asathyak@codeaurora.org>
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
cpufreq: Resolve CPUFREQ_NOTIFY issue

When the cpufreq_stat receives the frequency policy notification,
it checks if the frequency table and stats table are present for the cpu.
If both are present, it returns with -EBUSY error to the notification.
Due to this, none of the other registered modules receive this
notification.

If the stat table and sysfs nodes are already created, return 0 instead
of returning EBUSY error.

Change-Id: I1fd4a46e6a65edfc6253c4271288f10912ae2ad7
Signed-off-by: Archana Sathyakumar <asathyak@codeaurora.org>
msm: camera: Release mutex lock in case of failure

Release mutex lock in camera driver in case of a
failure.

Change-Id: Idc7de63b320df69754ad26fa9ae9639a08c96fc4
Signed-off-by: Suresh Vankadara <svankada@codeaurora.org>
msm: camera: Fix event queue drain issue

when camera daemon is killed, then command processing
timeout happens and there is a possibility of pending
event payload data. It creates a problem for further
command processing due to mismatch of event ids.
Drain the event payload queue when there is a timeout
for any event.

Change-Id: I046baf5ecc8abc8e795f96f8a1701da5c8506b88
CRs-Fixed: 467053
Signed-off-by: Suresh Vankadara <svankada@codeaurora.org>