linux-toradex.git, branch v3.17.6

Linux 3.17.6

2014-12-07T19:48:01+00:00

Revert "netfilter: conntrack: fix race in __nf_conntrack_confirm against get_next_corpse"

2014-12-07T19:46:46+00:00

This reverts commit 88fd8709858b9cd94e2d28b4b3cac4b752f0683a which was
commit 5195c14c8b27cc0b18220ddbf0e5ad3328a04187 upstream, which was
reverted in commit 43612d7c04f1a4f5e60104143918fcdf018b66ee.

Reported-by: Pablo Neira Ayuso 
Cc: Daniel Borkmann 
Cc: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Linux 3.17.5

2014-12-06T23:57:59+00:00

netfilter: conntrack: fix race in __nf_conntrack_confirm against get_next_corpse

2014-12-06T23:57:34+00:00

commit 5195c14c8b27cc0b18220ddbf0e5ad3328a04187 upstream.

After removal of the central spinlock nf_conntrack_lock, in
commit 93bb0ceb75be2 ("netfilter: conntrack: remove central
spinlock nf_conntrack_lock"), it is possible to race against
get_next_corpse().

The race is against the get_next_corpse() cleanup on
the "unconfirmed" list (a per-cpu list with seperate locking),
which set the DYING bit.

Fix this race, in __nf_conntrack_confirm(), by removing the CT
from unconfirmed list before checking the DYING bit.  In case
race occured, re-add the CT to the dying list.

While at this, fix coding style of the comment that has been
updated.

Fixes: 93bb0ceb75be2 ("netfilter: conntrack: remove central spinlock nf_conntrack_lock")
Reported-by: bill bonaparte 
Signed-off-by: bill bonaparte 
Signed-off-by: Jesper Dangaard Brouer 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman

x86: kvm: use alternatives for VMCALL vs. VMMCALL if kernel text is read-only

2014-12-06T23:57:34+00:00

commit c1118b3602c2329671ad5ec8bdf8e374323d6343 upstream.

On x86_64, kernel text mappings are mapped read-only with CONFIG_DEBUG_RODATA.
In that case, KVM will fail to patch VMCALL instructions to VMMCALL
as required on AMD processors.

The failure mode is currently a divide-by-zero exception, which obviously
is a KVM bug that has to be fixed.  However, picking the right instruction
between VMCALL and VMMCALL will be faster and will help if you cannot upgrade
the hypervisor.

Reported-by: Chris Webb 
Tested-by: Chris Webb 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x86@kernel.org
Acked-by: Borislav Petkov 
Signed-off-by: Paolo Bonzini 
Cc: Chris J Arges 
Signed-off-by: Greg Kroah-Hartman

clk: qcom: Fix duplicate rbcpr clock name

2014-12-06T23:57:34+00:00

commit 9a6cb70f40b0268297024949eb0a2689e3b7769b upstream.

There is a duplication in a clock name for apq8084 platform that causes
the following warning: "RBCPR_CLK_SRC" redefined

Resolve this by adding a MMSS_ prefix to this clock and making its name
coherent with msm8974 platform.

Fixes: 2b46cd23a5a2 ("clk: qcom: Add APQ8084 Multimedia Clock Controller (MMCC) support")
Signed-off-by: Georgi Djakov 
Reviewed-by: Stephen Boyd 
Signed-off-by: Michael Turquette 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Ignore long hpds on eDP ports

2014-12-06T23:57:34+00:00

original upstream id: 7a7f84ccb82e542c845c43f604665ccea1247866

Turning vdd on/off can generate a long hpd pulse on eDP ports. In order
to handle hpd we would need to turn on vdd to perform aux transfers.
This would lead to an endless cycle of
"vdd off -> long hpd -> vdd on -> detect -> vdd off -> ..."

So ignore long hpd pulses on eDP ports. eDP panels should be physically
tied to the machine anyway so they should not actually disappear and
thus don't need long hpd handling. Short hpds are still needed for link
re-train and whatnot so we can't just turn off the hpd interrupt
entirely for eDP ports. Perhaps we could turn it off whenever the panel
is disabled, but just ignoring the long hpd seems sufficient.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Dave Airlie 
Reviewed-by: Todd Previte 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: check TLV flag before trying to use hotspot firmware commands

2014-12-06T23:57:33+00:00

commit 5ac6c72e594471acfa5b00210c51d533a73413ad upstream.

Older firmwares do not provide support for the HOT_SPOT_CMD command.
Check for the appropriate TLV flag that declares hotspot support in
the firmware to prevent a firmware assertion failure that can be
triggered from the userspace,

Signed-off-by: Luciano Coelho 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: ROC - bug fixes around time events and locking

2014-12-06T23:57:33+00:00

commit a6cc5163149532734b84c86cbffa4994e527074b upstream.

Don't add the time event to the list. We added it several
times the same time event, which leads to an infinite loop
when walking the list.

Since we (currently) don't support more than one ROC for STA
vif at a time, enforce this and don't add the time event
to any list.

We were also missing the locking of the mutex which led to
a lockdep splat - fix that.

Signed-off-by: Matti Gottlieb 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

powerpc/powernv: Honor the generic "no_64bit_msi" flag

2014-12-06T23:57:33+00:00

commit 360743814c4082515581aa23ab1d8e699e1fbe88 upstream.

Instead of the arch specific quirk which we are deprecating
and that drivers don't understand.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman