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>
diag: Remove error message

Some diag messages are marked as error messages which should
be marked as debug. This patch fixes that issue.

Change-Id: If24b6cfdfca40321ff403826d8c149e8a3032803
Signed-off-by: Katish Paran <kparan@codeaurora.org>
Perf: Check perf activity on correct CPU

The CPU hotplug notifier is not always preempt safe.
So relying on smp_processor_id() is not correct.

Use the cpu id from the notifier as the target
CPU to check for perf activity before hotplug or power
collapse.

Change-Id: I1a96b236904a2c8ae2f82bbceab4ca8a195395d1
Signed-off-by: Ashwin Chaugule <ashwinc@codeaurora.org>
Perf: Add L1 counters to tracepoints

Create a new tracepoint to get L1 PMU counter
information at every context switch. Counters
are captured only when the tracepoint is enabled
via perf or ftrace.

Change-Id: If05527b29e04c700170cfdf9f88d300b2f558ffa
Signed-off-by: Ashwin Chaugule <ashwinc@codeaurora.org>
Perf: Fix counts across power collapse

After entry and exit from power collapse, the perf pm_notifier was
calling perf_pmu_disable/enable functions from perf core. Perf core
maintains a counter that it uses to match disable and enable calls but
since pm_notifier is invoked asynchronously, the counter was getting a
non-zero value which prevented the pmu from being enabled. As a result of
this, we were seeing zero counts for some cores across power collapse.

Make the architecture specific calls directly from pm_notifier.

Change-Id: I744e190906a20e70e1e4798235215c385018b121
Signed-off-by: Sheetal Sahasrabudhe <sheetals@codeaurora.org>
Perf: Make per-process counters configurable

Add feature to enable/disable per-process tracecounters at run-time.

Change-Id: Id6a4c7a0ecd1f5add85464c6ed260860e15c4e3b
Signed-off-by: Sheetal Sahasrabudhe <sheetals@codeaurora.org>
msm: perf: Add L2 support for tracecounters

Add L2 counter output to the tracecounters implementation.
This enables collection of L2 PMU counter values upon context switch.
Set up filtering based on number of L2 counters and number of cores.
Read L2 counter values and display them along with L1 counter values.

Change-Id: I8bbbd251ee52c66505d22ccf037c601013a916f0
Signed-off-by: Sheetal Sahasrabudhe <sheetals@codeaurora.org>
ARM: mm: remove IPI broadcasting on ASID rollover

ASIDs are allocated to MMU contexts based on a rolling counter. This
means that after 255 allocations we must invalidate all existing ASIDs
via an expensive IPI mechanism to synchronise all of the online CPUs and
ensure that all tasks execute with an ASID from the new generation.

This patch changes the rollover behaviour so that we rely instead on the
hardware broadcasting of the TLB invalidation to avoid the IPI calls.
This works by keeping track of the active ASID on each core, which is
then reserved in the case of a rollover so that currently scheduled
tasks can continue to run. For cores without hardware TLB broadcasting,
we keep track of pending flushes in a cpumask, so cores can flush their
local TLB before scheduling a new mm.

CRs-Fixed: 623919

Change-Id: I2ed0f2ab6635bf900bcb81e29efbd01991da8e86
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Git-commit: b5466f8728527a05a493cc4abe9e6f034a1bbaab
Git-repo: https://android.googlesource.com/kernel/common/
[spathi@codeaurora.org: removed unused function set_asid().
The function cpu_set_reserved_ttbr0() is not available since patch
"ARM: Use TTBR1 instead of reserved context ID" is not merged
so used old functionlity by calling cpu_set_asid(0)]
Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
ALSA: compress: Pass through return value of open ops callback

commit 749d32237bf39e6576dd95bfdf24e4378e51716c upstream.

The snd_compr_open function would always return 0 even if the compressed
ops open function failed, obviously this is incorrect. Looks like this
was introduced by a small typo in:

commit a0830dbd4e42b38aefdf3fb61ba5019a1a99ea85
ALSA: Add a reference counter to card instance

This patch returns the value from the compressed op as it should.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
libceph: resend all writes after the osdmap loses the full flag

commit 9a1ea2dbff11547a8e664f143c1ffefc586a577a upstream.

With the current full handling, there is a race between osds and
clients getting the first map marked full. If the osd wins, it will
return -ENOSPC to any writes, but the client may already have writes
in flight. This results in the client getting the error and
propagating it up the stack. For rbd, the block layer turns this into
EIO, which can cause corruption in filesystems above it.

To avoid this race, osds are being changed to drop writes that came
from clients with an osdmap older than the last osdmap marked full.
In order for this to work, clients must resend all writes after they
encounter a full -> not full transition in the osdmap. osds will wait
for an updated map instead of processing a request from a client with
a newer map, so resent writes will not be dropped by the osd unless
there is another not full -> full transition.

This approach requires both osds and clients to be fixed to avoid the
race. Old clients talking to osds with this fix may hang instead of
returning EIO and potentially corrupting an fs. New clients talking to
old osds have the same behavior as before if they encounter this race.

Fixes: http://tracker.ceph.com/issues/6938

Reviewed-by: Sage Weil <sage@inktank.com>
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iwlwifi: Complete backport of "iwlwifi: always copy first 16 bytes of commands"

Linux 3.4.83 included an incomplete backport of commit
8a964f44e01ad3bbc208c3e80d931ba91b9ea786 ('iwlwifi: always copy first
16 bytes of commands') which causes a regression for this driver.
This is the missing piece.

Reported-by: Andreas Sturmlechner <andreas.sturmlechner@gmail.com>
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: Jianguo Wu <wujianguo@huawei.com>
Cc: Andres Bertens <abertensu@yahoo.com>
Tested-by: Andreas Sturmlechner <andreas.sturmlechner@gmail.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
x86: bpf_jit: support negative offsets

commit fdfaf64e75397567257e1051931f9a3377360665 upstream.

Commit a998d4342337 claimed to introduce negative offset support to x86 jit,
but it couldn't be working, since at the time of the execution
of LD+ABS or LD+IND instructions via call into
bpf_internal_load_pointer_neg_helper() the %edx (3rd argument of this func)
had junk value instead of access size in bytes (1 or 2 or 4).

Store size into %edx instead of %ecx (what original commit intended to do)

Fixes: a998d4342337 ("bpf jit: Let the x86 jit handle negative offsets")
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Cc: Jan Seiffert <kaffeemonster@googlemail.com>
Cc: Eric Dumazet <edumazet@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
deb-pkg: Fix cross-building linux-headers package

commit f8ce239dfc7ba9add41d9ecdc5e7810738f839fa upstream.

builddeb generates a control file that says the linux-headers package
can only be built for the build system primary architecture.  This
breaks cross-building configurations.  We should use $debarch for this
instead.

Since $debarch is not yet set when generating the control file, set
Architecture: any and use control file variables to fill in the
description.

Fixes: cd8d60a20a45 ('kbuild: create linux-headers package in deb-pkg')
Reported-and-tested-by: "Niew, Sh." <shniew@gmail.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
p54: clamp properly instead of just truncating

commit 608cfbe4abaf76e9d732efd7ed1cfa3998163d91 upstream.

The call to clamp_t() first truncates the variable signed 8 bit and as a
result, the actual clamp is a no-op.

Fixes: 0d78156eef1d ('p54: improve site survey')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
i7300_edac: Fix device reference count

commit 75135da0d68419ef8a925f4c1d5f63d8046e314d upstream.

pci_get_device() decrements the reference count of "from" (last
argument) so when we break off the loop successfully we have only one
device reference - and we don't know which device we have. If we want
a reference to each device, we must take them explicitly and let
the pci_get_device() walk complete to avoid duplicate references.

This is serious, as over-putting device references will cause
the device to eventually disappear. Without this fix, the kernel
crashes after a few insmod/rmmod cycles.

Tested on an Intel S7000FC4UR system with a 7300 chipset.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Link: http://lkml.kernel.org/r/20140224111656.09bbb7ed@endymion.delvare
Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Doug Thompson <dougthompson@xmission.com>
Cc: stable@vger.kernel.org
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: move outer_cache declaration out of ifdef

commit 0b53c11d533a8f6688d73fad0baf67dd08ec1b90 upstream.

Move the outer_cache declaration of the CONFIG_OUTER_CACHE ifdef so that
outer_cache can be used inside IS_ENABLED condition.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Input: elantech - improve clickpad detection

commit c15bdfd5b9831e4cab8cfc118243956e267dd30e upstream.

The current assumption in the elantech driver that hw version 3 touchpads
are never clickpads and hw version 4 touchpads are always clickpads is
wrong.

There are several bug reports for this, ie:
https://bugzilla.redhat.com/show_bug.cgi?id=1030802
http://superuser.com/questions/619582/right-elantech-touchpad-button-not-working-in-linux

I've spend a couple of hours wading through various bugzillas, launchpads
and forum posts to create a list of fw-versions and capabilities for
different laptop models to find a good method to differentiate between
clickpads and versions with separate hardware buttons.

Which shows that a device being a clickpad is reliable indicated by bit 12
being set in the fw_version. I've included the gathered list inside the
driver, so that we've this info at hand if we need to revisit this later.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
KVM: MMU: handle invalid root_hpa at __direct_map

commit 989c6b34f6a9480e397b170cc62237e89bf4fdb9 upstream.

It is possible for __direct_map to be called on invalid root_hpa
(-1), two examples:

1) try_async_pf -> can_do_async_pf
    -> vmx_interrupt_allowed -> nested_vmx_vmexit
2) vmx_handle_exit -> vmx_interrupt_allowed -> nested_vmx_vmexit

Then to load_vmcs12_host_state and kvm_mmu_reset_context.

Check for this possibility, let fault exception be regenerated.

BZ: https://bugzilla.redhat.com/show_bug.cgi?id=924916

Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
KVM: VMX: fix use after free of vmx->loaded_vmcs

commit 26a865f4aa8e66a6d94958de7656f7f1b03c6c56 upstream.

After free_loaded_vmcs executes, the "loaded_vmcs" structure
is kfreed, and now vmx->loaded_vmcs points to a kfreed area.
Subsequent free_loaded_vmcs then attempts to manipulate
vmx->loaded_vmcs.

Switch the order to avoid the problem.

https://bugzilla.redhat.com/show_bug.cgi?id=1047892

Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>