net: rmnet_usb: Duplicate skb when there is no tailroom

If the skb to be transmitted has no trailroom for mux padding,
then copy the skb into a new expanded skb with tailroom.

CRs-Fixed: 545483
Change-Id: I6d41c7b80246aac928e8466091cc3e925ecf550c
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
msm: audio: qdsp6v2: Change acdb_mmap size variable to unsigned

The acdb_mmap fuction does a size calculation but
stores the result in an int which makes negitive
numbers possible. Changing the variable to unsigned
ensures that the size used is never out of bounds.

Change-Id: I78714044594310a4411db1f50456e1294cf6ffce
CRs-fixed: 548145
Signed-off-by: Ben Romberger <bromberg@codeaurora.org>
ARM: 7810/1: perf: Fix array out of bounds access in armpmu_map_hw_event()

Vince Weaver reports an oops in the ARM perf event code while
running his perf_fuzzer tool on a pandaboard running v3.11-rc4.

Unable to handle kernel paging request at virtual address 73fd14cc
pgd = eca6c000
[73fd14cc] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in: snd_soc_omap_hdmi omapdss snd_soc_omap_abe_twl6040 snd_soc_twl6040 snd_soc_omap snd_soc_omap_hdmi_card snd_soc_omap_mcpdm snd_soc_omap_mcbsp snd_soc_core snd_compress regmap_spi snd_pcm snd_page_alloc snd_timer snd soundcore
CPU: 1 PID: 2790 Comm: perf_fuzzer Not tainted 3.11.0-rc4 #6
task: eddcab80 ti: ed892000 task.ti: ed892000
PC is at armpmu_map_event+0x20/0x88
LR is at armpmu_event_init+0x38/0x280
pc : [<c001c3e4>]    lr : [<c001c17c>]    psr: 60000013
sp : ed893e40  ip : ecececec  fp : edfaec00
r10: 00000000  r9 : 00000000  r8 : ed8c3ac0
r7 : ed8c3b5c  r6 : edfaec00  r5 : 00000000  r4 : 00000000
r3 : 000000ff  r2 : c0496144  r1 : c049611c  r0 : edfaec00
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: aca6c04a  DAC: 00000015
Process perf_fuzzer (pid: 2790, stack limit = 0xed892240)
Stack: (0xed893e40 to 0xed894000)
3e40: 00000800 c001c17c 00000002 c008a748 00000001 00000000 00000000 c00bf078
3e60: 00000000 edfaee50 00000000 00000000 00000000 edfaec00 ed8c3ac0 edfaec00
3e80: 00000000 c073ffac ed893f20 c00bf180 00000001 00000000 c00bf078 ed893f20
3ea0: 00000000 ed8c3ac0 00000000 00000000 00000000 c0cb0818 eddcab80 c00bf440
3ec0: ed893f20 00000000 eddcab80 eca76800 00000000 eca76800 00000000 00000000
3ee0: 00000000 ec984c80 eddcab80 c00bfe68 00000000 00000000 00000000 00000080
3f00: 00000000 ed892000 00000000 ed892030 00000004 ecc7e3c8 ecc7e3c8 00000000
3f20: 00000000 00000048 ecececec 00000000 00000000 00000000 00000000 00000000
3f40: 00000000 00000000 00297810 00000000 00000000 00000000 00000000 00000000
3f60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3f80: 00000002 00000002 000103a4 00000002 0000016c c00128e8 ed892000 00000000
3fa0: 00090998 c0012700 00000002 000103a4 00090ab8 00000000 00000000 0000000f
3fc0: 00000002 000103a4 00000002 0000016c 00090ab0 00090ab8 000107a0 00090998
3fe0: bed92be0 bed92bd0 0000b785 b6e8f6d0 40000010 00090ab8 00000000 00000000
[<c001c3e4>] (armpmu_map_event+0x20/0x88) from [<c001c17c>] (armpmu_event_init+0x38/0x280)
[<c001c17c>] (armpmu_event_init+0x38/0x280) from [<c00bf180>] (perf_init_event+0x108/0x180)
[<c00bf180>] (perf_init_event+0x108/0x180) from [<c00bf440>] (perf_event_alloc+0x248/0x40c)
[<c00bf440>] (perf_event_alloc+0x248/0x40c) from [<c00bfe68>] (SyS_perf_event_open+0x4f4/0x8fc)
[<c00bfe68>] (SyS_perf_event_open+0x4f4/0x8fc) from [<c0012700>] (ret_fast_syscall+0x0/0x48)
Code: 0a000005 e3540004 0a000016 e3540000 (0791010c)

This is because event->attr.config in armpmu_event_init()
contains a very large number copied directly from userspace and
is never checked against the size of the array indexed in
armpmu_map_hw_event(). Fix the problem by checking the value of
config before indexing the array and rejecting invalid config
values.

Change-Id: I77c21164fc0f57f8a44dd0bcc7d00b51998669f6
Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Tested-by: Vince Weaver <vincent.weaver@maine.edu>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Git-commit: d9f966357b14e356dbd83b8f4a197a287ab4ff83
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
CRs-fixed: 561044
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
msm: kgsl: Ignore kgsl flags while submitting cmds

Allow KGSL_CMD_FLAGS_EOF(end of frame) marker flag to
pass while adding userspace commands to ringbuffer.

CRs-fixed: 564030

Change-Id: I730143d2d1a0f3231705371f2119c55e277849e2
Signed-off-by: Anshuman Dani <adani@codeaurora.org>
msm: kgsl: Do not execute shader on wakeup from power collapse for 8064

Reverting "execute shader on wakeup from power collapse"
workaround for 8064.
This is causing GPU hang with all graphics test cases.

CRs-fixed: 564030

Change-Id: I7cc0eaad070fa929951be7247f95f24c1c7d849a
Signed-off-by: Anshuman Dani <adani@codeaurora.org>
msm: Remove files no longer buildable under arch/arm/mach-msm

Removed the files to reduce efforts as we move driver code out of mach-msm

Change-Id: Ic926ede69a7f4bb6ed0fbdffa7d551892886936a
Signed-off-by: Mohammad Johny Shaik <mjshai@codeaurora.org>
msm:pm: Fix for race condition of starting cpu1 when cpu0 in PC.

There is a window where core sends ipi to secondary core and
wait for it to come online for 1 second. This would allow
core0 to go power collapse in a rare condition where core1
started booting and doesn't become online yet.

Fix this by not allowing power collapse on core0
if hot plug operation is in progress.

CRs-fixed: 545714.
Change-Id: I1ca503a2f09cd9a65c2fdcd41eb54466a1e486c5
Signed-off-by: Anil kumar mamidala <amami@codeaurora.org>
KBuild: Export msm_rmnet.h to user space

Exposing msm_rmnet.h to user space using standard mechanism such that
user space applications do not have to use relative paths in include
list.

CRs-Fixed: 548664
Change-Id: I807f9854de1d0bf9961607c9ed54dd5ecef782dc
Signed-off-by: Harout Hedeshian <harouth@codeaurora.org>
kernel: Prevent unnecessary rfkill event generation.

Prevent unnecessary rfkill event generation when the state has
not actually changed. These events have to be delivered to
relevant userspace processes, causing these processes to wake
up and do something while they could as well have slept. This
obviously results in more CPU usage, longer time-to-sleep-again
and therefore higher power consumption.

Change-Id: I3ac4e141fbdf1315b74d3bad6aa96f34b00c3f92
CRs-fixed: 398283
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Signed-off-by: Mykyta Iziumtsev <nikita.izyumtsev@gmail.com>
Signed-off-by: Deepthi Gowri <deepthi@codeaurora.org>
Patch-mainline: v3.7
Git-commit: eab48345c2b2d791159aaac4a77000baa8dbc1ae
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Bluetooth: Remove wake_locks added for BT idle timer

Wakelocks were used to address the issue related to timer
which was not triggered when device was put into suspend
mode.This does not impact the usecases as the link would
be put into sniff mode immediately after the device comes
out of suspend mode.

Change-Id: I648acf32c6ce9bd0d3415ac0e9dcd2250d3fb68d
Signed-off-by: Sumit Bajpai <sbajpai@codeaurora.org>
Bluetooth : Recover BT, if hardware error event is received from the SOC

If Hardware Error event is received from the SOC, then BT SOC is in bad
state. As per spec, Hardware Error event is handled in HCI. Upper layer
gets informed by HCI to reset everything. & recover BT state machine & BT
SOC.

Change-Id: Iefdf8511ad51f88ff8a24ab9e075eb8dbc0a0a67
Signed-off-by: Nitin Shivpure <nshivpur@codeaurora.org>
mmc: block: fix a bug of error handling in MMC driver

Current MMC driver doesn't handle generic error (bit19 of device
status) in write sequence. As a result, write data gets lost when
generic error occurs. For example, a generic error when updating a
filesystem management information causes a loss of write data and
corrupts the filesystem. In the worst case, the system will never
boot.

This patch includes the following functionality:
  1. To enable error checking for the response of CMD12 and CMD13
     in write command sequence
  2. To retry write sequence when a generic error occurs

Messages are added for v2 to show what occurs.

cherry-picked it from
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/mmc?id=c8760069627ad3b0dbbea170f0c4c58b16e18d3d

Change-Id: I2bc5224a83b931a11e4664c449050323c34cdec5
Signed-off-by: KOBAYASHI Yoshitake <yoshitake.kobayashi@toshiba.co.jp>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Devin Kim <dojip.kim@lge.com>
mm: fix pageblock bitmap allocation

commit 7c45512df987c5619db041b5c9b80d281e26d3db upstream.

Commit c060f943d092 ("mm: use aligned zone start for pfn_to_bitidx
calculation") fixed out calculation of the index into the pageblock
bitmap when a !SPARSEMEM zome was not aligned to pageblock_nr_pages.

However, the _allocation_ of that bitmap had never taken this alignment
requirement into accout, so depending on the exact size and alignment of
the zone, the use of that index could then access past the allocation,
resulting in some very subtle memory corruption.

This was reported (and bisected) by Ingo Molnar: one of his random
config builds would hang with certain very specific kernel command line
options.

In the meantime, commit c060f943d092 has been marked for stable, so this
fix needs to be back-ported to the stable kernels that backported the
commit to use the right alignment.

Bisected-and-tested-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Change-Id: Ibb30176a14ca39c94ca13202f8272272e441f1d3
add extra free kbytes tunable

Add a userspace visible knob to tell the VM to keep an extra amount
of memory free, by increasing the gap between each zone's min and
low watermarks.

This is useful for realtime applications that call system
calls and have a bound on the number of allocations that happen
in any short time period.  In this application, extra_free_kbytes
would be left at an amount equal to or larger than than the
maximum number of allocations that happen in any burst.

It may also be useful to reduce the memory use of virtual
machines (temporarily?), in a way that does not cause memory
fragmentation like ballooning does.

[ccross]
Revived for use on old kernels where no other solution exists.
The tunable will be removed on kernels that do better at avoiding
direct reclaim.

Change-Id: I765a42be8e964bfd3e2886d1ca85a29d60c3bb3e
Signed-off-by: Rik van Riel<riel@redhat.com>
Signed-off-by: Colin Cross <ccross@android.com>
memcg: add memory.pressure_level events

With this patch userland applications that want to maintain the
interactivity/memory allocation cost can use the pressure level
notifications.  The levels are defined like this:

The "low" level means that the system is reclaiming memory for new
allocations.  Monitoring this reclaiming activity might be useful for
maintaining cache level.  Upon notification, the program (typically
"Activity Manager") might analyze vmstat and act in advance (i.e.
prematurely shutdown unimportant services).

The "medium" level means that the system is experiencing medium memory
pressure, the system might be making swap, paging out active file
caches, etc.  Upon this event applications may decide to further analyze
vmstat/zoneinfo/memcg or internal memory usage statistics and free any
resources that can be easily reconstructed or re-read from a disk.

The "critical" level means that the system is actively thrashing, it is
about to out of memory (OOM) or even the in-kernel OOM killer is on its
way to trigger.  Applications should do whatever they can to help the
system.  It might be too late to consult with vmstat or any other
statistics, so it's advisable to take an immediate action.

The events are propagated upward until the event is handled, i.e.  the
events are not pass-through.  Here is what this means: for example you
have three cgroups: A->B->C.  Now you set up an event listener on
cgroups A, B and C, and suppose group C experiences some pressure.  In
this situation, only group C will receive the notification, i.e.  groups
A and B will not receive it.  This is done to avoid excessive
"broadcasting" of messages, which disturbs the system and which is
especially bad if we are low on memory or thrashing.  So, organize the
cgroups wisely, or propagate the events manually (or, ask us to
implement the pass-through events, explaining why would you need them.)

Performance wise, the memory pressure notifications feature itself is
lightweight and does not require much of bookkeeping, in contrast to the
rest of memcg features.  Unfortunately, as of current memcg
implementation, pages accounting is an inseparable part and cannot be
turned off.  The good news is that there are some efforts[1] to improve
the situation; plus, implementing the same, fully API-compatible[2]
interface for CONFIG_CGROUP_MEM_RES_CTLR=n case (e.g.  embedded) is also
a viable option, so it will not require any changes on the userland
side.

[1] http://permalink.gmane.org/gmane.linux.kernel.cgroups/6291
[2] http://lkml.org/lkml/2013/2/21/454

Change-Id: Ib7b9f7986008d423b84152e2781d0402a560c95e
[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: fix CONFIG_CGROPUPS=n warnings]
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: Kirill A. Shutemov <kirill@shutemov.name>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Glauber Costa <glommer@parallels.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Luiz Capitulino <lcapitulino@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: Leonid Moiseichuk <leonid.moiseichuk@nokia.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: John Stultz <john.stultz@linaro.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mm: add a field to store names for private anonymous memory

Userspace processes often have multiple allocators that each do
anonymous mmaps to get memory.  When examining memory usage of
individual processes or systems as a whole, it is useful to be
able to break down the various heaps that were allocated by
each layer and examine their size, RSS, and physical memory
usage.

This patch adds a user pointer to the shared union in
vm_area_struct that points to a null terminated string inside
the user process containing a name for the vma.  vmas that
point to the same address will be merged, but vmas that
point to equivalent strings at different addresses will
not be merged.

Userspace can set the name for a region of memory by calling
prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, start, len, (unsigned long)name);
Setting the name to NULL clears it.

The names of named anonymous vmas are shown in /proc/pid/maps
as [anon:<name>] and in /proc/pid/smaps in a new "Name" field
that is only present for named vmas.  If the userspace pointer
is no longer valid all or part of the name will be replaced
with "<fault>".

The idea to store a userspace pointer to reduce the complexity
within mm (at the expense of the complexity of reading
/proc/pid/mem) came from Dave Hansen.  This results in no
runtime overhead in the mm subsystem other than comparing
the anon_name pointers when considering vma merging.  The pointer
is stored in a union with fieds that are only used on file-backed
mappings, so it does not increase memory usage.

Change-Id: Ie2ffc0967d4ffe7ee4c70781313c7b00cf7e3092
Signed-off-by: Colin Cross <ccross@android.com>
slub: tid must be retrieved from the percpu area of the current processor

As Steven Rostedt has pointer out: rescheduling could occur on a
different processor after the determination of the per cpu pointer and
before the tid is retrieved. This could result in allocation from the
wrong node in slab_alloc().

The effect is much more severe in slab_free() where we could free to the
freelist of the wrong page.

The window for something like that occurring is pretty small but it is
possible.

Signed-off-by: Christoph Lameter <cl@linux.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
msm: acpuclock: Fix acpuclk_data null pointer dereference

If acpuclk_data is null, dereferencing it in acpuclk_get_switch_time
causes a kernel panic.  Add pointer check to fix that.

Change-Id: I69b92671c8cf26cb45ec8f1193c147be2ebe4c16
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
msm: krait-regulator: correct krait rail settling delay calculation

set_pmic_gang_voltage() updates pmic_vmax_uV to be equal to vmax
prior returning.  Because of this, the settling delay calculation
will always yield 0us. Fix this.

from caf
commit  46d0b10ef7b72fc5756eb290139a6e6595ab2081

Change-Id: I670a0bdecfe72e9ddf663e9a35ef8a6354946224
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
Signed-off-by: Devin Kim <dojip.kim@lge.com>
msm: krait-regulator: Update SLEW_RATE constant

The Krait regulators are clocked from an RC oscillator circuit
that could vary in frequency by as much as 25% in extreme
conditions, causing the voltage ramp to be either faster or slower
than the nominal rate. To ensure we wait long enough for the rail
to settle in all conditions, lower SLEW_RATE by 25%.

from caf
commit  92abbdd637cee6f8b2f3ef438f5d727290680f2d

Change-Id: I11cc4e7d57eced2f8f984153d48b4298ee71ec9e
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
Signed-off-by: Devin Kim <dojip.kim@lge.com>