Revert "vfs: Rename end_writeback() to clear_inode()"

This reverts commit 5823ba041a389ac7fbd96aba220f634ce8b11737.
Mute charger/thermal/touchscreen crazy verbose debug
Signed-off-by: renderbroken <zkennedy87@gmail.com>
Remove more kmsg spam.

Change-Id: I42a9ef8e415cb7503dd9210fecba0f1eb07b7082
Remove log spam.

Change-Id: I2f715844e9f416707a01f62abe0b81f05de0ec56

Conflicts:
	net/ipv6/addrconf.c

Conflicts:
	include/linux/input/lge_touch_core.h
cpufreq: Fix policy getting stuck when 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>
Signed-off-by: Ajay Dudani <adudani@codeaurora.org>
(cherry picked from commit 9decaa70a478ef26bfca840febe6296493a249d9)
msm: camera: Exit gracefully while camera daemon crashes

Add camera daemon shutdown handling in all camera
sub devices to exit camera gracefully and it helps
to restart camera.

Change-Id: I39643a16f100b873275efe3a0c6184fe54e52830
Signed-off-by: Suresh Vankadara <svankada@codeaurora.org>
Signed-off-by: Shuzhen Wang <shuzhenw@codeaurora.org>
msm: camera_v2: Don't touch CCI if camera daemon crashed.

If daemon crashes, refrain from writing to the CCI. This is needed
because these writes will not wait in a process crash scenario and can
potentially leave the CCI in a bad state.

Change-Id: I785cb4af8dc3893b8a7f11e1d1c2a2e1ad775665
Signed-off-by: Satyavaraprasad Yerramsetti <satyav@codeaurora.org>
Signed-off-by: Shuzhen Wang <shuzhenw@codeaurora.org>
msm: camera2: cpp: Set exact size for firmware loading.

The poll reads after during and after firmware loading fails.
This is because the exact size of firmware changes with the
version of the firmware. This change uses the firmware size
based on actual firmware file being loaded.

Bug: 10577806
Change-Id: I949954347a48d0b388b11b3c81fd5d1a4627cbf7
Signed-off-by: Rajakumar Govindaram <rajakuma@codeaurora.org>
Signed-off-by: Shuzhen Wang <shuzhenw@codeaurora.org>
(cherry picked from commit 48219c02786bae8216833022fceee3079f5c2755)
msm: camera: return -EIO if daemon hasn't fully launched

Media server depends on camera daemon to be fully launched
to be able to get camera info. Return -EIO if daemon hasn't
subscribed to v4l2 device node. This gives HAL opportunity
to try again.

Bug: 10577806
Signed-off-by: Shuzhen Wang <shuzhenw@codeaurora.org>
(cherry picked from commit d562b2f9774d9251068dbded5ad15a1c7407824f)

Change-Id: Iebc51c8e56352e02ef5f0554c9eb5ac2bf629595
msm: camera: Do not ignore ERESTARTSYS return from wait function

By ignoring ERESTARTSYS return from wait function, the thread
could potentially hold up the freezing of the task for a long
time, causing battery drain.

Bug: 10577806
Signed-off-by: Shuzhen Wang <shuzhenw@codeaurora.org>
Change-Id: I653c06c6bf41b07c811d6bab33e3c839460f45b6
(cherry picked from commit db69933cd572bb7f6fc6ede66175dc4adfdd8217)
msm: camera_v2: Handle vfe camif irq before axi irq

For each irq status, axi bits (image/stats) could be set as well
as camif sof bit. In this case, axi bits should be handled first
to better reflect the order of events: buf done of frame N before
SOF of frame N+1.

Bug: 11614033
Signed-off-by: Shuzhen Wang <shuzhenw@codeaurora.org>

Conflicts:
	drivers/media/platform/msm/camera_v2/isp/msm_isp_util.c
lge_touch_core: Don't announce support for ALL the tools

This confuses the heck out of some apps, and it's simply not true

Change-Id: I68742a8213ca541c017fbdf839194cd34eaea2d6
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

Cc: stable@vger.kernel.org
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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>