block: row: Remove warning massage from add_request

Regular priority queues is marked as "starved" if it skipped a dispatch
due to being empty. When a new request is added to a "starved" queue
it will be marked as urgent.
The removed WARN_ON was warning about an impossible case when a regular
priority (read) queue was marked as starved but wasn't empty. This is
a possible case due to the bellow:
If the device driver fetched a read request that is pending for
transmission and an URGENT request arrives, the fetched read will be
reinserted back to the scheduler. Its possible that the queue it will be
reinserted to was marked as "starved" in the meanwhile due to being empty.

CRs-fixed: 517800
Change-Id: Iaae642ea0ed9c817c41745b0e8ae2217cc684f0c
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Squashed update of kernel from 3.4.55 to 3.4.56
Bluetooth: Fix for the l2cap layer crashes while turning OFF BT

-This patch fix a case where while turning OFF BT l2cap channel
 & l2cap conn get deleted in one process context, which preempted
 the another process, where l2cap con was being used while trying to
 disconnect l2cap.  As the result l2cap conn pointer become invalid.
 Later which is leading a crash.  L2cap conn should be guarded by
 spin lock while disconnecting l2cap to avoid preemption which will
 avoid  crash due invalid conn pointer.

-This patch fix list_add crash due to invalid skb pointer.
 & BUG sleep warning as well.

CRs-Fixed: 499732, 504054

Change-Id: I90c5d29cc8728566a420f0dedaf7075846b32d1a
Signed-off-by: Nitin Shivpure <nshivpur@codeaurora.org>
configs: Better support for VPN over IPsec
Enable setting security contexts on rootfs inodes.

rootfs (ramfs) can support setting of security contexts
by userspace due to the vfs fallback behavior of calling
the security module to set the in-core inode state
for security.* attributes when the filesystem does not
provide an xattr handler.  No xattr handler required
as the inodes are pinned in memory and have no backing
store.

This is useful in allowing early userspace to label individual
files within a rootfs while still providing a policy-defined
default via genfs.

Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Change-Id: I3436cf9ae27ade445e37376d7b9125746b1e506f
ariesve_sensors: updated all sensors to match with the new opensource libsensors
changes:
-changed the input events and the event type for some sensors, the newer kernels use EV_REL for the relative axis values and EV_ABS for the absolute axis values
-corrected some event type with the new types standard
-added support to 10ms data delay for the magnetic sensor yas529 (ref. datasheet)
-changed the names of sensors with the standard conventional names (for math with the libsensors and the new deamons)
-cleanup some code
-removed the unnecessary drivers
marimba_profile_ancora_tmo: Remove spacing between backslash and newline to supress warning. Align tab spacing.
Squashed update of kernel from 3.4.56 to 3.4.57
board_ariesve: cleanup mdp_pdata and added missing mem_hid
Squashed update of kernel from 3.4.57 to 3.4.58
Squashed update of kernel from 3.4.58 to 3.4.59
Squashed update of kernel from 3.4.59 to 3.4.60
msm: scm: Add scm_call_noalloc and helper macros

Currently, scm_call internally calls kmalloc() to allocate a command
buffer structure. This prevents scm_call from working before kmalloc
structures are initialized or during atomic contexts. Allow clients
to pass in a pre-allocated buffer for scm_call to be used for internal
structures.

Change-Id: Id09500c8c696298228aefdcc2a61953e654677c9
CRs-Fixed: 498392
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
arm: Add ARCH_RANDOM Kconfig

Some boards may support architecture generated random numbers. Add
the appropriate Kconfig.

Change-Id: I0077a982c9bb6d3a35435cc27fe40b7e0596ca84
CRs-Fixed: 498392
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
msm: implement ARCH_RANDOM

Currently, the software random number generator is not intialized
until relatively late in the boot process. Software that relies on
random numbers early will not be reliable. Entropy sources are
available early but not early enough for some use cases which means
that moving the software random number generation earlier is not an
option. As an alternate solution, implement the functions associated
with CONFIG_ARCH_RANDOM. These functions currently make a call into
trustzone to get reliable random numbers. The functions are disabled
once the regular random number generator is sufficiently reliable.

Change-Id: If40cfcb96b091fa26a28047c10a902287b26f6c1
CRs-Fixed: 498392
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
init: Move stack canary initialization after setup_arch

Stack canary intialization involves getting a random number.
Getting this random number may involve accessing caches or other
architectural specific features which are not available until
after the architecture is setup. Move the stack canary initialization
later to accomodate this.

Change-Id: I00b564a2c3172229a44339c061fa380c17fe7d8e
CRs-Fixed: 498392
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
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>
net: ipv6: add missing lock in ping_v6_sendmsg

Bug: 9469865
Change-Id: I5e9db559d22e35d27fa1df948b70c70ed8b42115
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: ipv6: fix wrong ping_v6_sendmsg return value

ping_v6_sendmsg currently returns 0 on success. It should return
the number of bytes written instead.

Bug: 9469865
Change-Id: I14aad6018f0c3fd92dad315bc3ade04c0b3982e0
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>