msm: kgsl: Add the buffer user address to the debugfs memory list

For each buffer in the debugfs memory list print the address it is
mapped to in the user process.  This is useful for matching up the
user side allocations with what the kernel thinks it has.

Change-Id: Ic0dedbadd07a8f704c0bf73b183aaeeddbbdd129
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
msm: kgsl: use %pK to restrict printing GPU / memory addresses

Use %pK in the output for the per-process memory dump to keep from
printing the GPU and user memory addresses for the GPU memory
objects own by the process.  This allows us to make the 'mem' file
world readable without exposing any really dangerous information.

Change-Id: Ic0dedbad21654110905d1b3744f562966584d8ed
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Sunil Khatri <sunilkh@codeaurora.org>
sched: Reset rq->next_interval before going idle

next_balance, the point in jiffy time scale when a cpu will next load
balance, could have been calculated when the cpu was busy. A busy cpu
will apply its sched domain's busy_factor (usually > 1) in computing
next_balance for that sched domain, which causes the (busy) cpu to load
balance less frequently in its sched domains. However when the same cpu
is going idle, its next_balance needs to be reset without consideration
of busy_factor. Failure to do so would not trigger nohz idle balancer on
that cpu for unnecessarily long time (introducing additional scheduling
latencies for tasks). Fix bug in scheduler which aims to reset
next_balance before a cpu goes idle (as per existing comment) but is
clearly not doing so.

Change-Id: I7e027a51686528c4092d770c7d33c874d38f5df4
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
sched: re-calculate a cpu's next_balance point upon sched domain changes

Commit 55ddeb0f (sched: Reset rq->next_interval before going idle) reset
a cpu's rq->next_balance when pulled_task = 0, which will be true when
the cpu failed to pull any task, causing it go idle. However that patch
relied on next_balance being calculated as a result of traversing cpu's
sched domain hierarchy.

A cpu that is the only online cpu will however not be attached to any
sched domain hierarchy. When such a cpu calls into idle_balance(), we
will end up initializing next_balance to be 1sec away! Such a CPU will
defer load balance check for another 1sec, even though we may bring up
more cpus in the meantime requiring it to check for load imbalance more
frequently. This could then lead to increased scheduling latency for
some tasks.

This patch results in a cpu's next_balance being re-calculated when its
attaching to a new sched domain hierarchy.  This should let cpus call
load balance checks at the right time we expect them to!

Change-Id: I855cff8da5ca28d278596c3bb0163b839d4704bc
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
sched: Make sure to not re-read variables after validation

We could re-read rq->rt_avg after we validated it was smaller than
total, invalidating the check and resulting in an unintended negative.

Change-Id: I8543974aad539107768e9e513ca3a8c4cb79b2ff
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: David Rientjes <rientjes@google.com>
Link: http://lkml.kernel.org/r/1337688268.9698.29.camel@twins
Signed-off-by: Ingo Molnar <mingo@kernel.org>
CRs-Fixed: 497236
Git-commit: b654f7de41b0e3903ee2b51d3b8db77fe52ce728
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
ARM: 7486/1: sched_clock: update epoch_cyc on resume

Many clocks that are used to provide sched_clock will reset during
suspend.  If read_sched_clock returns 0 after suspend, sched_clock will
appear to jump forward.  This patch resets cd.epoch_cyc to the current
value of read_sched_clock during resume, which causes sched_clock() just
after suspend to return the same value as sched_clock() just before
suspend.

In addition, during the window where epoch_ns has been updated before
suspend, but epoch_cyc has not been updated after suspend, it is unknown
whether the clock has reset or not, and sched_clock() could return a
bogus value.  Add a suspended flag, and return the pre-suspend epoch_ns
value during this period.

The new behavior is triggered by calling setup_sched_clock_needs_suspend
instead of setup_sched_clock.

Change-Id: I7441ef74dc6802c00eea61f3b8c0a25ac00a724d
Signed-off-by: Colin Cross <ccross@android.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
CRs-Fixed: 497236
Git-commit: 237ec6f2e51d2fc2ff37c7c5f1ccc9264d09c85b
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
ARM: 7565/1: sched: stop sched_clock() during suspend

The scheduler imposes a requirement to sched_clock()
which is to stop the clock during suspend, if we don't
do that any RT thread will be rescheduled in the future
which might cause any sort of problems.

This became an issue on OMAP when we converted omap-i2c.c
to use threaded IRQs, it turned out that depending on how
much time we spent on suspend, the I2C IRQ thread would
end up being rescheduled so far in the future that I2C
transfers would timeout and, because omap_hsmmc depends
on an I2C-connected device to detect if an MMC card is
inserted in the slot, our rootfs would just vanish.

arch/arm/kernel/sched_clock.c already had an optional
implementation (sched_clock_needs_suspend()) which would
handle scheduler's requirement properly, what this patch
does is simply to make that implementation non-optional.

Note that this has the side-effect that printk timings
won't reflect the actual time spent on suspend so other
methods to measure that will have to be used.

This has been tested with beagleboard XM (OMAP3630) and
pandaboard rev A3 (OMAP4430). Suspend to RAM is now working
after this patch.

Thanks to Kevin Hilman for helping out with debugging.

Change-Id: Ie2f9e3b22eb3d1f3806cf8c598f22e2fa1b8651f
Acked-by: Kevin Hilman <khilman@ti.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
CRs-Fixed: 497236
Git-commit: 6a4dae5e138a32b45ca5218cc2b81802f9d378c3
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
ARM: 7643/1: sched: correct update_sched_clock()

If we want load epoch_cyc and epoch_ns atomically,
we should update epoch_cyc_copy first of all.
This notify reader that updating is in progress.

If we update epoch_cyc first like as current implementation,
there is subtle error case.
Look at the below example.

<Initial Condition>
cyc = 9
ns = 900
cyc_copy = 9

== CASE 1 ==
<CPU A = reader>           <CPU B = updater>
                           write cyc = 10
read cyc = 10
read ns = 900
                           write ns = 1000
                           write cyc_copy = 10
read cyc_copy = 10

output = (10, 900)

== CASE 2 ==
<CPU A = reader>           <CPU B = updater>
read cyc = 9
                           write cyc = 10
                           write ns = 1000
read ns = 1000
read cyc_copy = 9
                           write cyc_copy = 10
output = (9, 1000)

If atomic read is ensured, output should be (9, 900) or (10, 1000).
But, output in example case are not.

So, change updating sequence in order to correct this problem.

Change-Id: Ia9196dd50a519f516f70c3138233624b669ef96a
Cc: <stable@vger.kernel.org>
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
CRs-Fixed: 497236
Git-commit: 7c4e9ced424be4d36df6a3e3825763e97ee97607
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
sched: Set MC (multi-core) sched domain's busy_factor attribute to 1

busy_factor attribute of a scheduler domain causes busy CPUs (CPUs
that are not idle) to load balance less frequently in that domain,
which could impact performance by increasing scheduling latency for
tasks.

As an example, consider MC scheduler domain's attribute values of
max_interval = 4ms and busy_factor = 64. Further consider
max_load_balance_interval = 100 (HZ/10). In this case, a non-idle CPU
could put off load balance check in MC domain by 100ms. This
effectively means that a CPU running a single task in its queue could
fail to notice increased load on another CPU (that is in same MC
domain) for upto 100ms, before picking up load from the overloaded
CPU. Needless to say, this leads to increased scheduling latency for
tasks, affecting performance adversely.

By setting MC domain's busy_factor value to 1, we limit maximum
interval that busy CPU can put off load balance checks to 4ms
(effectively 10ms, given HZ value of 100).

Change-Id: Id45869d06f5556ea8eec602b65c2ffd2143fe060
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
msm: dma: Moving queue_work() function within spinlock

Currently we are adding a dma command to the staged list with in a
spinlock and then adding to workqueue using queue_work after unlocking
the spinlock. With this there is chance of executing DMA commands in out
of order in below concurrency case.

Tread1                                Thread2
__msm_dmov_enqueue_cmd_ext
   spin_lock_irqsave(..)
   list_add_tail(..)
   spin_unlock_irqrestore(..)
       --PREEMPT--
                                      __msm_dmov_enqueue_cmd_ext
                                         spin_lock_irqsave(..)
                                         list_add_tail(..)
                                         spin_unlock_irqrestore(..)
                                         queue_work()
                                         ..
   queue_work()
So adding queue_work with in spin_lock will make sure that the
work added in the work_queue is processed in the same order as they
are added in staged_commands.

CRs-Fixed: 423190,669409
Change-Id: I2ffd1327fb5f0cd1f06db7de9c026d1c4997fe4d
Acked-by: Gopi Krishna Nedanuri <gnedanur@qti.qualcomm.com>
Signed-off-by: Utsab Bose <ubose@codeaurora.org>
Signed-off-by: Vijay Kumar T M <vtmuni@codeaurora.org>
Merge "msm: kgsl: Add the buffer user address to the debugfs memory list"
Merge "msm: kgsl: use %pK to restrict printing GPU / memory addresses"
Merge "msm: dma: Moving queue_work() function within spinlock"
ksm: Provide support to use deferred timers for scanner thread

KSM thread to scan pages is getting schedule on definite timeout.
That wakes up CPU from idle state and hence may affect the power
consumption. Provide an optional support to use deferred timer
which suites low-power use-cases.

To enable deferred timers,
$ echo 1 > /sys/kernel/mm/ksm/deferred_timer

Change-Id: I07fe199f97fe1f72f9a9e1b0b757a3ac533719e8
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
USB: msm72k_udc: Synchronize ep dequeue to handle race

The rndis composition switch and handling a rndis command
or a standard request like setup can lead to a race
condition. While the command is getting completed,
ep dequeue may happen as a part of android_disable which
can lead to crash.

Have a busy state marked to the endpoint while
the completion on that request is running and let
ep dequeue wait untill command is completed.

CRs-Fixed: 523964
Change-Id: Ia3a1bbadccdf8abe24cc14ee64aad3d9eae1d3e5
Signed-off-by: Sujeet Kumar <ksujeet@codeaurora.org>
msm: rpc: add shutdown and restart handler for rpc

Add shutdown and restart handler for rpcrouter. The
shutdown handler will take care of calling the
msm_rpcrouter_close function with a pre defined
priority. PM no longer had to handle rpc in the shutdown/reboot
sequence.

Signed-off-by: Angshuman Sarkar <angshuman@codeaurora.org>
(cherry picked from commit 4e253c2c596ff611556736822a6df166132504e7)

Change-Id: I312c38ce222f10cc5589bb9de22d7a6bf47045d5
Signed-off-by: Gopal Goberu <ggober@codeaurora.org>
msm: rpc: add shutdown and restart handler for rpc

Add shutdown and restart handler for rpcrouter. The
shutdown handler take care of calling the
msm_rpcrouter_close function with a pre defined
priority. PM no longer handle rpc close in the shutdown/reboot
sequence.

CRs-fixed: 396641
Signed-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>
Signed-off-by: Angshuman Sarkar <angshuman@codeaurora.org>
(cherry picked from commit 0975c60881a90c0adf36bac4739b812e34acb813)

Conflicts:

	arch/arm/mach-msm/smd_rpcrouter.c

Change-Id: I3dd21a72eb624273b16f5a300b55b068a02d509b
Signed-off-by: Gopal Goberu <ggober@codeaurora.org>
selinux: Fix Kernel panic due to NULL pointer dereference

Below Kernel panic is observed due to race condition, where
sock_has_perm called in a thread and is trying to access sksec->sid
without checking sksec. Just before that, sk->sk_security was set
to NULL by selinux_sk_free_security through sk_free in other thread.

31704.949269:   <3> IPv4: Attempt to release alive inet socket dd81b200
31704.959049:   <1> Unable to handle kernel NULL pointer dereference at \
                        virtual address 00000000
31704.983562:   <1> pgd = c6b74000
31704.985248:   <1> [00000000] *pgd=00000000
31704.996591:   <0> Internal error: Oops: 5 [#1] PREEMPT SMP ARM
31705.001016:   <6> Modules linked in: adsprpc [last unloaded: wlan]
31705.006659:   <6> CPU: 1    Tainted: G           O  \
                        (3.4.0-g837ab9b-00003-g6bcd9c6 #1)
31705.014042:   <6> PC is at sock_has_perm+0x58/0xd4
31705.018292:   <6> LR is at sock_has_perm+0x58/0xd4
31705.022546:   <6> pc : [<c0341e8c>]    lr : [<c0341e8c>]    \
                                                  psr: 60000013
31705.022549:   <6> sp : dda27f00  ip : 00000000  fp : 5f36fc84
31705.034002:   <6> r10: 00004000  r9 : 0000009d  r8 : e8c2b700
31705.039211:   <6> r7 : dda27f24  r6 : dd81b200  r5 : 00000000  \
                                                  r4 : 00000000
31705.045721:   <6> r3 : 00000000  r2 : dda27ef8  r1 : 00000000  \
                                                  r0 : dda27f54
31705.052232:   <6> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM \
                        Segment user
31705.059349:   <6> Control: 10c5787d  Table: 10d7406a  DAC: 00000015
.
.
.
.
31705.697816:   <6> [<c0341e8c>] (sock_has_perm+0x58/0xd4) from \
                    [<c033ed10>] (security_socket_getsockopt+0x14/0x1c)
31705.707534:   <6> [<c033ed10>] (security_socket_getsockopt+0x14/0x1c) \
                           from [<c0745c18>] (sys_getsockopt+0x34/0xa8)
31705.717343:   <6> [<c0745c18>] (sys_getsockopt+0x34/0xa8) from \
                    [<c0106140>] (ret_fast_syscall+0x0/0x30)
31705.726193:   <0> Code: e59832e8 e5933058 e5939004 ebfac736 (e5953000)
31705.732635:   <4> ---[ end trace 22889004dafd87bd ]---

Change-Id: I79c3fb525f35ea2494d53788788cd71a38a32d6b
Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
Signed-off-by: Osvaldo Banuelos <osvaldob@codeaurora.org>
ipv4: Dump stack on attempt to release alive inet socket

In commit 82e1cecf1 we hide a bug, that will make SELinux
bomb out. Let's dump the stack when it happens to have at
least a chance to find the cause.

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

Change-Id: Iab1d8871f1dffa499e10ba9d845ac204d0fee32a