linux.git, branch v4.18.8

Linux 4.18.8

2018-09-15T07:47:02+00:00

ASoC: wm8994: Fix missing break in switch

2018-09-15T07:47:02+00:00

commit ad0eaee6195db1db1749dd46b9e6f4466793d178 upstream.

Add missing break statement in order to prevent the code from falling
through to the default case.

Addresses-Coverity-ID: 115050 ("Missing break in switch")
Reported-by: Valdis Kletnieks 
Signed-off-by: Gustavo A. R. Silva 
Acked-by: Charles Keepax 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org
[Gustavo: Backported to 3.16..4.18 - Remove code comment removal]
Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Greg Kroah-Hartman

HID: redragon: fix num lock and caps lock LEDs

2018-09-15T07:47:02+00:00

commit dc9b8e85ed95cbe7e3ad0eabb5b48d617bbc365e upstream.

The redragon asura keyboard registers two input devices. The initial commit
85455dd906d5 ("HID: redragon: Fix modifier keys for Redragon Asura Keyboard")
considered this an error and prevented one of the devices from registering.
However, once this is done the num lock and caps lock leds no longer toggle on
and off, although the key functionality is not affected.

This commit removes the code that prevents the input device
registration and restores the num lock and caps lock LEDs.

Fixes: 85455dd906d5 ("HID: redragon: Fix modifier keys for Redragon Asura Keyboard")
Signed-off-by: Robert Munteanu 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

x86: kvm: avoid unused variable warning

2018-09-15T07:47:02+00:00

commit 7288bde1f9df6c1475675419bdd7725ce84dec56 upstream.

Removing one of the two accesses of the maxphyaddr variable led to
a harmless warning:

arch/x86/kvm/x86.c: In function 'kvm_set_mmio_spte_mask':
arch/x86/kvm/x86.c:6563:6: error: unused variable 'maxphyaddr' [-Werror=unused-variable]

Removing the #ifdef seems to be the nicest workaround, as it
makes the code look cleaner than adding another #ifdef.

Fixes: 28a1f3ac1d0c ("kvm: x86: Set highest physical address bits in non-present/reserved SPTEs")
Signed-off-by: Arnd Bergmann 
Cc: stable@vger.kernel.org # L1TF
Signed-off-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman

kvm: x86: Set highest physical address bits in non-present/reserved SPTEs

2018-09-15T07:47:02+00:00

commit 28a1f3ac1d0c8558ee4453d9634dad891a6e922e upstream.

Always set the 5 upper-most supported physical address bits to 1 for SPTEs
that are marked as non-present or reserved, to make them unusable for
L1TF attacks from the guest. Currently, this just applies to MMIO SPTEs.
(We do not need to mark PTEs that are completely 0 as physical page 0
is already reserved.)

This allows mitigation of L1TF without disabling hyper-threading by using
shadow paging mode instead of EPT.

Signed-off-by: Junaid Shahid 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman

kbuild: make missing $DEPMOD a Warning instead of an Error

2018-09-15T07:47:02+00:00

commit 914b087ff9e0e9a399a4927fa30793064afc0178 upstream.

When $DEPMOD is not found, only print a warning instead of exiting
with an error message and error status:

Warning: 'make modules_install' requires /sbin/depmod. Please install it.
This is probably in the kmod package.

Change the Error to a Warning because "not all build hosts for cross
compiling Linux are Linux systems and are able to provide a working
port of depmod, especially at the file patch /sbin/depmod."

I.e., "make modules_install" may be used to copy/install the
loadable modules files to a target directory on a build system and
then transferred to an embedded device where /sbin/depmod is run
instead of it being run on the build system.

Fixes: 934193a654c1 ("kbuild: verify that $DEPMOD is installed")
Signed-off-by: Randy Dunlap 
Reported-by: H. Nikolaus Schaller 
Cc: stable@vger.kernel.org
Cc: Lucas De Marchi 
Cc: Lucas De Marchi 
Cc: Michal Marek 
Cc: Jessica Yu 
Cc: Chih-Wei Huang 
Signed-off-by: Masahiro Yamada 
Signed-off-by: Greg Kroah-Hartman

x86/xen: don't write ptes directly in 32-bit PV guests

2018-09-15T07:47:02+00:00

commit f7c90c2aa4004808dff777ba6ae2c7294dd06851 upstream.

In some cases 32-bit PAE PV guests still write PTEs directly instead of
using hypercalls. This is especially bad when clearing a PTE as this is
done via 32-bit writes which will produce intermediate L1TF attackable
PTEs.

Change the code to use hypercalls instead.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 
Signed-off-by: Boris Ostrovsky 
Signed-off-by: Greg Kroah-Hartman

x86/pae: use 64 bit atomic xchg function in native_ptep_get_and_clear

2018-09-15T07:47:01+00:00

commit b2d7a075a1ccef2fb321d595802190c8e9b39004 upstream.

Using only 32-bit writes for the pte will result in an intermediate
L1TF vulnerable PTE. When running as a Xen PV guest this will at once
switch the guest to shadow mode resulting in a loss of performance.

Use arch_atomic64_xchg() instead which will perform the requested
operation atomically with all 64 bits.

Some performance considerations according to:

https://software.intel.com/sites/default/files/managed/ad/dc/Intel-Xeon-Scalable-Processor-throughput-latency.pdf

The main number should be the latency, as there is no tight loop around
native_ptep_get_and_clear().

"lock cmpxchg8b" has a latency of 20 cycles, while "lock xchg" (with a
memory operand) isn't mentioned in that document. "lock xadd" (with xadd
having 3 cycles less latency than xchg) has a latency of 11, so we can
assume a latency of 14 for "lock xchg".

Signed-off-by: Juergen Gross 
Reviewed-by: Thomas Gleixner 
Reviewed-by: Jan Beulich 
Tested-by: Jason Andryuk 
Signed-off-by: Boris Ostrovsky 
Signed-off-by: Greg Kroah-Hartman

debugobjects: Make stack check warning more informative

2018-09-15T07:47:01+00:00

commit fc91a3c4c27acdca0bc13af6fbb68c35cfd519f2 upstream.

While debugging an issue debugobject tracking warned about an annotation
issue of an object on stack. It turned out that the issue was due to the
object in concern being on a different stack which was due to another
issue.

Thomas suggested to print the pointers and the location of the stack for
the currently running task. This helped to figure out that the object was
on the wrong stack.

As this is general useful information for debugging similar issues, make
the error message more informative by printing the pointers.

[ tglx: Massaged changelog ]

Signed-off-by: Joel Fernandes (Google) 
Signed-off-by: Thomas Gleixner 
Acked-by: Waiman Long 
Acked-by: Yang Shi 
Cc: kernel-team@android.com
Cc: Arnd Bergmann 
Cc: astrachan@google.com
Link: https://lkml.kernel.org/r/20180723212531.202328-1-joel@joelfernandes.org
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Don't warn on destroying a pinned BO

2018-09-15T07:47:01+00:00

commit 456607d816d89a442a3d5ec98b02c8bc950b5228 upstream.

The warning turned out to be not so useful, as BO destruction tends to
be deferred to a workqueue.

Also, we should be preventing any damage from this now, so not really
important anymore to fix code doing this.

Acked-by: Alex Deucher 
Tested-by: Mike Lothian 
Signed-off-by: Michel Dänzer 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman