diag: Reduce error message frequency

Some diag error messages are printed with high frequency. This
cause flooding of kernel logs. Rate limiting these messages will
help reading kernel logs.

Change-Id: I477ff2394116603a27d65948a60d3460c32572d1
CRs-fixed: 594186
Signed-off-by: Katish Paran <kparan@codeaurora.org>
USB force fast charging

-Use base from Chad Froebel <chadfroebel@gmail.com> so we continue to
use the same generic sysfs mechanism

-Referenced franco's git for drivers/usb/otg/msm_otg.c changes
https://github.com/franciscofranco/mako/commit/5a8a4c8e23c7e1df39c740b9ce1d5dda20b0ede3

Off by default

Turn on:
echo 1 > /sys/kernel/fast_charge/force_fast_charge

Turn off:
echo 0 > /sys/kernel/fast_charge/force_fast_charge

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

Conflicts:
	arch/arm/mach-msm/Kconfig
configs: USB Fast Charge
block: row: add magic values.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
return_address.c: Fix warning - TODO: return_address should use unwind tables
core.c: Disable Software CRC check
audit: disable log spam messages
ALSA: usb-audio: Fix the mixer control range limiting issue

- mixer_ctl_set() function is limiting the volume level
  to particular range. This results in incorrect initial
  volume setting for that device.
- In USB mixer while calculating the dBmin/dBmax values
  resolution factor is hardcoded to 256 which results in
  populating the wrong values for dBmin/dBmax.
- Fix is to use appropriate resolution factor while
  calculating the dBmin/dBmax values.

CRs-Fixed: 515012
Prev-Change-Id: I502355af66f850bb65380c27333c3341fa43a947
Signed-off-by: Deepa Madiregama <dmadireg@codeaurora.org>

Change-Id: I79c14014ad6828a802f6978b796d8a4a91c87e46
ASoC: msm: qdsp6: Fix pop noise seen with touch tone during playback

Issue: When a session is opened for playback of the touch tone and
	routed through the COPP, the PBE and IIR params are being
	reconfigured in the COPP every time a session is open.

Rootcause:Configuring the PBE/IIR in the COPP every time a session
           is open.
Fix: Configuring the PBE and IIR param in the COPP one time a session
      is open

CRs-Fixed: 541722
Prev-Change-Id: If0d1a8c6893a94186e1c6c2a75432d2f4a89f842
Signed-off-by: Satish Kamuju <skamuj@codeaurora.org>

Change-Id: If51d472b554e358f2eada257b7cebb97682683b0
ALSA: pcm: check for integer overflow during multiplication

Channel info data structure is parsed from userspace and if
user does not set the no. of channels correctly, it could lead
to security vulnerability if we don't check for overflow when the
no. of channels is multiplied with pcm bit width. Add a condition
to check for overflow during multiplication.

CRs-fixed: 537818
Prev-Change-Id: Ia3c31406dd8b7627ea704c076643c0348582da28
Signed-off-by: Phani Kumar Uppalapati <phaniu@codeaurora.org>

Change-Id: I577e28017baae43f0ca49141916381c7e791a281
ASoC: msm: qdsp6v2: Copy frame data based on frame length

Copying data based on count will result in copying
uninitialized data to userspace which can potentially
disclose sensitive data. Fix by copying data based on
frame instead.

CRs-Fixed: 552528, 552531
Prev-Change-Id: I307b285ef2aefe00b953cf650582e9ff7e03ceb1
Signed-off-by: Shiv Maliyappanahalli <smaliyap@codeaurora.org>

Conflicts:

	sound/soc/msm/qdsp6v2/msm-pcm-voip-v2.c

Change-Id: Ie468d0ccdbd6e253af9bbc7731559856fa302e6e
ALSA: core: Fix crash by avoiding appl_ptr crossing 32-bit boundary

Incase of A2DP usecase using proxy driver, appl_ptr has
boundary value as 0x60000000 frames in sw_params for stereo(2 channels).
When this value crosses 0x40000000, then userspace calculating
appl_ptr at bytes results in crossing 32-bit value 0x100000000,
and points to 0x0 offset which can result in crash or pop.
To avoid above scenario, set the sw_params appl_ptr boundary value
within 0x40000000. Added proper check at sw_params update
to set this value correctly within 32-bit boundary(frames).

Prev-Change-Id: I537a04156699d90549a0a468ae19539ecd552d3b
CRs-Fixed: 483203
Signed-off-by: Laxminath Kasam <lkasam@codeaurora.org>

Change-Id: Ife1e9debfce7cc62c88ca9587006f0e4e44a7a64
ASoC: msm: qdsp6v2: Fix buffer overflow in voice driver

Userspace registers calibration data with acdb driver
through ioctls. Voice driver registers the calibration
data with CVD by querying acdb data from acdb driver and
copies the calibration data in apr message.

The size of the calibration data can be controlled by userspace
and can result in buffer overflow if the calibration size is
greater than the destination buffer size.
Reject acdb data if the size is greater than the size of
destination buffer.

Prev-Change-Id: I1b495390d67907afc608ed8233bf916777d38e11
CRs-fixed: 548872
Signed-off-by: Shiv Maliyappanahalli <smaliyap@codeaurora.org>

Conflicts:

	sound/soc/msm/qdsp6v2/q6voice.c

Change-Id: Ic50d948134a72ab416be1a46ba59e33beb04827d
mm: vmscan: when kswapd is awoken due to reclaim by a running task

Set the priority of kswapd to that of the calling task thus making memory reclaim cpu activity affected by nice level.

http://ck.kolivas.org/patches/3.0/3.9/3.9-ck1/patches/mm-kswapd_inherit_prio-1.patch
mm: forbid lumpy-reclaim in shrink_active_list()

Reset the reclaim mode in shrink_active_list() to RECLAIM_MODE_SINGLE |
RECLAIM_MODE_ASYNC.  (sync/async sign is used only in shrink_page_list
and does not affect shrink_active_list)

Currenly shrink_active_list() sometimes works in lumpy-reclaim mode, if
RECLAIM_MODE_LUMPYRECLAIM is left over from an earlier
shrink_inactive_list().  Meanwhile, in age_active_anon()
sc->reclaim_mode is totally zero.  So the current behavior is too
complex and confusing, and this looks like bug.

In general, shrink_active_list() populates the inactive list for the
next shrink_inactive_list().  Lumpy shring_inactive_list() isolates
pages around the chosen one from both the active and inactive lists.
So, there is no reason for lumpy isolation in shrink_active_list().

See also: https://lkml.org/lkml/2012/3/15/583

Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Proposed-by: Hugh Dickins <hughd@google.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Revert "mm: forbid lumpy-reclaim in shrink_active_list()"

This reverts commit 7939f09fe58eb5500decba4c11237757547e9284.
Always set noatime no diratime on all partitions! I/O Boost!

Also mod read_ahead to 512. as seems that is faster! in test apps.
Always set noatime no diratime on all partitions! I/O Boost! V2
writeback: fix race that cause writeback hung

There is a race between mark inode dirty and writeback thread, see the
following scenario.  In this case, writeback thread will not run though
there is dirty_io.

__mark_inode_dirty()                                          bdi_writeback_workfn()
	...                                                       	...
	spin_lock(&inode->i_lock);
	...
	if (bdi_cap_writeback_dirty(bdi)) {
	    <<< assume wb has dirty_io, so wakeup_bdi is false.
	    <<< the following inode_dirty also have wakeup_bdi false.
	    if (!wb_has_dirty_io(&bdi->wb))
		    wakeup_bdi = true;
	}
	spin_unlock(&inode->i_lock);
	                                                            <<< assume last dirty_io is removed here.
	                                                            pages_written = wb_do_writeback(wb);
	                                                            ...
	                                                            <<< work_list empty and wb has no dirty_io,
	                                                            <<< delayed_work will not be queued.
	                                                            if (!list_empty(&bdi->work_list) ||
	                                                                (wb_has_dirty_io(wb) && dirty_writeback_interval))
	                                                                queue_delayed_work(bdi_wq, &wb->dwork,
	                                                                    msecs_to_jiffies(dirty_writeback_interval * 10));
	spin_lock(&bdi->wb.list_lock);
	inode->dirtied_when = jiffies;
	<<< new dirty_io is added.
	list_move(&inode->i_wb_list, &bdi->wb.b_dirty);
	spin_unlock(&bdi->wb.list_lock);

	<<< though there is dirty_io, but wakeup_bdi is false,
	<<< so writeback thread will not be waked up and
	<<< the new dirty_io will not be flushed.
	if (wakeup_bdi)
	    bdi_wakeup_thread_delayed(bdi);

Writeback will run until there is a new flush work queued.  This may cause
a lot of dirty pages stay in memory for a long time.

Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
SELinux: Reduce overhead of mls_level_isvalid() function call

Date	Mon, 10 Jun 2013 13:55:08 -0400

v4->v5:
  - Fix scripts/checkpatch.pl warning.

v3->v4:
  - Merge the 2 separate while loops in ebitmap_contains() into
    a single one.

v2->v3:
  - Remove unused local variables i, node from mls_level_isvalid().

v1->v2:
 - Move the new ebitmap comparison logic from mls_level_isvalid()
   into the ebitmap_contains() helper function.
 - Rerun perf and performance tests on the latest v3.10-rc4 kernel.

While running the high_systime workload of the AIM7 benchmark on
a 2-socket 12-core Westmere x86-64 machine running 3.10-rc4 kernel
(with HT on), it was found that a pretty sizable amount of time was
spent in the SELinux code. Below was the perf trace of the "perf
record -a -s" of a test run at 1500 users:

  5.04%            ls  [kernel.kallsyms]     [k] ebitmap_get_bit
  1.96%            ls  [kernel.kallsyms]     [k] mls_level_isvalid
  1.95%            ls  [kernel.kallsyms]     [k] find_next_bit

The ebitmap_get_bit() was the hottest function in the perf-report
output.  Both the ebitmap_get_bit() and find_next_bit() functions
were, in fact, called by mls_level_isvalid(). As a result, the
mls_level_isvalid() call consumed 8.95% of the total CPU time of
all the 24 virtual CPUs which is quite a lot. The majority of the
mls_level_isvalid() function invocations come from the socket creation
system call.

Looking at the mls_level_isvalid() function, it is checking to see
if all the bits set in one of the ebitmap structure are also set in
another one as well as the highest set bit is no bigger than the one
specified by the given policydb data structure. It is doing it in
a bit-by-bit manner. So if the ebitmap structure has many bits set,
the iteration loop will be done many times.

The current code can be rewritten to use a similar algorithm as the
ebitmap_contains() function with an additional check for the
highest set bit. The ebitmap_contains() function was extended to
cover an optional additional check for the highest set bit, and the
mls_level_isvalid() function was modified to call ebitmap_contains().

With that change, the perf trace showed that the used CPU time drop
down to just 0.08% (ebitmap_contains + mls_level_isvalid) of the
total which is about 100X less than before.

  0.07%            ls  [kernel.kallsyms]     [k] ebitmap_contains
  0.05%            ls  [kernel.kallsyms]     [k] ebitmap_get_bit
  0.01%            ls  [kernel.kallsyms]     [k] mls_level_isvalid
  0.01%            ls  [kernel.kallsyms]     [k] find_next_bit

The remaining ebitmap_get_bit() and find_next_bit() functions calls
are made by other kernel routines as the new mls_level_isvalid()
function will not call them anymore.

This patch also improves the high_systime AIM7 benchmark result,
though the improvement is not as impressive as is suggested by the
reduction in CPU time spent in the ebitmap functions. The table below
shows the performance change on the 2-socket x86-64 system (with HT
on) mentioned above.

+--------------+---------------+----------------+-----------------+
|   Workload   | mean % change | mean % change  | mean % change   |
|              | 10-100 users  | 200-1000 users | 1100-2000 users |
+--------------+---------------+----------------+-----------------+
| high_systime |     +0.1%     |     +0.9%      |     +2.6%       |
+--------------+---------------+----------------+-----------------+
Signed-off-by: Waiman Long <Waiman.Long@hp.com>
Signed-off-by: Paul Reioux <reioux@gmail.com>