workqueue: Added null check and warning

If work item is already in queue get_work_cwq() will return null.
so null check is added to avoid crash in delayed_work_timer_on()

CRs-Fixed: 586162

Change-Id: I5c885142fd72781cea90d6c9b3456ecc7f0778b6
Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
cfg80211: discard regulatory hints from country IEs with undefined wiphy

Regulatory hints are processed in a worker thread and by the
time this thread gets a chance to schedule driver can deregister
the wiphy on which the country IE was discovered. There is no need
to process the hints which are coming from such invalid wiphy
devices and we should drop them.

Change-Id: I44f6f7b29ed1d0927151a88f3ea9e0c17044bd7e
CRs-Fixed: 588103
Signed-off-by: Mihir Shete <smihir@codeaurora.org>
msm: msm_fb: Update panel info in case of resolution change.
In case of resolution change, panel_info and mfd are updated with latest resolution.

Change-Id: I4958b8adc1650ec01c331b1a1ab695c5fd5add9b
Signed-off-by: raghavendra ambadas <rambad@codeaurora.org>
Revert "mm: make is_vmalloc_addr work properly."

This reverts commit d560dd9a8fd200d119be3bb9d99f22b0f06eddb4

Change-Id: I610975d802b11c6c382c2c29f8e2394ce8acce2d
Signed-off-by: Shruthi Krishna <skrish@codeaurora.org>
mm: make is_vmalloc_addr lockless

is_vmalloc_addr currently takes the vmap_area_lock and walks
the list of vmalloc areas to determine if an address is actually
a vmalloc address. Unfortunately, the current locking structure
with vmap_area_lock does not disable irqs which means that it may
be possible to recusively take the vmap_area_lock if an irq occurs
while walking the tree list. Considering the list of possible
vmalloc vs. not vmalloc ranges is not going to change after bootup,
skip the tree walking and just keep a bitmap of which virtual
addresses are set aside for vmalloc and which are not.

Change-Id: I0c159e09dc17b5c6641d08dcf630e6116b991cd5
CRs-Fixed: 591797
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
android: lowmemorykiller: add lmk parameters tunning code.

There are cases that LMK doesn't run, even when it must run.
It is due to LMK shrinker not considering memory status per zone.
So add LMK parameters(other_free, other_file) tunnig code to
consider target zone of LMK shrinker.

Change-Id: I6f1f8660d5da920a0e3af45a160499965032081d
Git-commit: 22d990a58fc17b3f0155e15eb2dc3efa037bea1c
Git-repo: https://android.googlesource.com/kernel/common/
[ohaugan@codeaurora.org: Fix compilation issues]
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
android/lowmemorykiller: Account for total_swapcache_pages

The lowmemorykiller relies on NR_FILE_PAGES when measureing
the amount of reclaimable memory in the system.
However when swap is enabled swap cache pages are counted
in NR_FILE_PAGES, and swap cache pages aren't as reclaimable
in low memory as file cache pages. Therefore a large swap
cache can result in the lowmemorykiller not running and
an OOM occuring.

In order to ensure the lowmemorykiller properly evaluates the
amount of reclaimable memory don't count the swap cache pages.

Change-Id: I38239283e572f814b277c718eaf6be7f92abacbb
Signed-off-by: Liam Mark <lmark@codeaurora.org>
Revert "Revert "msm: pm2: Setup memory for save/restore cpu registers early""

This reverts commit 49569af3e67d67eb2fa71fe462261b629efc1dae.
defconfig: Disable CONFIG_ENABLE_VMALLOC_SAVING

 * Only useful for devices with more than 1GB memory
defconfig: Disable KGSL shadow writes
Squashed update of kernel from 3.4.75 to 3.4.76
ARM: kconfig: select HAVE_EFFICIENT_UNALIGNED_ACCESS for CPUv6+ && MMU

Modern ARM CPUs can perform efficient unaligned memory accesses in
hardware and this feature is relied up on by code such as the dcache
word-at-a-time name hashing.

[pawitp: adapt to kernel 3.0]

Change-Id: I41559fc9255229e2601f4bef28aa8d48246156b7
Signed-off-by: Will Deacon <will.deacon@arm.com>
epoll: optimize EPOLL_CTL_DEL using rcu

Date	Tue, 1 Oct 2013 17:08:10 +0000 (GMT)

Optimize EPOLL_CTL_DEL such that it does not require the 'epmutex' by
converting the file->f_ep_links list into an rcu one. In this way, we can
traverse the epoll network on the add path in parallel with deletes. Since
deletes can't create loops or worse wakeup paths, this is safe.

This patch in combination with the patch "epoll: Do not take global 'epmutex'
for simple topologies", shows a dramatic performance improvement in
scalability for SPECjbb.

Tested-by: Nathan Zimmer <nzimmer@sgi.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>

backported for Linux 3.4 for use on Android
Signed-off-by: Paul Reioux <reioux@gmail.com>
epoll: Do not take global 'epmutex' for simple topologies

Date	Tue, 1 Oct 2013 17:08:14 +0000 (GMT)

When calling EPOLL_CTL_ADD for an epoll file descriptor that is attached
directly to a wakeup source, we do not need to take the global 'epmutex',
unless the epoll file descriptor is nested. The purpose of taking
the 'epmutex' on add is to prevent complex topologies such as loops and
deep wakeup paths from forming in parallel through multiple EPOLL_CTL_ADD
operations. However, for the simple case of an epoll file descriptor
attached directly to a wakeup source (with no nesting), we do not need
to hold the 'epmutex'.

This patch along with 'epoll: optimize EPOLL_CTL_DEL using rcu' improves
scalability on larger systems. Quoting Nathan Zimmer's mail on SPECjbb
performance:

"
On the 16 socket run the performance went from 35k jOPS to 125k jOPS.
In addition the benchmark when from scaling well on 10 sockets to scaling well
on just over 40 sockets.

...

Currently the benchmark stops scaling at around 40-44 sockets but it seems like
I found a second unrelated bottleneck.
"

Tested-by: Nathan Zimmer <nzimmer@sgi.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>

backported to Linux 3.4 for use on Android
Signed-off-by: Paul Reioux <reioux@gmail.com>
epoll: do not take globals epmutex for simple topologies fix

- use `bool' for boolean variables
- remove unneeded/undesirable cast of void*
- add missed ep_scan_ready_list() kerneldoc

Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Davide Libenzi <davidel@xmailserver.org>
Cc: Eric Wong <normalperson@yhbt.net>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Nathan Zimmer <nzimmer@sgi.com>
Cc: Nelson Elhage <nelhage@nelhage.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Signed-off-by: Paul Reioux <reioux@gmail.com>
sync: don't block the flusher thread waiting on IO

When sync does it's WB_SYNC_ALL writeback, it issues data Io and
then immediately waits for IO completion. This is done in the
context of the flusher thread, and hence completely ties up the
flusher thread for the backing device until all the dirty inodes
have been synced. On filesystems that are dirtying inodes constantly
and quickly, this means the flusher thread can be tied up for
minutes per sync call and hence badly affect system level write IO
performance as the page cache cannot be cleaned quickly.

We already have a wait loop for IO completion for sync(2), so cut
this out of the flusher thread and delegate it to wait_sb_inodes().
Hence we can do rapid IO submission, and then wait for it all to
complete.

Effect of sync on fsmark before the patch:

FSUse%        Count         Size    Files/sec     App Overhead
.....
     0       640000         4096      35154.6          1026984
     0       720000         4096      36740.3          1023844
     0       800000         4096      36184.6           916599
     0       880000         4096       1282.7          1054367
     0       960000         4096       3951.3           918773
     0      1040000         4096      40646.2           996448
     0      1120000         4096      43610.1           895647
     0      1200000         4096      40333.1           921048

And a single sync pass took:

  real    0m52.407s
  user    0m0.000s
  sys     0m0.090s

After the patch, there is no impact on fsmark results, and each
individual sync(2) operation run concurrently with the same fsmark
workload takes roughly 7s:

  real    0m6.930s
  user    0m0.000s
  sys     0m0.039s

IOWs, sync is 7-8x faster on a busy filesystem and does not have an
adverse impact on ongoing async data write operations.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
hwrng: add randomness to system from rng sources

an intelligent MSM thermal throttling kernel driver designed to replace
the
closed sourced thermald(aemon) from Qualcomm.

The current driver can throttle the SOC via core frequency scaling or
via
core hotplug with user configurable sysfs entries to adjust the
throttling
temperature thresholds for each.

Derived from Qualcomm's Open source repo.

Signed-off-by: Paul Reioux <reioux@gmail.com>

Conflicts:
	arch/arm/mach-msm/lge/board-8974-z-kr.c
	drivers/thermal/Kconfig
	drivers/thermal/Makefile
sched: change WARN_ON_ONCE to WARN_ON in try_to_wake_up_local()

The WARN_ON_ONCE() calls at the beginning of try_to_wake_up_local()
were recently converted from BUG_ON() calls. If these hit it indicates
something is wrong and that may contribute to other system instability.
To eliminate the risk of an instance of one of these errors going
un-noticed because there was an earlier instance that occured long ago,
change to WARN_ON(). If there ever is a flood of these there are bigger
problems.

Change-Id: I392832e2b6ec24b3569b001b1af9ecd4ed6828e7
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
watchdog: Fix warning caused by use of smp_processor_id()

watchdog driver creates per-cpu kernel threads that are bound to
separate cpus. Use of smp_processor_id() by such threads in
__touch_watchdog() is perfectly fine, as they are generally pinned to
the cpu on which they are running.

During cpu offline event, however, affinity for the watchdog thread
bound to dying cpu is broken before it is killed. There is a small
time window between affinity broken and thread dying in which thread
can run on a cpu with its affinity not set to that cpu exclusively.
This will trigger a warning from use of smp_processor_id(), which is
harmless in this case as it will provide the required heartbeat on cpu
where it is running and moreover that thread will be shortly killed.

Mute the harmless warning by use of raw_smp_processor_id() in
__touch_watchdog(). This seems less intrusive fix than killing threads
in CPU_DOWN_PREPARE event handler.

Change-Id: I7fa22ff529aeea0ec3d5610cfec87aea92cf95a0
CRs-Fixed: 517188
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
sched/rt: Remove redundant nr_cpus_allowed test

Date	Fri, 4 Oct 2013 14:24:53 -0500

From: Shawn Bohrer <sbohrer@rgmadvisors.com>

In 76854c7e8f3f4172fef091e78d88b3b751463ac6 "sched: Use
rt.nr_cpus_allowed to recover select_task_rq() cycles" an optimization
was added to select_task_rq_rt() that immediately returns when
p->nr_cpus_allowed == 1 at the beginning of the function.  This makes
the latter p->nr_cpus_allowed > 1 check redundant and can be removed.
Signed-off-by: Shawn Bohrer <sbohrer@rgmadvisors.com>

Signed-off-by: Paul Reioux <reioux@gmail.com>