linux.git/arch, branch v4.4.114

x86/microcode/intel: Extend BDW late-loading further with LLC size check

2018-01-31T11:06:12+00:00

commit 7e702d17ed138cf4ae7c00e8c00681ed464587c7 upstream.

Commit b94b73733171 ("x86/microcode/intel: Extend BDW late-loading with a
revision check") reduced the impact of erratum BDF90 for Broadwell model
79.

The impact can be reduced further by checking the size of the last level
cache portion per core.

Tony: "The erratum says the problem only occurs on the large-cache SKUs.
So we only need to avoid the update if we are on a big cache SKU that is
also running old microcode."

For more details, see erratum BDF90 in document #334165 (Intel Xeon
Processor E7-8800/4800 v4 Product Family Specification Update) from
September 2017.

Fixes: b94b73733171 ("x86/microcode/intel: Extend BDW late-loading with a revision check")
Signed-off-by: Jia Zhang 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Acked-by: Tony Luck 
Link: https://lkml.kernel.org/r/1516321542-31161-1-git-send-email-zhang.jia@linux.alibaba.com
Signed-off-by: Greg Kroah-Hartman

vsyscall: Fix permissions for emulate mode with KAISER/PTI

2018-01-31T11:06:12+00:00

The backport of KAISER to 4.4 turned vsyscall emulate mode into native
mode.  Add a vsyscall_pgprot variable to hold the correct page
protections, like Borislav and Hugh did for 3.2 and 3.18.

Cc: Borislav Petkov 
Cc: Hugh Dickins 
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

um: link vmlinux with -no-pie

2018-01-31T11:06:12+00:00

commit 883354afbc109c57f925ccc19840055193da0cc0 upstream.

Debian's gcc defaults to pie. The global Makefile already defines the -fno-pie option.
Link UML dynamic kernel image also with -no-pie to fix the build.

Signed-off-by: Thomas Meyer 
Signed-off-by: Richard Weinberger 
Cc: Bernie Innocenti 
Signed-off-by: Greg Kroah-Hartman

x86/ioapic: Fix incorrect pointers in ioapic_setup_resources()

2018-01-31T11:06:09+00:00

commit 9d98bcec731756b8688b59ec998707924d716d7b upstream.

On a 4-socket Brickland system, hot-removing one ioapic is fine.
Hot-removing the 2nd one causes panic in mp_unregister_ioapic()
while calling release_resource().

It is because the iomem_res pointer has already been released
when removing the first ioapic.

To explain the use of &res[num] here: res is assigned to ioapic_resources,
and later in ioapic_insert_resources() we do:

	struct resource *r = ioapic_resources;

        for_each_ioapic(i) {
                insert_resource(&iomem_resource, r);
                r++;
        }

Here 'r' is treated as an arry of 'struct resource', and the r++ ensures
that each element of the array is inserted separately. Thus we should call
release_resouce() on each element at &res[num].

Fix it by assigning the correct pointers to ioapics[i].iomem_res in
ioapic_setup_resources().

Signed-off-by: Rui Wang 
Signed-off-by: Thomas Gleixner 
Cc: tony.luck@intel.com
Cc: linux-pci@vger.kernel.org
Cc: rjw@rjwysocki.net
Cc: linux-acpi@vger.kernel.org
Cc: bhelgaas@google.com
Link: http://lkml.kernel.org/r/1465369193-4816-3-git-send-email-rui.y.wang@intel.com
Signed-off-by: Ingo Molnar 
Acked-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

drivers: base: cacheinfo: fix x86 with CONFIG_OF enabled

2018-01-31T11:06:08+00:00

commit fac51482577d5e05bbb0efa8d602a3c2111098bf upstream.

With CONFIG_OF enabled on x86, we get the following error on boot:
"
	Failed to find cpu0 device node
 	Unable to detect cache hierarchy from DT for CPU 0
"
and the cacheinfo fails to get populated in the corresponding sysfs
entries. This is because cache_setup_of_node looks for of_node for
setting up the shared cpu_map without checking that it's already
populated in the architecture specific callback.

In order to indicate that the shared cpu_map is already populated, this
patch introduces a boolean `cpu_map_populated` in struct cpu_cacheinfo
that can be used by the generic code to skip cache_shared_cpu_map_setup.

This patch also sets that boolean for x86.

Cc: Greg Kroah-Hartman 
Signed-off-by: Sudeep Holla 
Signed-off-by: Mian Yousaf Kaukab 
Signed-off-by: Greg Kroah-Hartman

Prevent timer value 0 for MWAITX

2018-01-31T11:06:08+00:00

commit 88d879d29f9cc0de2d930b584285638cdada6625 upstream.

Newer hardware has uncovered a bug in the software implementation of
using MWAITX for the delay function. A value of 0 for the timer is meant
to indicate that a timeout will not be used to exit MWAITX. On newer
hardware this can result in MWAITX never returning, resulting in NMI
soft lockup messages being printed. On older hardware, some of the other
conditions under which MWAITX can exit masked this issue. The AMD APM
does not currently document this and will be updated.

Please refer to http://marc.info/?l=kvm&m=148950623231140 for
information regarding NMI soft lockup messages on an AMD Ryzen 1800X.
This has been root-caused as a 0 passed to MWAITX causing it to wait
indefinitely.

This change has the added benefit of avoiding the unnecessary setup of
MONITORX/MWAITX when the delay value is zero.

Signed-off-by: Janakarajan Natarajan 
Link: http://lkml.kernel.org/r/1493156643-29366-1-git-send-email-Janakarajan.Natarajan@amd.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Davidlohr Bueso 
Signed-off-by: Greg Kroah-Hartman

x86/retpoline: Fill RSB on context switch for affected CPUs

2018-01-31T11:06:07+00:00

commit c995efd5a740d9cbafbf58bde4973e8b50b4d761 upstream.

On context switch from a shallow call stack to a deeper one, as the CPU
does 'ret' up the deeper side it may encounter RSB entries (predictions for
where the 'ret' goes to) which were populated in userspace.

This is problematic if neither SMEP nor KPTI (the latter of which marks
userspace pages as NX for the kernel) are active, as malicious code in
userspace may then be executed speculatively.

Overwrite the CPU's return prediction stack with calls which are predicted
to return to an infinite loop, to "capture" speculation if this
happens. This is required both for retpoline, and also in conjunction with
IBRS for !SMEP && !KPTI.

On Skylake+ the problem is slightly different, and an *underflow* of the
RSB may cause errant branch predictions to occur. So there it's not so much
overwrite, as *filling* the RSB to attempt to prevent it getting
empty. This is only a partial solution for Skylake+ since there are many
other conditions which may result in the RSB becoming empty. The full
solution on Skylake+ is to use IBRS, which will prevent the problem even
when the RSB becomes empty. With IBRS, the RSB-stuffing will not be
required on context switch.

[ tglx: Added missing vendor check and slighty massaged comments and
  	changelog ]

[js] backport to 4.4 -- __switch_to_asm does not exist there, we
     have to patch the switch_to macros for both x86_32 and x86_64.

Signed-off-by: David Woodhouse 
Signed-off-by: Thomas Gleixner 
Acked-by: Arjan van de Ven 
Cc: gnomes@lxorguk.ukuu.org.uk
Cc: Rik van Riel 
Cc: Andi Kleen 
Cc: Josh Poimboeuf 
Cc: thomas.lendacky@amd.com
Cc: Peter Zijlstra 
Cc: Linus Torvalds 
Cc: Jiri Kosina 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: Kees Cook 
Cc: Tim Chen 
Cc: Greg Kroah-Hartman 
Cc: Paul Turner 
Link: https://lkml.kernel.org/r/1515779365-9032-1-git-send-email-dwmw@amazon.co.uk
Signed-off-by: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman

x86/cpu/intel: Introduce macros for Intel family numbers

2018-01-31T11:06:07+00:00

commit 970442c599b22ccd644ebfe94d1d303bf6f87c05 upstream.

Problem:

We have a boatload of open-coded family-6 model numbers.  Half of
them have these model numbers in hex and the other half in
decimal.  This makes grepping for them tons of fun, if you were
to try.

Solution:

Consolidate all the magic numbers.  Put all the definitions in
one header.

The names here are closely derived from the comments describing
the models from arch/x86/events/intel/core.c.  We could easily
make them shorter by doing things like s/SANDYBRIDGE/SNB/, but
they seemed fine even with the longer versions to me.

Do not take any of these names too literally, like "DESKTOP"
or "MOBILE".  These are all colloquial names and not precise
descriptions of everywhere a given model will show up.

Signed-off-by: Dave Hansen 
Cc: Adrian Hunter 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Darren Hart 
Cc: Dave Hansen 
Cc: Denys Vlasenko 
Cc: Doug Thompson 
Cc: Eduardo Valentin 
Cc: H. Peter Anvin 
Cc: Jacob Pan 
Cc: Kan Liang 
Cc: Len Brown 
Cc: Linus Torvalds 
Cc: Mauro Carvalho Chehab 
Cc: Peter Zijlstra 
Cc: Rafael J. Wysocki 
Cc: Rajneesh Bhardwaj 
Cc: Souvik Kumar Chakravarty 
Cc: Srinivas Pandruvada 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Cc: Ulf Hansson 
Cc: Viresh Kumar 
Cc: Vishwanath Somayaji 
Cc: Zhang Rui 
Cc: jacob.jun.pan@intel.com
Cc: linux-acpi@vger.kernel.org
Cc: linux-edac@vger.kernel.org
Cc: linux-mmc@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: platform-driver-x86@vger.kernel.org
Link: http://lkml.kernel.org/r/20160603001927.F2A7D828@viggo.jf.intel.com
Signed-off-by: Ingo Molnar 
Cc: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman

x86/microcode/intel: Fix BDW late-loading revision check

2018-01-31T11:06:07+00:00

The backport of commit b94b73733171 ("x86/microcode/intel: Extend BDW
late-loading with a revision check") to 4.4-stable deleted a "return true"
statement.  This bug is not present upstream or other stable branches.

Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels

2018-01-31T11:06:07+00:00

commit 1c52d859cb2d417e7216d3e56bb7fea88444cec9 upstream.

We support various non-Intel CPUs that don't have the CPUID
instruction, so the M486 test was wrong.  For now, fix it with a big
hammer: handle missing CPUID on all 32-bit CPUs.

Reported-by: One Thousand Gnomes 
Signed-off-by: Andy Lutomirski 
Cc: Juergen Gross 
Cc: Peter Zijlstra 
Cc: Brian Gerst 
Cc: Matthew Whitehead 
Cc: Borislav Petkov 
Cc: Henrique de Moraes Holschuh 
Cc: Andrew Cooper 
Cc: Boris Ostrovsky 
Cc: xen-devel 
Link: http://lkml.kernel.org/r/685bd083a7c036f7769510b6846315b17d6ba71f.1481307769.git.luto@kernel.org
Signed-off-by: Thomas Gleixner 
Cc: "Zhang, Ning A" 
Signed-off-by: Greg Kroah-Hartman