4.14.9-stable review
Subsystems (9)
Greg Kroah-Hartman
maintainerPATCH 65/159 x86/virt: Add enum for hypervisors to replace x86_hyper
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Juergen Gross <[email protected]>
commit 03b2a320b19f1424e9ac9c21696be9c60b6d0d93 upstream.
The x86_hyper pointer is only used for checking whether a virtual device is supporting the hypervisor the system is running on.
Use an enum for that purpose instead and drop the x86_hyper pointer.
--- arch/x86/hyperv/hv_init.c | 2 +- arch/x86/include/asm/hypervisor.h | 23 ++++++++++++++--------- arch/x86/kernel/cpu/hypervisor.c | 12 +++++++++--- arch/x86/kernel/cpu/mshyperv.c | 4 ++-- arch/x86/kernel/cpu/vmware.c | 4 ++-- arch/x86/kernel/kvm.c | 4 ++-- arch/x86/xen/enlighten_hvm.c | 4 ++-- arch/x86/xen/enlighten_pv.c | 4 ++-- drivers/hv/vmbus_drv.c | 2 +- drivers/input/mouse/vmmouse.c | 10 ++++------ drivers/misc/vmw_balloon.c | 2 +- 11 files changed, 40 insertions(+), 31 deletions(-)
arch/x86/hyperv/hv_init.c +1 -1
@@ -113,7 +113,7 @@ void hyperv_init(void)u64 guest_id;union hv_x64_msr_hypercall_contents hypercall_msr; -if (x86_hyper != &x86_hyper_ms_hyperv) +if (x86_hyper_type !=X86_HYPER_MS_HYPERV )return ;/* Allocate percpu VP index */
arch/x86/include/asm/hypervisor.h +14 -9
@@ -29,6 +29,16 @@/* * x86 hypervisor information */ + +enum x86_hypervisor_type { +X86_HYPER_NATIVE =0 , +X86_HYPER_VMWARE , +X86_HYPER_MS_HYPERV , +X86_HYPER_XEN_PV , +X86_HYPER_XEN_HVM , +X86_HYPER_KVM , +}; +struct hypervisor_x86 {/* Hypervisor name */ const char *name;
@@ -36,6 +46,9 @@ struct hypervisor_x86 {/* Detection routine */ uint32_t (*detect)(void ); +/* Hypervisor type */ +enum x86_hypervisor_type type; +/* init time callbacks */ struct x86_hyper_init init;
@@ -43,15 +56,7 @@ struct hypervisor_x86 { struct x86_hyper_runtime runtime; }; -extern const struct hypervisor_x86 *x86_hyper; - -/* Recognized hypervisors */ -extern const struct hypervisor_x86 x86_hyper_vmware; -extern const struct hypervisor_x86 x86_hyper_ms_hyperv; -extern const struct hypervisor_x86 x86_hyper_xen_pv; -extern const struct hypervisor_x86 x86_hyper_xen_hvm; -extern const struct hypervisor_x86 x86_hyper_kvm; - +extern enum x86_hypervisor_type x86_hyper_type;extern void init_hypervisor_platform (void );#else static inline void init_hypervisor_platform (void ) { }
arch/x86/kernel/cpu/hypervisor.c +9 -3
@@ -26,6 +26,12 @@#include <asm/processor.h> #include <asm/hypervisor.h> +extern const struct hypervisor_x86 x86_hyper_vmware; +extern const struct hypervisor_x86 x86_hyper_ms_hyperv; +extern const struct hypervisor_x86 x86_hyper_xen_pv; +extern const struct hypervisor_x86 x86_hyper_xen_hvm; +extern const struct hypervisor_x86 x86_hyper_kvm; +static const __initconst struct hypervisor_x86 *const hypervisors[] = { #ifdef CONFIG_XEN_PV
@@ -41,8 +47,8 @@ static const __initconst struct hypervis#endif }; -const struct hypervisor_x86 *x86_hyper; -EXPORT_SYMBOL (x86_hyper); +enum x86_hypervisor_type x86_hyper_type; +EXPORT_SYMBOL (x86_hyper_type);static inline const struct hypervisor_x86 *__init detect_hypervisor_vendor (void )
@@ -87,6 +93,6 @@ void __init init_hypervisor_platform(voicopy_array (&h->init, &x86_init.hyper,sizeof (h->init));copy_array (&h->runtime, &x86_platform.hyper,sizeof (h->runtime)); - x86_hyper = h; + x86_hyper_type = h->type; x86_init.hyper.init_platform (); }
arch/x86/kernel/cpu/mshyperv.c +2 -2
@@ -254,9 +254,9 @@ static void __init ms_hyperv_init_platfo#endif } -const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = { +const __initconst struct hypervisor_x86 x86_hyper_ms_hyperv = { .name ="Microsoft Hyper-V" , .detect = ms_hyperv_platform, + .type =X86_HYPER_MS_HYPERV , .init.init_platform = ms_hyperv_init_platform, }; -EXPORT_SYMBOL (x86_hyper_ms_hyperv);
arch/x86/kernel/cpu/vmware.c +2 -2
@@ -205,10 +205,10 @@ static bool __init vmware_legacy_x2apic_ (eax & (1 <<VMWARE_PORT_CMD_LEGACY_X2APIC )) !=0 ; } -const __refconst struct hypervisor_x86 x86_hyper_vmware = { +const __initconst struct hypervisor_x86 x86_hyper_vmware = { .name ="VMware" , .detect = vmware_platform, + .type =X86_HYPER_VMWARE , .init.init_platform = vmware_platform_setup, .init.x2apic_available = vmware_legacy_x2apic_available, }; -EXPORT_SYMBOL (x86_hyper_vmware);
arch/x86/kernel/kvm.c +2 -2
@@ -544,12 +544,12 @@ static uint32_t __init kvm_detect(void)return kvm_cpuid_base (); } -const struct hypervisor_x86 x86_hyper_kvm__refconst = { +const __initconst struct hypervisor_x86 x86_hyper_kvm = { .name ="KVM" , .detect = kvm_detect, + .type =X86_HYPER_KVM , .init.x2apic_available = kvm_para_available, }; -EXPORT_SYMBOL_GPL (x86_hyper_kvm);static __init int activate_jump_labels (void ) {
arch/x86/xen/enlighten_hvm.c +2 -2
@@ -226,12 +226,12 @@ static uint32_t __init xen_platform_hvm(return xen_cpuid_base (); } -const struct hypervisor_x86 x86_hyper_xen_hvm = { +const __initconst struct hypervisor_x86 x86_hyper_xen_hvm = { .name ="Xen HVM" , .detect = xen_platform_hvm, + .type =X86_HYPER_XEN_HVM , .init.init_platform = xen_hvm_guest_init, .init.x2apic_available = xen_x2apic_para_available, .init.init_mem_mapping = xen_hvm_init_mem_mapping, .runtime.pin_vcpu = xen_pin_vcpu, }; -EXPORT_SYMBOL (x86_hyper_xen_hvm);
arch/x86/xen/enlighten_pv.c +2 -2
@@ -1459,9 +1459,9 @@ static uint32_t __init xen_platform_pv(vreturn 0 ; } -const struct hypervisor_x86 x86_hyper_xen_pv = { +const __initconst struct hypervisor_x86 x86_hyper_xen_pv = { .name ="Xen PV" , .detect = xen_platform_pv, + .type =X86_HYPER_XEN_PV , .runtime.pin_vcpu = xen_pin_vcpu, }; -EXPORT_SYMBOL (x86_hyper_xen_pv);
drivers/hv/vmbus_drv.c +1 -1
@@ -1534,7 +1534,7 @@ static int __init hv_acpi_init(void) {int ret, t; -if (x86_hyper != &x86_hyper_ms_hyperv) +if (x86_hyper_type !=X86_HYPER_MS_HYPERV )return -ENODEV ;init_completion (&probe_event);
drivers/input/mouse/vmmouse.c +4 -6
@@ -316,11 +316,9 @@ static int vmmouse_enable(struct psmouse/* * Array of supported hypervisors. */ -static const struct hypervisor_x86 *vmmouse_supported_hypervisors[] = { - &x86_hyper_vmware, -#ifdef CONFIG_KVM_GUEST - &x86_hyper_kvm, -#endif +static enum x86_hypervisor_type vmmouse_supported_hypervisors[] = { +X86_HYPER_VMWARE , +X86_HYPER_KVM , };/**
@@ -331,7 +329,7 @@ static bool vmmouse_check_hypervisor(voiint i;for (i =0 ; i <ARRAY_SIZE (vmmouse_supported_hypervisors); i++) -if (vmmouse_supported_hypervisors[i] == x86_hyper) +if (vmmouse_supported_hypervisors[i] == x86_hyper_type)return true;return false;
drivers/misc/vmw_balloon.c +1 -1
@@ -1271,7 +1271,7 @@ static int __init vmballoon_init(void)* Check if we are running on VMware's hypervisor and bail out * if we are not. */ -if (x86_hyper != &x86_hyper_vmware) +if (x86_hyper_type !=X86_HYPER_VMWARE )return -ENODEV ; for (is_2m_pages = 0; is_2m_pages < VMW_BALLOON_NUM_PAGE_SIZES;
Greg Kroah-Hartman
maintainerPATCH 65/159 x86/virt: Add enum for hypervisors to replace x86_hyper
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Juergen Gross <[email protected]>
commit 03b2a320b19f1424e9ac9c21696be9c60b6d0d93 upstream.
The x86_hyper pointer is only used for checking whether a virtual device is supporting the hypervisor the system is running on.
Use an enum for that purpose instead and drop the x86_hyper pointer.
--- arch/x86/hyperv/hv_init.c | 2 +- arch/x86/include/asm/hypervisor.h | 23 ++++++++++++++--------- arch/x86/kernel/cpu/hypervisor.c | 12 +++++++++--- arch/x86/kernel/cpu/mshyperv.c | 4 ++-- arch/x86/kernel/cpu/vmware.c | 4 ++-- arch/x86/kernel/kvm.c | 4 ++-- arch/x86/xen/enlighten_hvm.c | 4 ++-- arch/x86/xen/enlighten_pv.c | 4 ++-- drivers/hv/vmbus_drv.c | 2 +- drivers/input/mouse/vmmouse.c | 10 ++++------ drivers/misc/vmw_balloon.c | 2 +- 11 files changed, 40 insertions(+), 31 deletions(-)
arch/x86/hyperv/hv_init.c +1 -1
@@ -113,7 +113,7 @@ void hyperv_init(void)u64 guest_id;union hv_x64_msr_hypercall_contents hypercall_msr; -if (x86_hyper != &x86_hyper_ms_hyperv) +if (x86_hyper_type !=X86_HYPER_MS_HYPERV )return ;/* Allocate percpu VP index */
arch/x86/include/asm/hypervisor.h +14 -9
@@ -29,6 +29,16 @@/* * x86 hypervisor information */ + +enum x86_hypervisor_type { +X86_HYPER_NATIVE =0 , +X86_HYPER_VMWARE , +X86_HYPER_MS_HYPERV , +X86_HYPER_XEN_PV , +X86_HYPER_XEN_HVM , +X86_HYPER_KVM , +}; +struct hypervisor_x86 {/* Hypervisor name */ const char *name;
@@ -36,6 +46,9 @@ struct hypervisor_x86 {/* Detection routine */ uint32_t (*detect)(void ); +/* Hypervisor type */ +enum x86_hypervisor_type type; +/* init time callbacks */ struct x86_hyper_init init;
@@ -43,15 +56,7 @@ struct hypervisor_x86 { struct x86_hyper_runtime runtime; }; -extern const struct hypervisor_x86 *x86_hyper; - -/* Recognized hypervisors */ -extern const struct hypervisor_x86 x86_hyper_vmware; -extern const struct hypervisor_x86 x86_hyper_ms_hyperv; -extern const struct hypervisor_x86 x86_hyper_xen_pv; -extern const struct hypervisor_x86 x86_hyper_xen_hvm; -extern const struct hypervisor_x86 x86_hyper_kvm; - +extern enum x86_hypervisor_type x86_hyper_type;extern void init_hypervisor_platform (void );#else static inline void init_hypervisor_platform (void ) { }
arch/x86/kernel/cpu/hypervisor.c +9 -3
@@ -26,6 +26,12 @@#include <asm/processor.h> #include <asm/hypervisor.h> +extern const struct hypervisor_x86 x86_hyper_vmware; +extern const struct hypervisor_x86 x86_hyper_ms_hyperv; +extern const struct hypervisor_x86 x86_hyper_xen_pv; +extern const struct hypervisor_x86 x86_hyper_xen_hvm; +extern const struct hypervisor_x86 x86_hyper_kvm; +static const __initconst struct hypervisor_x86 *const hypervisors[] = { #ifdef CONFIG_XEN_PV
@@ -41,8 +47,8 @@ static const __initconst struct hypervis#endif }; -const struct hypervisor_x86 *x86_hyper; -EXPORT_SYMBOL (x86_hyper); +enum x86_hypervisor_type x86_hyper_type; +EXPORT_SYMBOL (x86_hyper_type);static inline const struct hypervisor_x86 *__init detect_hypervisor_vendor (void )
@@ -87,6 +93,6 @@ void __init init_hypervisor_platform(voicopy_array (&h->init, &x86_init.hyper,sizeof (h->init));copy_array (&h->runtime, &x86_platform.hyper,sizeof (h->runtime)); - x86_hyper = h; + x86_hyper_type = h->type; x86_init.hyper.init_platform (); }
arch/x86/kernel/cpu/mshyperv.c +2 -2
@@ -254,9 +254,9 @@ static void __init ms_hyperv_init_platfo#endif } -const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = { +const __initconst struct hypervisor_x86 x86_hyper_ms_hyperv = { .name ="Microsoft Hyper-V" , .detect = ms_hyperv_platform, + .type =X86_HYPER_MS_HYPERV , .init.init_platform = ms_hyperv_init_platform, }; -EXPORT_SYMBOL (x86_hyper_ms_hyperv);
arch/x86/kernel/cpu/vmware.c +2 -2
@@ -205,10 +205,10 @@ static bool __init vmware_legacy_x2apic_ (eax & (1 <<VMWARE_PORT_CMD_LEGACY_X2APIC )) !=0 ; } -const __refconst struct hypervisor_x86 x86_hyper_vmware = { +const __initconst struct hypervisor_x86 x86_hyper_vmware = { .name ="VMware" , .detect = vmware_platform, + .type =X86_HYPER_VMWARE , .init.init_platform = vmware_platform_setup, .init.x2apic_available = vmware_legacy_x2apic_available, }; -EXPORT_SYMBOL (x86_hyper_vmware);
arch/x86/kernel/kvm.c +2 -2
@@ -544,12 +544,12 @@ static uint32_t __init kvm_detect(void)return kvm_cpuid_base (); } -const struct hypervisor_x86 x86_hyper_kvm__refconst = { +const __initconst struct hypervisor_x86 x86_hyper_kvm = { .name ="KVM" , .detect = kvm_detect, + .type =X86_HYPER_KVM , .init.x2apic_available = kvm_para_available, }; -EXPORT_SYMBOL_GPL (x86_hyper_kvm);static __init int activate_jump_labels (void ) {
arch/x86/xen/enlighten_hvm.c +2 -2
@@ -226,12 +226,12 @@ static uint32_t __init xen_platform_hvm(return xen_cpuid_base (); } -const struct hypervisor_x86 x86_hyper_xen_hvm = { +const __initconst struct hypervisor_x86 x86_hyper_xen_hvm = { .name ="Xen HVM" , .detect = xen_platform_hvm, + .type =X86_HYPER_XEN_HVM , .init.init_platform = xen_hvm_guest_init, .init.x2apic_available = xen_x2apic_para_available, .init.init_mem_mapping = xen_hvm_init_mem_mapping, .runtime.pin_vcpu = xen_pin_vcpu, }; -EXPORT_SYMBOL (x86_hyper_xen_hvm);
arch/x86/xen/enlighten_pv.c +2 -2
@@ -1459,9 +1459,9 @@ static uint32_t __init xen_platform_pv(vreturn 0 ; } -const struct hypervisor_x86 x86_hyper_xen_pv = { +const __initconst struct hypervisor_x86 x86_hyper_xen_pv = { .name ="Xen PV" , .detect = xen_platform_pv, + .type =X86_HYPER_XEN_PV , .runtime.pin_vcpu = xen_pin_vcpu, }; -EXPORT_SYMBOL (x86_hyper_xen_pv);
drivers/hv/vmbus_drv.c +1 -1
@@ -1534,7 +1534,7 @@ static int __init hv_acpi_init(void) {int ret, t; -if (x86_hyper != &x86_hyper_ms_hyperv) +if (x86_hyper_type !=X86_HYPER_MS_HYPERV )return -ENODEV ;init_completion (&probe_event);
drivers/input/mouse/vmmouse.c +4 -6
@@ -316,11 +316,9 @@ static int vmmouse_enable(struct psmouse/* * Array of supported hypervisors. */ -static const struct hypervisor_x86 *vmmouse_supported_hypervisors[] = { - &x86_hyper_vmware, -#ifdef CONFIG_KVM_GUEST - &x86_hyper_kvm, -#endif +static enum x86_hypervisor_type vmmouse_supported_hypervisors[] = { +X86_HYPER_VMWARE , +X86_HYPER_KVM , };/**
@@ -331,7 +329,7 @@ static bool vmmouse_check_hypervisor(voiint i;for (i =0 ; i <ARRAY_SIZE (vmmouse_supported_hypervisors); i++) -if (vmmouse_supported_hypervisors[i] == x86_hyper) +if (vmmouse_supported_hypervisors[i] == x86_hyper_type)return true;return false;
drivers/misc/vmw_balloon.c +1 -1
@@ -1271,7 +1271,7 @@ static int __init vmballoon_init(void)* Check if we are running on VMware's hypervisor and bail out * if we are not. */ -if (x86_hyper != &x86_hyper_vmware) +if (x86_hyper_type !=X86_HYPER_VMWARE )return -ENODEV ; for (is_2m_pages = 0; is_2m_pages < VMW_BALLOON_NUM_PAGE_SIZES;
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Greg Kroah-Hartman
maintainerPATCH 66/159 drivers/misc/intel/pti: Rename the header file to free up the namespace
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ingo Molnar <[email protected]>
commit 1784f9144b143a1e8b19fe94083b040aa559182b upstream.
We'd like to use the 'PTI' acronym for 'Page Table Isolation' - free up the namespace by renaming the <linux/pti.h> driver header to <linux/intel-pti.h>.
(Also standardize the header guard name while at it.)
--- drivers/misc/pti.c | 2 +- include/linux/intel-pti.h | 43 +++++++++++++++++++++++++++++++++++++++++++ include/linux/pti.h | 43 ------------------------------------------- 3 files changed, 44 insertions(+), 44 deletions(-)
drivers/misc/pti.c +1 -1
@@ -32,7 +32,7 @@#include <linux/pci.h> #include <linux/mutex.h> #include <linux/miscdevice.h> -#include <linux/pti.h> +#include <linux/intel-pti.h> #include <linux/slab.h> #include <linux/uaccess.h>
include/linux/intel-pti.h new file +43 -0
43 lines not on this page · raw message
include/linux/pti.h deleted +0 -43
43 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 67/159 x86/cpufeature: Add User-Mode Instruction Prevention definitions
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ricardo Neri <[email protected]>
commit a8b4db562e7283a1520f9e9730297ecaab7622ea upstream.
[ Note, this is a Git cherry-pick of the following commit: (limited to the cpufeatures.h file)
3522c2a6a4f3 ("x86/cpufeature: Add User-Mode Instruction Prevention definitions")
... for easier x86 PTI code testing and back-porting. ]
User-Mode Instruction Prevention is a security feature present in new Intel processors that, when set, prevents the execution of a subset of instructions if such instructions are executed in user mode (CPL > 0). Attempting to execute such instructions causes a general protection exception.
The subset of instructions comprises:
* SGDT - Store Global Descriptor Table
* SIDT - Store Interrupt Descriptor Table
* SLDT - Store Local Descriptor Table
* SMSW - Store Machine Status Word
* STR - Store Task Register
This feature is also added to the list of disabled-features to allow a cleaner handling of build-time configuration.
--- arch/x86/include/asm/cpufeatures.h | 1 + 1 file changed, 1 insertion(+)
arch/x86/include/asm/cpufeatures.h +1 -0
@@ -296,6 +296,7 @@/* Intel-defined CPU features, CPUID level 0x00000007:0 (ECX), word 16 */ #define X86_FEATURE_AVX512VBMI (16*32+ 1)/* AVX512 Vector Bit Manipulation instructions*/ +#define X86_FEATURE_UMIP (16*32+ 2)/* User Mode Instruction Protection */ #define X86_FEATURE_PKU (16*32+ 3)/* Protection Keys for Userspace */ #define X86_FEATURE_OSPKE (16*32+ 4)/* OS Protection Keys Enable */ #define X86_FEATURE_AVX512_VBMI2 (16*32+ 6)/* Additional AVX512 Vector Bit Manipulation Instructions */
Greg Kroah-Hartman
maintainerPATCH 68/159 x86: Make X86_BUG_FXSAVE_LEAK detectable in CPUID on AMD
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rudolf Marek <[email protected]>
commit f2dbad36c55e5d3a91dccbde6e8cae345fe5632f upstream.
[ Note, this is a Git cherry-pick of the following commit:
2b67799bdf25 ("x86: Make X86_BUG_FXSAVE_LEAK detectable in CPUID on AMD")... for easier x86 PTI code testing and back-porting. ]
The latest AMD AMD64 Architecture Programmer's Manual adds a CPUID feature XSaveErPtr (CPUID_Fn80000008_EBX[2]).
If this feature is set, the FXSAVE, XSAVE, FXSAVEOPT, XSAVEC, XSAVES / FXRSTOR, XRSTOR, XRSTORS always save/restore error pointers, thus making the X86_BUG_FXSAVE_LEAK workaround obsolete on such CPUs.
--- arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/kernel/cpu/amd.c | 7 +++++-- 2 files changed, 6 insertions(+), 2 deletions(-)
arch/x86/include/asm/cpufeatures.h +1 -0
@@ -266,6 +266,7 @@/* AMD-defined CPU features, CPUID level 0x80000008 (EBX), word 13 */ #define X86_FEATURE_CLZERO (13*32+ 0)/* CLZERO instruction */ #define X86_FEATURE_IRPERF (13*32+ 1)/* Instructions Retired Count */ +#define X86_FEATURE_XSAVEERPTR (13*32+ 2)/* Always save/restore FP error pointers */ /* Thermal and Power Management Leaf, CPUID level 0x00000006 (EAX), word 14 */ #define X86_FEATURE_DTHERM (14*32+ 0)/* Digital Thermal Sensor */
arch/x86/kernel/cpu/amd.c +5 -2
@@ -804,8 +804,11 @@ static void init_amd(struct cpuinfo_x86case 0x17 :init_amd_zn (c);break ; } -/* Enable workaround for FXSAVE leak */ -if (c->x86 >=6 ) +/* +* Enable workaround for FXSAVE leak on CPUs +* without a XSaveErPtr feature +*/ +if ((c->x86 >=6 ) && (!cpu_has (c,X86_FEATURE_XSAVEERPTR )))set_cpu_bug (c,X86_BUG_FXSAVE_LEAK );cpu_detect_cache_sizes (c);
Greg Kroah-Hartman
maintainerPATCH 69/159 perf/x86: Enable free running PEBS for REGS_USER/INTR
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andi Kleen <[email protected]>
commit 2fe1bc1f501d55e5925b4035bcd85781adc76c63 upstream.
[ Note, this is a Git cherry-pick of the following commit:
a47ba4d77e12 ("perf/x86: Enable free running PEBS for REGS_USER/INTR")
... for easier x86 PTI code testing and back-porting. ]
Currently free running PEBS is disabled when user or interrupt registers are requested. Most of the registers are actually available in the PEBS record and can be supported.
So we just need to check for the supported registers and then allow it: it is all except for the segment register.
For user registers this only works when the counter is limited to ring 3 only, so this also needs to be checked.
--- arch/x86/events/intel/core.c | 4 ++++ arch/x86/events/perf_event.h | 24 +++++++++++++++++++++++- 2 files changed, 27 insertions(+), 1 deletion(-)
arch/x86/events/intel/core.c +4 -0
@@ -2958,6 +2958,10 @@ static unsigned long intel_pmu_free_runnif (event->attr.use_clockid) flags &= ~PERF_SAMPLE_TIME ; +if (!event->attr.exclude_kernel) + flags &= ~PERF_SAMPLE_REGS_USER ; +if (event->attr.sample_regs_user & ~PEBS_REGS ) + flags &= ~(PERF_SAMPLE_REGS_USER |PERF_SAMPLE_REGS_INTR );return flags; }
arch/x86/events/perf_event.h +23 -1
@@ -85,13 +85,15 @@ struct amd_nb {* Flags PEBS can handle without an PMI. * * TID can only be handled by flushing at context switch. +* REGS_USER can be handled for events limited to ring 3. * */ #define PEBS_FREERUNNING_FLAGS \ (PERF_SAMPLE_IP | PERF_SAMPLE_TID | PERF_SAMPLE_ADDR | \ PERF_SAMPLE_ID | PERF_SAMPLE_CPU | PERF_SAMPLE_STREAM_ID | \ PERF_SAMPLE_DATA_SRC | PERF_SAMPLE_IDENTIFIER | \ - PERF_SAMPLE_TRANSACTION | PERF_SAMPLE_PHYS_ADDR) + PERF_SAMPLE_TRANSACTION | PERF_SAMPLE_PHYS_ADDR | \ + PERF_SAMPLE_REGS_INTR | PERF_SAMPLE_REGS_USER)/* * A debug store configuration.
@@ -110,6 +112,26 @@ struct debug_store {u64 pebs_event_reset[MAX_PEBS_EVENTS ]; }; +#define PEBS_REGS \ + (PERF_REG_X86_AX | \ + PERF_REG_X86_BX | \ + PERF_REG_X86_CX | \ + PERF_REG_X86_DX | \ + PERF_REG_X86_DI | \ + PERF_REG_X86_SI | \ + PERF_REG_X86_SP | \ + PERF_REG_X86_BP | \ + PERF_REG_X86_IP | \ + PERF_REG_X86_FLAGS | \ + PERF_REG_X86_R8 | \ + PERF_REG_X86_R9 | \ + PERF_REG_X86_R10 | \ + PERF_REG_X86_R11 | \ + PERF_REG_X86_R12 | \ + PERF_REG_X86_R13 | \ + PERF_REG_X86_R14 | \ + PERF_REG_X86_R15) +/* * Per register state. */
Greg Kroah-Hartman
maintainerPATCH 70/159 bpf: fix build issues on um due to mising bpf_perf_event.h
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Borkmann <[email protected]>
commit ab95477e7cb35557ecfc837687007b646bab9a9f upstream.
[ Note, this is a Git cherry-pick of the following commit:
a23f06f06dbe ("bpf: fix build issues on um due to mising bpf_perf_event.h")
... for easier x86 PTI code testing and back-porting. ]
Since c895f6f703ad ("bpf: correct broken uapi for BPF_PROG_TYPE_PERF_EVENT program type") um (uml) won't build on i386 or x86_64:
[...]
CC init/main.o
In file included from ../include/linux/perf_event.h:18:0,
from ../include/linux/trace_events.h:10,
from ../include/trace/syscall.h:7,
from ../include/linux/syscalls.h:82,
from ../init/main.c:20: ../include/uapi/linux/bpf_perf_event.h:11:32: fatal error:
asm/bpf_perf_event.h: No such file or directory #include <asm/bpf_perf_event.h>
[...]
Lets add missing bpf_perf_event.h also to um arch. This seems to be the only one still missing.
--- arch/um/include/asm/Kbuild | 1 + 1 file changed, 1 insertion(+)
arch/um/include/asm/Kbuild +1 -0
@@ -1,4 +1,5 @@ generic-y += barrier.h +generic-y += bpf_perf_event.h generic-y += bug.h generic-y += clkdev.h generic-y += current.h
Greg Kroah-Hartman
maintainerPATCH 71/159 locking/barriers: Add implicit smp_read_barrier_depends() to READ_ONCE()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Will Deacon <[email protected]>
commit c2bc66082e1048c7573d72e62f597bdc5ce13fea upstream.
[ Note, this is a Git cherry-pick of the following commit:
76ebbe78f739 ("locking/barriers: Add implicit smp_read_barrier_depends() to READ_ONCE()")
... for easier x86 PTI code testing and back-porting. ]
In preparation for the removal of lockless_dereference(), which is the same as READ_ONCE() on all architectures other than Alpha, add an implicit smp_read_barrier_depends() to READ_ONCE() so that it can be used to head dependency chains on all architectures.
--- include/linux/compiler.h | 1 + 1 file changed, 1 insertion(+)
include/linux/compiler.h +1 -0
@@ -341,6 +341,7 @@ static __always_inline void __write_once__read_once_size (&(x), __u.__c,sizeof (x)); \ else \ __read_once_size_nocheck(&(x), __u.__c, sizeof(x)); \ +smp_read_barrier_depends ();/* Enforce dependency ordering from x */ \ __u.__val; \ })#define READ_ONCE (x) __READ_ONCE(x, 1)
Greg Kroah-Hartman
maintainerPATCH 72/159 locking/barriers: Convert users of lockless_dereference() to READ_ONCE()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Will Deacon <[email protected]>
commit 3382290ed2d5e275429cef510ab21889d3ccd164 upstream.
[ Note, this is a Git cherry-pick of the following commit:
506458efaf15 ("locking/barriers: Convert users of lockless_dereference() to READ_ONCE()")
... for easier x86 PTI code testing and back-porting. ]
READ_ONCE() now has an implicit smp_read_barrier_depends() call, so it can be used instead of lockless_dereference() without any change in semantics.
--- arch/x86/events/core.c | 2 +- arch/x86/include/asm/mmu_context.h | 4 ++-- arch/x86/kernel/ldt.c | 2 +- drivers/md/dm-mpath.c | 20 ++++++++++---------- fs/dcache.c | 4 ++-- fs/overlayfs/ovl_entry.h | 2 +- fs/overlayfs/readdir.c | 2 +- include/linux/rculist.h | 4 ++-- include/linux/rcupdate.h | 4 ++-- kernel/events/core.c | 4 ++-- kernel/seccomp.c | 2 +- kernel/task_work.c | 2 +- mm/slab.h | 2 +- 13 files changed, 27 insertions(+), 27 deletions(-)
arch/x86/events/core.c +1 -1
@@ -2371,7 +2371,7 @@ static unsigned long get_segment_base(unstruct ldt_struct *ldt;/* IRQs are off, so this synchronizes with smp_store_release */ - ldt =lockless_dereference (current->active_mm->context.ldt); + ldt =READ_ONCE (current->active_mm->context.ldt);if (!ldt || idx >= ldt->nr_entries)return 0 ;
arch/x86/include/asm/mmu_context.h +2 -2
@@ -73,8 +73,8 @@ static inline void load_mm_ldt(struct mm#ifdef CONFIG_MODIFY_LDT_SYSCALL struct ldt_struct *ldt; -/* lockless_dereference synchronizes with smp_store_release */ - ldt =lockless_dereference (mm->context.ldt); +/* READ_ONCE synchronizes with smp_store_release */ + ldt =READ_ONCE (mm->context.ldt);/* * Any change to mm->context.ldt is followed by an IPI to all
arch/x86/kernel/ldt.c +1 -1
@@ -103,7 +103,7 @@ static void finalize_ldt_struct(struct lstatic void install_ldt (struct mm_struct *current_mm,struct ldt_struct *ldt) { -/* Synchronizes with lockless_dereference in load_mm_ldt. */ +/* Synchronizes with READ_ONCE in load_mm_ldt. */ smp_store_release (¤t_mm->context.ldt, ldt);/* Activate the LDT for all CPUs using current_mm. */
drivers/md/dm-mpath.c +10 -10
@@ -366,7 +366,7 @@ static struct pgpath *choose_path_in_pg( pgpath =path_to_pgpath (path); -if (unlikely (lockless_dereference (m->current_pg) != pg)) { +if (unlikely (READ_ONCE (m->current_pg) != pg)) {/* Only update current_pgpath if pg changed */ spin_lock_irqsave (&m->lock, flags); m->current_pgpath = pgpath;
@@ -390,7 +390,7 @@ static struct pgpath *choose_pgpath(stru }/* Were we instructed to switch PG? */ -if (lockless_dereference (m->next_pg)) { +if (READ_ONCE (m->next_pg)) {spin_lock_irqsave (&m->lock, flags); pg = m->next_pg;if (!pg) {
@@ -406,7 +406,7 @@ static struct pgpath *choose_pgpath(stru/* Don't change PG until it has no remaining paths */ check_current_pg: - pg =lockless_dereference (m->current_pg); + pg =READ_ONCE (m->current_pg);if (pg) { pgpath =choose_path_in_pg (m, pg, nr_bytes);if (!IS_ERR_OR_NULL (pgpath))
@@ -473,7 +473,7 @@ static int multipath_clone_and_map(strucstruct request *clone;/* Do we need to select a new pgpath? */ - pgpath =lockless_dereference (m->current_pgpath); + pgpath =READ_ONCE (m->current_pgpath);if (!pgpath || !test_bit (MPATHF_QUEUE_IO , &m->flags)) pgpath =choose_pgpath (m, nr_bytes);
@@ -533,7 +533,7 @@ static int __multipath_map_bio(struct mubool queue_io;/* Do we need to select a new pgpath? */ - pgpath =lockless_dereference (m->current_pgpath); + pgpath =READ_ONCE (m->current_pgpath); queue_io =test_bit (MPATHF_QUEUE_IO , &m->flags);if (!pgpath || !queue_io) pgpath =choose_pgpath (m, nr_bytes);
@@ -1802,7 +1802,7 @@ static int multipath_prepare_ioctl(strucstruct pgpath *current_pgpath;int r; - current_pgpath =lockless_dereference (m->current_pgpath); + current_pgpath =READ_ONCE (m->current_pgpath);if (!current_pgpath) current_pgpath =choose_pgpath (m,0 );
@@ -1824,7 +1824,7 @@ static int multipath_prepare_ioctl(struc }if (r == -ENOTCONN ) { -if (!lockless_dereference (m->current_pg)) { +if (!READ_ONCE (m->current_pg)) {/* Path status changed, redo selection */ (void )choose_pgpath (m,0 ); }
@@ -1893,9 +1893,9 @@ static int multipath_busy(struct dm_targreturn (m->queue_mode !=DM_TYPE_MQ_REQUEST_BASED );/* Guess which priority_group will be used at next mapping time */ - pg =lockless_dereference (m->current_pg); - next_pg =lockless_dereference (m->next_pg); -if (unlikely (!lockless_dereference (m->current_pgpath) && next_pg)) + pg =READ_ONCE (m->current_pg); + next_pg =READ_ONCE (m->next_pg); +if (unlikely (!READ_ONCE (m->current_pgpath) && next_pg)) pg = next_pg;if (!pg) {
fs/dcache.c +2 -2
@@ -231,7 +231,7 @@ static inline int dentry_cmp(const struc {/* * Be careful about RCU walk racing with rename: -* use 'lockless_dereference' to fetch the name pointer. +* use 'READ_ONCE' to fetch the name pointer. * * NOTE! Even if a rename will mean that the length * was not loaded atomically, we don't care. The
@@ -245,7 +245,7 @@ static inline int dentry_cmp(const struc* early because the data cannot match (there can * be no NUL in the ct/tcount data) */ -const unsigned char *cs =lockless_dereference (dentry->d_name.name); +const unsigned char *cs =READ_ONCE (dentry->d_name.name);return dentry_string_cmp (cs, ct, tcount); }
fs/overlayfs/ovl_entry.h +1 -1
@@ -77,5 +77,5 @@ static inline struct ovl_inode *OVL_I(ststatic inline struct dentry *ovl_upperdentry_dereference (struct ovl_inode *oi) { -return lockless_dereference (oi->__upperdentry); +return READ_ONCE (oi->__upperdentry); }
fs/overlayfs/readdir.c +1 -1
@@ -757,7 +757,7 @@ static int ovl_dir_fsync(struct file *fiif (!od->is_upper &&OVL_TYPE_UPPER (ovl_path_type (dentry))) {struct inode *inode =file_inode (file); - realfile =lockless_dereference (od->upperfile); + realfile =READ_ONCE (od->upperfile);if (!realfile) {struct path upperpath;
include/linux/rculist.h +2 -2
@@ -275,7 +275,7 @@ static inline void list_splice_tail_init* primitives such as list_add_rcu() as long as it's guarded by rcu_read_lock(). */ #define list_entry_rcu (ptr, type, member) \ - container_of(lockless_dereference(ptr), type, member) + container_of(READ_ONCE(ptr), type, member)/* * Where are list_empty_rcu() and list_first_entry_rcu()?
@@ -368,7 +368,7 @@ static inline void list_splice_tail_init* example is when items are added to the list, but never deleted. */ #define list_entry_lockless (ptr, type, member) \ - container_of((typeof(ptr))lockless_dereference(ptr), type, member) + container_of((typeof(ptr))READ_ONCE(ptr), type, member)/** * list_for_each_entry_lockless - iterate over rcu list of given type
include/linux/rcupdate.h +2 -2
@@ -346,7 +346,7 @@ static inline void rcu_preempt_sleep_che#define __rcu_dereference_check (p, c, space) \ ({ \/* Dependency order vs. p above. */ \ - typeof(*p) *________p1 = (typeof(*p) *__force)lockless_dereference(p); \ + typeof(*p) *________p1 = (typeof(*p) *__force)READ_ONCE(p); \RCU_LOCKDEP_WARN (!(c),"suspicious rcu_dereference_check() usage" ); \rcu_dereference_sparse (p, space); \ ((typeof(*p) __force __kernel *)(________p1)); \
@@ -360,7 +360,7 @@ static inline void rcu_preempt_sleep_che#define rcu_dereference_raw (p) \ ({ \/* Dependency order vs. p above. */ \ -typeof (p) ________p1 =lockless_dereference (p); \ +typeof (p) ________p1 =READ_ONCE (p); \ ((typeof(*p) __force __kernel *)(________p1)); \ })
kernel/events/core.c +2 -2
@@ -4233,7 +4233,7 @@ static void perf_remove_from_owner(struc* indeed free this event, otherwise we need to serialize on * owner->perf_event_mutex. */ - owner =lockless_dereference (event->owner); + owner =READ_ONCE (event->owner);if (owner) {/* * Since delayed_put_task_struct() also drops the last
@@ -4330,7 +4330,7 @@ again:* Cannot change, child events are not migrated, see the * comment with perf_event_ctx_lock_nested(). */ - ctx =lockless_dereference (child->ctx); + ctx =READ_ONCE (child->ctx);/* * Since child_mutex nests inside ctx::mutex, we must jump * through hoops. We start by grabbing a reference on the ctx.
kernel/seccomp.c +1 -1
@@ -190,7 +190,7 @@ static u32 seccomp_run_filters(const stru32 ret =SECCOMP_RET_ALLOW ;/* Make sure cross-thread synced filter points somewhere sane. */ struct seccomp_filter *f = -lockless_dereference (current->seccomp.filter); +READ_ONCE (current->seccomp.filter);/* Ensure unexpected behavior doesn't result in failing open. */ if (unlikely (WARN_ON (f ==NULL )))
kernel/task_work.c +1 -1
@@ -68,7 +68,7 @@ task_work_cancel(struct task_struct *tas* we raced with task_work_run(), *pprev == NULL/exited. */ raw_spin_lock_irqsave (&task->pi_lock, flags); -while ((work =lockless_dereference (*pprev))) { +while ((work =READ_ONCE (*pprev))) {if (work->func != func) pprev = &work->next;else if (cmpxchg (pprev, work, work->next) == work)
mm/slab.h +1 -1
@@ -259,7 +259,7 @@ cache_from_memcg_idx(struct kmem_cache ** memcg_caches issues a write barrier to match this (see * memcg_create_kmem_cache()). */ - cachep =lockless_dereference (arr->entries[idx]); + cachep =READ_ONCE (arr->entries[idx]);rcu_read_unlock ();return cachep;
Greg Kroah-Hartman
maintainerPATCH 73/159 x86/mm/kasan: Dont use vmemmap_populate() to initialize shadow
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrey Ryabinin <[email protected]>
commit 2aeb07365bcd489620f71390a7d2031cd4dfb83e upstream.
[ Note, this is a Git cherry-pick of the following commit:
d17a1d97dc20: ("x86/mm/kasan: don't use vmemmap_populate() to initialize shadow")... for easier x86 PTI code testing and back-porting. ]
The KASAN shadow is currently mapped using vmemmap_populate() since that provides a semi-convenient way to map pages into init_top_pgt. However, since that no longer zeroes the mapped pages, it is not suitable for KASAN, which requires zeroed shadow memory.
Add kasan_populate_shadow() interface and use it instead of vmemmap_populate(). Besides, this allows us to take advantage of gigantic pages and use them to populate the shadow, which should save us some memory wasted on page tables and reduce TLB pressure.
--- arch/x86/Kconfig | 2 arch/x86/mm/kasan_init_64.c | 143 +++++++++++++++++++++++++++++++++++++++++--- 2 files changed, 137 insertions(+), 8 deletions(-)
arch/x86/Kconfig +1 -1
@@ -108,7 +108,7 @@ config X86 select HAVE_ARCH_AUDITSYSCALL select HAVE_ARCH_HUGE_VMAP if X86_64 || X86_PAE select HAVE_ARCH_JUMP_LABEL - select HAVE_ARCH_KASAN if X86_64 && SPARSEMEM_VMEMMAP + select HAVE_ARCH_KASAN if X86_64 select HAVE_ARCH_KGDB select HAVE_ARCH_KMEMCHECK select HAVE_ARCH_MMAP_RND_BITS if MMU
arch/x86/mm/kasan_init_64.c +136 -7
178 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 74/159 x86/entry/64/paravirt: Use paravirt-safe macro to access eflags
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Boris Ostrovsky <[email protected]>
commit e17f8234538d1ff708673f287a42457c4dee720d upstream.
Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make them NMI-safe") added DEBUG_ENTRY_ASSERT_IRQS_OFF macro that acceses eflags using 'pushfq' instruction when testing for IF bit. On PV Xen guests looking at IF flag directly will always see it set, resulting in 'ud2'.
Introduce SAVE_FLAGS() macro that will use appropriate save_fl pv op when running paravirt.
--- arch/x86/entry/entry_64.S | 7 ++++--- arch/x86/include/asm/irqflags.h | 3 +++ arch/x86/include/asm/paravirt.h | 9 +++++++++ arch/x86/kernel/asm-offsets_64.c | 3 +++ 4 files changed, 19 insertions(+), 3 deletions(-)
arch/x86/entry/entry_64.S +4 -3
@@ -462,12 +462,13 @@ END(irq_entries_start) .macro DEBUG_ENTRY_ASSERT_IRQS_OFF #ifdef CONFIG_DEBUG_ENTRY - pushfq - testl $X86_EFLAGS_IF, (%rsp) + pushq %rax + SAVE_FLAGS(CLBR_RAX) + testl $X86_EFLAGS_IF, %eax jz .Lokay_\@ ud2 .Lokay_\@: - addq $8, %rsp + popq %rax #endif .endm
arch/x86/include/asm/irqflags.h +3 -0
@@ -142,6 +142,9 @@ static inline notrace unsigned long archswapgs ; \ sysretl +#ifdef CONFIG_DEBUG_ENTRY +#define SAVE_FLAGS (x) pushfq; popq %rax +#endif #else #define INTERRUPT_RETURN iret#define ENABLE_INTERRUPTS_SYSEXIT sti; sysexit
arch/x86/include/asm/paravirt.h +9 -0
@@ -927,6 +927,15 @@ extern void default_banner(void);PARA_SITE (PARA_PATCH (pv_cpu_ops, PV_CPU_usergs_sysret64), \CLBR_NONE , \ jmp PARA_INDIRECT(pv_cpu_ops+PV_CPU_usergs_sysret64)) + +#ifdef CONFIG_DEBUG_ENTRY +#define SAVE_FLAGS (clobbers) \ + PARA_SITE(PARA_PATCH(pv_irq_ops, PV_IRQ_save_fl), clobbers, \ + PV_SAVE_REGS(clobbers | CLBR_CALLEE_SAVE); \ + call PARA_INDIRECT(pv_irq_ops+PV_IRQ_save_fl); \ + PV_RESTORE_REGS(clobbers | CLBR_CALLEE_SAVE);) +#endif +#endif /* CONFIG_X86_32 */ #endif /* __ASSEMBLY__ */
arch/x86/kernel/asm-offsets_64.c +3 -0
@@ -23,6 +23,9 @@ int main(void)#ifdef CONFIG_PARAVIRT OFFSET (PV_CPU_usergs_sysret64, pv_cpu_ops, usergs_sysret64);OFFSET (PV_CPU_swapgs, pv_cpu_ops, swapgs); +#ifdef CONFIG_DEBUG_ENTRY +OFFSET (PV_IRQ_save_fl, pv_irq_ops, save_fl); +#endif BLANK ();#endif
Greg Kroah-Hartman
maintainerPATCH 75/159 x86/unwinder/orc: Dont bail on stack overflow
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit d3a09104018cf2ad5973dfa8a9c138ef9f5015a3 upstream.
If the stack overflows into a guard page and the ORC unwinder should work
well: by construction, there can't be any meaningful data in the guard page because no writes to the guard page will have succeeded.
But there is a bug that prevents unwinding from working correctly: if the starting register state has RSP pointing into a stack guard page, the ORC unwinder bails out immediately.
Instead of bailing out immediately check whether the next page up is a valid check page and if so analyze that. As a result the ORC unwinder will start the unwind.
Tested by intentionally overflowing the task stack. The result is an accurate call trace instead of a trace consisting purely of '?' entries.
There are a few other bugs that are triggered if the unwinder encounters a stack overflow after the first step, but they are outside the scope of this fix.
--- arch/x86/kernel/unwind_orc.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
arch/x86/kernel/unwind_orc.c +12 -2
@@ -553,8 +553,18 @@ void __unwind_start(struct unwind_state }if (get_stack_info ((unsigned long *)state->sp, state->task, - &state->stack_info, &state->stack_mask)) -return ; + &state->stack_info, &state->stack_mask)) { +/* +* We weren't on a valid stack. It's possible that +* we overflowed a valid stack into a guard page. +* See if the next page up is valid so that we can +* generate some kind of backtrace if this happens. +*/ +void *next_page = (void *)PAGE_ALIGN ((unsigned long )state->sp); +if (get_stack_info (next_page, state->task, &state->stack_info, + &state->stack_mask)) +return ; + }/* * The caller can provide the address of the first frame directly
Greg Kroah-Hartman
maintainerPATCH 76/159 x86/unwinder: Handle stack overflows more gracefully
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josh Poimboeuf <[email protected]>
commit b02fcf9ba1211097754b286043cd87a8b4907e75 upstream.
There are at least two unwinder bugs hindering the debugging of stack-overflow crashes:
- It doesn't deal gracefully with the case where the stack overflows and the stack pointer itself isn't on a valid stack but the to-be-dereferenced data *is*.
- The ORC oops dump code doesn't know how to print partial pt_regs, for the case where if we get an interrupt/exception in *early* entry code before the full pt_regs have been saved.
Fix both issues.
http://lkml.kernel.org/r/20171126024031.uxi4numpbjm5rlbr@treble
--- arch/x86/include/asm/kdebug.h | 1 arch/x86/include/asm/unwind.h | 7 +++ arch/x86/kernel/dumpstack.c | 32 ++++++++++++++--- arch/x86/kernel/process_64.c | 11 ++---- arch/x86/kernel/unwind_orc.c | 76 ++++++++++++++---------------------------- 5 files changed, 66 insertions(+), 61 deletions(-)
arch/x86/include/asm/kdebug.h +1 -0
@@ -26,6 +26,7 @@ extern void die(const char *, struct pt_extern int __must_check __die (const char *,struct pt_regs *,long );extern void show_stack_regs (struct pt_regs *regs);extern void __show_regs (struct pt_regs *regs,int all); +extern void show_iret_regs (struct pt_regs *regs);extern unsigned long oops_begin (void );extern void oops_end (unsigned long ,struct pt_regs *,int signr);
arch/x86/include/asm/unwind.h +7 -0
@@ -7,6 +7,9 @@#include <asm/ptrace.h> #include <asm/stacktrace.h> +#define IRET_FRAME_OFFSET (offsetof(struct pt_regs, ip)) +#define IRET_FRAME_SIZE (sizeof(struct pt_regs) - IRET_FRAME_OFFSET) +struct unwind_state {struct stack_info stack_info;unsigned long stack_mask;
@@ -52,6 +55,10 @@ void unwind_start(struct unwind_state *s }#if defined(CONFIG_UNWINDER_ORC ) || defined(CONFIG_UNWINDER_FRAME_POINTER ) +/* +* WARNING: The entire pt_regs may not be safe to dereference. In some cases, +* only the iret frame registers are accessible. Use with caution! +*/ static inline struct pt_regs *unwind_get_entry_regs (struct unwind_state *state) {if (unwind_done (state))
arch/x86/kernel/dumpstack.c +27 -5
@@ -50,6 +50,28 @@ static void printk_stack_address(unsigneprintk ("%s %s%pB\n" , log_lvl, reliable ?"" :"? " , (void *)address); } +void show_iret_regs (struct pt_regs *regs) +{ +printk (KERN_DEFAULT "RIP: %04x:%pS\n" , (int )regs->cs, (void *)regs->ip); +printk (KERN_DEFAULT "RSP: %04x:%016lx EFLAGS: %08lx" , (int )regs->ss, + regs->sp, regs->flags); +} + +static void show_regs_safe (struct stack_info *info,struct pt_regs *regs) +{ +if (on_stack (info, regs,sizeof (*regs))) +__show_regs (regs,0 ); +else if (on_stack (info, (void *)regs +IRET_FRAME_OFFSET , +IRET_FRAME_SIZE )) { +/* +* When an interrupt or exception occurs in entry code, the +* full pt_regs might not have been saved yet. In that case +* just print the iret frame. +*/ +show_iret_regs (regs); + } +} +void show_trace_log_lvl (struct task_struct *task,struct pt_regs *regs,unsigned long *stack,char *log_lvl) {
@@ -94,8 +116,8 @@ void show_trace_log_lvl(struct task_struif (stack_name)printk ("%s <%s>\n" , log_lvl, stack_name); -if (regs &&on_stack (&stack_info, regs,sizeof (*regs))) -__show_regs (regs,0 ); +if (regs) +show_regs_safe (&stack_info, regs);/* * Scan the stack, printing any text addresses we find. At the
@@ -119,7 +141,7 @@ void show_trace_log_lvl(struct task_stru/* * Don't print regs->ip again if it was already printed -* by __show_regs() below. +* by show_regs_safe() below. */ if (regs && stack == ®s->ip) goto next;
@@ -155,8 +177,8 @@ next:/* if the frame has entry regs, print them */ regs =unwind_get_entry_regs (&state); -if (regs &&on_stack (&stack_info, regs,sizeof (*regs))) -__show_regs (regs,0 ); +if (regs) +show_regs_safe (&stack_info, regs); }if (stack_name)
arch/x86/kernel/process_64.c +5 -6
@@ -69,9 +69,8 @@ void __show_regs(struct pt_regs *regs, iunsigned int fsindex, gsindex;unsigned int ds, cs, es; -printk (KERN_DEFAULT "RIP: %04lx:%pS\n" , regs->cs, (void *)regs->ip); -printk (KERN_DEFAULT "RSP: %04lx:%016lx EFLAGS: %08lx" , regs->ss, - regs->sp, regs->flags); +show_iret_regs (regs); +if (regs->orig_ax !=-1 )pr_cont (" ORIG_RAX: %016lx\n" , regs->orig_ax);else
@@ -88,6 +87,9 @@ void __show_regs(struct pt_regs *regs, iprintk (KERN_DEFAULT "R13: %016lx R14: %016lx R15: %016lx\n" , regs->r13, regs->r14, regs->r15); +if (!all) +return ; + asm("movl %%ds,%0" :"=r" (ds)); asm("movl %%cs,%0" :"=r" (cs)); asm("movl %%es,%0" :"=r" (es));
@@ -98,9 +100,6 @@ void __show_regs(struct pt_regs *regs, irdmsrl (MSR_GS_BASE , gs);rdmsrl (MSR_KERNEL_GS_BASE , shadowgs); -if (!all) -return ; - cr0 =read_cr0 (); cr2 =read_cr2 (); cr3 =__read_cr3 ();
arch/x86/kernel/unwind_orc.c +26 -50
124 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 77/159 x86/irq: Remove an old outdated comment about context tracking races
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit 6669a692605547892a026445e460bf233958bd7f upstream.
That race has been fixed and code cleaned up for a while now.
--- arch/x86/kernel/irq.c | 12 ------------ 1 file changed, 12 deletions(-)
arch/x86/kernel/irq.c +0 -12
@@ -219,18 +219,6 @@ __visible unsigned int __irq_entry do_IR/* high bit used in ret_from_ code */ unsigned vector = ~regs->orig_ax; -/* -* NB: Unlike exception entries, IRQ entries do not reliably -* handle context tracking in the low-level entry code. This is -* because syscall entries execute briefly with IRQs on before -* updating context tracking state, so we can take an IRQ from -* kernel mode with CONTEXT_USER. The low-level entry code only -* updates the context if we came from user mode, so we won't -* switch to CONTEXT_KERNEL. We'll fix that once the syscall -* code is cleaned up enough that we can cleanly defer enabling -* IRQs. -*/ -entering_irq ();/* entering_irq() tells RCU that we're not quiescent. Check it. */
Greg Kroah-Hartman
maintainerPATCH 78/159 x86/irq/64: Print the offending IP in the stack overflow warning
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit 4f3789e792296e21405f708cf3cb409d7c7d5683 upstream.
In case something goes wrong with unwind (not unlikely in case of overflow), print the offending IP where we detected the overflow.
--- arch/x86/kernel/irq_64.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/kernel/irq_64.c +2 -2
@@ -57,10 +57,10 @@ static inline void stack_overflow_check(if (regs->sp >= estack_top && regs->sp <= estack_bottom)return ; -WARN_ONCE (1 ,"do_IRQ(): %s has overflown the kernel stack (cur:%Lx,sp:%lx,irq stk top-bottom:%Lx-%Lx,exception stk top-bottom:%Lx-%Lx)\n" , +WARN_ONCE (1 ,"do_IRQ(): %s has overflown the kernel stack (cur:%Lx,sp:%lx,irq stk top-bottom:%Lx-%Lx,exception stk top-bottom:%Lx-%Lx,ip:%pF)\n" , current->comm, curbase, regs->sp, irq_stack_top, irq_stack_bottom, - estack_top, estack_bottom); + estack_top, estack_bottom, (void *)regs->ip);if (sysctl_panic_on_stackoverflow)panic ("low stack detected by irq handler - check messages\n" );
Greg Kroah-Hartman
maintainerPATCH 79/159 x86/entry/64: Allocate and enable the SYSENTER stack
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit 1a79797b58cddfa948420a7553241c79c013e3ca upstream.
This will simplify future changes that want scratch variables early in the SYSENTER handler -- they'll be able to spill registers to the stack. It also lets us get rid of a SWAPGS_UNSAFE_STACK user.
This does not depend on CONFIG_IA32_EMULATION=y because we'll want the stack space even without IA32 emulation.
As far as I can tell, the reason that this wasn't done from day 1 is that we use IST for #DB and #BP, which is IMO rather nasty and causes a lot more problems than it solves. But, since #DB uses IST, we don't actually need a real stack for SYSENTER (because SYSENTER with TF set will invoke #DB on the IST stack rather than the SYSENTER stack).
I want to remove IST usage from these vectors some day, and this patch is a prerequisite for that as well.
--- arch/x86/entry/entry_64_compat.S | 2 +- arch/x86/include/asm/processor.h | 3 --- arch/x86/kernel/asm-offsets.c | 5 +++++ arch/x86/kernel/asm-offsets_32.c | 5 ----- arch/x86/kernel/cpu/common.c | 4 +++- arch/x86/kernel/process.c | 2 -- arch/x86/kernel/traps.c | 3 +-- 7 files changed, 10 insertions(+), 14 deletions(-)
arch/x86/entry/entry_64_compat.S +1 -1
@@ -48,7 +48,7 @@ */ ENTRY(entry_SYSENTER_compat) /* Interrupts are off on entry. */ - SWAPGS_UNSAFE_STACK + SWAPGS movq PER_CPU_VAR(cpu_current_top_of_stack), %rsp /*
arch/x86/include/asm/processor.h +0 -3
@@ -339,14 +339,11 @@ struct tss_struct {*/ unsigned long io_bitmap[IO_BITMAP_LONGS +1 ]; -#ifdef CONFIG_X86_32 /* * Space for the temporary SYSENTER stack. */ unsigned long SYSENTER_stack_canary;unsigned long SYSENTER_stack[64 ]; -#endif - }____cacheline_aligned ; DECLARE_PER_CPU_SHARED_ALIGNED(struct tss_struct, cpu_tss);
arch/x86/kernel/asm-offsets.c +5 -0
@@ -93,4 +93,9 @@ void common(void) {BLANK ();DEFINE (PTREGS_SIZE ,sizeof (struct pt_regs )); + +/* Offset from cpu_tss to SYSENTER_stack */ +OFFSET (CPU_TSS_SYSENTER_stack, tss_struct, SYSENTER_stack); +/* Size of SYSENTER_stack */ +DEFINE (SIZEOF_SYSENTER_stack,sizeof (((struct tss_struct *)0 )->SYSENTER_stack)); }
arch/x86/kernel/asm-offsets_32.c +0 -5
@@ -50,11 +50,6 @@ void foo(void) DEFINE(TSS_sysenter_sp0, offsetof(struct tss_struct, x86_tss.sp0) - offsetofend(struct tss_struct, SYSENTER_stack)); -/* Offset from cpu_tss to SYSENTER_stack */ -OFFSET (CPU_TSS_SYSENTER_stack, tss_struct, SYSENTER_stack); -/* Size of SYSENTER_stack */ -DEFINE (SIZEOF_SYSENTER_stack,sizeof (((struct tss_struct *)0 )->SYSENTER_stack)); -#ifdef CONFIG_CC_STACKPROTECTOR BLANK ();OFFSET (stack_canary_offset, stack_canary, canary);
arch/x86/kernel/cpu/common.c +3 -1
@@ -1361,7 +1361,9 @@ void syscall_init(void)* AMD doesn't allow SYSENTER in long mode (either 32- or 64-bit). */ wrmsrl_safe (MSR_IA32_SYSENTER_CS , (u64 )__KERNEL_CS); -wrmsrl_safe (MSR_IA32_SYSENTER_ESP ,0ULL ); +wrmsrl_safe (MSR_IA32_SYSENTER_ESP , + (unsigned long )this_cpu_ptr (&cpu_tss) + + offsetofend(struct tss_struct, SYSENTER_stack));wrmsrl_safe (MSR_IA32_SYSENTER_EIP , (u64 )entry_SYSENTER_compat);#else wrmsrl (MSR_CSTAR , (unsigned long )ignore_sysret);
arch/x86/kernel/process.c +0 -2
@@ -71,9 +71,7 @@ __visible DEFINE_PER_CPU_SHARED_ALIGNED(*/ .io_bitmap = { [0 ... IO_BITMAP_LONGS] = ~0 }, #endif -#ifdef CONFIG_X86_32 .SYSENTER_stack_canary =STACK_END_MAGIC , -#endif };EXPORT_PER_CPU_SYMBOL (cpu_tss);
arch/x86/kernel/traps.c +1 -2
@@ -794,14 +794,13 @@ dotraplinkage void do_debug(struct pt_redebug_stack_usage_dec (); exit: -#if defined(CONFIG_X86_32 )/* * This is the most likely code path that involves non-trivial use * of the SYSENTER stack. Check that we haven't overrun it. */ WARN (this_cpu_read (cpu_tss.SYSENTER_stack_canary) !=STACK_END_MAGIC ,"Overran or corrupted SYSENTER stack\n" ); -#endif +ist_exit (regs); }NOKPROBE_SYMBOL (do_debug);
Greg Kroah-Hartman
maintainerPATCH 80/159 x86/dumpstack: Add get_stack_info() support for the SYSENTER stack
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit 33a2f1a6c4d7c0a02d1c006fb0379cc5ca3b96bb upstream.
get_stack_info() doesn't currently know about the SYSENTER stack, so unwinding will fail if we entered the kernel on the SYSENTER stack and haven't fully switched off. Teach get_stack_info() about the SYSENTER stack.
With future patches applied that run part of the entry code on the SYSENTER stack and introduce an intentional BUG(), I would get:
PANIC: double fault, error_code: 0x0
...
RIP: 0010:do_error_trap+0x33/0x1c0 ... Call Trace: Code: ...
With this patch, I get:
PANIC: double fault, error_code: 0x0
...
Call Trace: <SYSENTER> ? async_page_fault+0x36/0x60 ? invalid_op+0x22/0x40 ? async_page_fault+0x36/0x60 ? sync_regs+0x3c/0x40 ? sync_regs+0x2e/0x40 ? error_entry+0x6c/0xd0 ? async_page_fault+0x36/0x60 </SYSENTER> Code: ...
which is a lot more informative.
arch/x86/include/asm/stacktrace.h +3 -0
@@ -16,6 +16,7 @@ enum stack_type {STACK_TYPE_TASK ,STACK_TYPE_IRQ ,STACK_TYPE_SOFTIRQ , +STACK_TYPE_SYSENTER ,STACK_TYPE_EXCEPTION , STACK_TYPE_EXCEPTION_LAST = STACK_TYPE_EXCEPTION + N_EXCEPTION_STACKS-1, };
@@ -28,6 +29,8 @@ struct stack_info {bool in_task_stack (unsigned long *stack,struct task_struct *task,struct stack_info *info); +bool in_sysenter_stack (unsigned long *stack,struct stack_info *info); +int get_stack_info (unsigned long *stack,struct task_struct *task,struct stack_info *info,unsigned long *visit_mask);
arch/x86/kernel/dumpstack.c +19 -0
@@ -43,6 +43,25 @@ bool in_task_stack(unsigned long *stack, struct task_struct *task,return true; } +bool in_sysenter_stack (unsigned long *stack,struct stack_info *info) +{ +struct tss_struct *tss =this_cpu_ptr (&cpu_tss); + +/* Treat the canary as part of the stack for unwinding purposes. */ +void *begin = &tss->SYSENTER_stack_canary; +void *end = (void *)&tss->SYSENTER_stack +sizeof (tss->SYSENTER_stack); + +if ((void *)stack < begin || (void *)stack >= end) +return false; + + info->type =STACK_TYPE_SYSENTER ; + info->begin = begin; + info->end = end; + info->next_sp =NULL ; + +return true; +} +static void printk_stack_address (unsigned long address,int reliable,char *log_lvl) {
arch/x86/kernel/dumpstack_32.c +6 -0
@@ -26,6 +26,9 @@ const char *stack_type_name(enum stack_type type)if (type ==STACK_TYPE_SOFTIRQ )return "SOFTIRQ" ; +if (type ==STACK_TYPE_SYSENTER ) +return "SYSENTER" ; +return NULL ; }
@@ -93,6 +96,9 @@ int get_stack_info(unsigned long *stack, struct task_struct *task,if (task != current) goto unknown; +if (in_sysenter_stack (stack, info)) + goto recursion_check; +if (in_hardirq_stack (stack, info)) goto recursion_check;
arch/x86/kernel/dumpstack_64.c +6 -0
@@ -37,6 +37,9 @@ const char *stack_type_name(enum stack_type type)if (type ==STACK_TYPE_IRQ )return "IRQ" ; +if (type ==STACK_TYPE_SYSENTER ) +return "SYSENTER" ; +if (type >=STACK_TYPE_EXCEPTION && type <=STACK_TYPE_EXCEPTION_LAST )return exception_stack_names[type -STACK_TYPE_EXCEPTION ];
@@ -115,6 +118,9 @@ int get_stack_info(unsigned long *stack, struct task_struct *task,if (in_irq_stack (stack, info)) goto recursion_check; +if (in_sysenter_stack (stack, info)) + goto recursion_check; + goto unknown; recursion_check:
Greg Kroah-Hartman
maintainerPATCH 81/159 x86/entry/gdt: Put per-CPU GDT remaps in ascending order
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit aaeed3aeb39c1ba69f0a49baec8cb728121d0a91 upstream.
We currently have CPU 0's GDT at the top of the GDT range and higher-numbered CPUs at lower addresses. This happens because the fixmap is upside down (index 0 is the top of the fixmap).
Flip it so that GDTs are in ascending order by virtual address. This will simplify a future patch that will generalize the GDT remap to contain multiple pages.
--- arch/x86/include/asm/desc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/include/asm/desc.h +1 -1
@@ -63,7 +63,7 @@ static inline struct desc_struct *get_cu/* Get the fixmap index for a specific processor */ static inline unsigned int get_cpu_gdt_ro_index (int cpu) { -return FIX_GDT_REMAP_BEGIN + cpu; +return FIX_GDT_REMAP_END - cpu; }/* Provide the fixmap address of the remapped GDT */
Greg Kroah-Hartman
maintainerPATCH 82/159 x86/mm/fixmap: Generalize the GDT fixmap mechanism, introduce struct cpu_entry_area
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit ef8813ab280507972bb57e4b1b502811ad4411e9 upstream.
Currently, the GDT is an ad-hoc array of pages, one per CPU, in the fixmap. Generalize it to be an array of a new 'struct cpu_entry_area' so that we can cleanly add new things to it.
--- arch/x86/include/asm/desc.h | 9 +-------- arch/x86/include/asm/fixmap.h | 37 +++++++++++++++++++++++++++++++++++-- arch/x86/kernel/cpu/common.c | 14 +++++++------- arch/x86/xen/mmu_pv.c | 2 +- 4 files changed, 44 insertions(+), 18 deletions(-)
arch/x86/include/asm/desc.h +1 -8
@@ -60,17 +60,10 @@ static inline struct desc_struct *get_cureturn this_cpu_ptr (&gdt_page)->gdt; } -/* Get the fixmap index for a specific processor */ -static inline unsigned int get_cpu_gdt_ro_index (int cpu) -{ -return FIX_GDT_REMAP_END - cpu; -} -/* Provide the fixmap address of the remapped GDT */ static inline struct desc_struct *get_cpu_gdt_ro (int cpu) { -unsigned int idx =get_cpu_gdt_ro_index (cpu); -return (struct desc_struct *)__fix_to_virt (idx); +return (struct desc_struct *)&get_cpu_entry_area (cpu)->gdt; }/* Provide the current read-only GDT */
arch/x86/include/asm/fixmap.h +35 -2
@@ -44,6 +44,19 @@ extern unsigned long __FIXADDR_TOP; PAGE_SIZE)#endif +/* +* cpu_entry_area is a percpu region in the fixmap that contains things +* needed by the CPU and early entry/exit code. Real types aren't used +* for all fields here to avoid circular header dependencies. +* +* Every field is a virtual alias of some other allocated backing store. +* There is no direct allocation of a struct cpu_entry_area. +*/ +struct cpu_entry_area { +char gdt[PAGE_SIZE ]; +}; + +#define CPU_ENTRY_AREA_PAGES (sizeof(struct cpu_entry_area) / PAGE_SIZE)/* * Here we define all the compile-time 'special' virtual
@@ -101,8 +114,8 @@ enum fixed_addresses {FIX_LNW_VRTC , #endif/* Fixmap entries to remap the GDTs, one per processor. */ -FIX_GDT_REMAP_BEGIN , -FIX_GDT_REMAP_END =FIX_GDT_REMAP_BEGIN +NR_CPUS -1 , +FIX_CPU_ENTRY_AREA_TOP , +FIX_CPU_ENTRY_AREA_BOTTOM =FIX_CPU_ENTRY_AREA_TOP + (CPU_ENTRY_AREA_PAGES *NR_CPUS ) -1 , #ifdef CONFIG_ACPI_APEI_GHES/* Used for GHES mapping from assorted contexts */
@@ -191,5 +204,25 @@ void __init *early_memremap_decrypted_wpvoid __early_set_fixmap (enum fixed_addresses idx,phys_addr_t phys,pgprot_t flags); +static inline unsigned int __get_cpu_entry_area_page_index (int cpu,int page) +{ +BUILD_BUG_ON (sizeof (struct cpu_entry_area ) %PAGE_SIZE !=0 ); + +return FIX_CPU_ENTRY_AREA_BOTTOM - cpu*CPU_ENTRY_AREA_PAGES - page; +} + +#define __get_cpu_entry_area_offset_index (cpu, offset) ({ \ + BUILD_BUG_ON(offset % PAGE_SIZE != 0); \ + __get_cpu_entry_area_page_index(cpu, offset / PAGE_SIZE); \ + }) + +#define get_cpu_entry_area_index (cpu, field) \ + __get_cpu_entry_area_offset_index((cpu), offsetof(struct cpu_entry_area, field)) + +static inline struct cpu_entry_area *get_cpu_entry_area (int cpu) +{ +return (struct cpu_entry_area *)__fix_to_virt (__get_cpu_entry_area_page_index (cpu,0 )); +} +#endif /* !__ASSEMBLY__ */ #endif /* _ASM_X86_FIXMAP_H */
arch/x86/kernel/cpu/common.c +7 -7
@@ -466,12 +466,12 @@ void load_percpu_segment(int cpu)load_stack_canary_segment (); } -/* Setup the fixmap mapping only once per-processor */ -static inline void setup_fixmap_gdt (int cpu) +/* Setup the fixmap mappings only once per-processor */ +static inline void setup_cpu_entry_area (int cpu) {#ifdef CONFIG_X86_64 /* On 64-bit systems, we use a read-only fixmap GDT. */ -pgprot_t prot =PAGE_KERNEL_RO ; +pgprot_t gdt_prot =PAGE_KERNEL_RO ;#else /* * On native 32-bit systems, the GDT cannot be read-only because
@@ -482,11 +482,11 @@ static inline void setup_fixmap_gdt(int* On Xen PV, the GDT must be read-only because the hypervisor requires * it. */ -pgprot_t prot =boot_cpu_has (X86_FEATURE_XENPV ) ? +pgprot_t gdt_prot =boot_cpu_has (X86_FEATURE_XENPV ) ?PAGE_KERNEL_RO :PAGE_KERNEL ;#endif -__set_fixmap (get_cpu_gdt_ro_index (cpu),get_cpu_gdt_paddr (cpu), prot); +__set_fixmap (get_cpu_entry_area_index (cpu, gdt),get_cpu_gdt_paddr (cpu), gdt_prot); }/* Load the original GDT from the per-cpu structure */
@@ -1589,7 +1589,7 @@ void cpu_init(void)if (is_uv_system ())uv_cpu_init (); -setup_fixmap_gdt (cpu); +setup_cpu_entry_area (cpu);load_fixmap_gdt (cpu); }
@@ -1651,7 +1651,7 @@ void cpu_init(void)fpu__init_cpu (); -setup_fixmap_gdt (cpu); +setup_cpu_entry_area (cpu); load_fixmap_gdt(cpu); }#endif
arch/x86/xen/mmu_pv.c +1 -1
@@ -2272,7 +2272,7 @@ static void xen_set_fixmap(unsigned idx,#endif case FIX_TEXT_POKE0 :case FIX_TEXT_POKE1 : - case FIX_GDT_REMAP_BEGIN ... FIX_GDT_REMAP_END: + case FIX_CPU_ENTRY_AREA_TOP ... FIX_CPU_ENTRY_AREA_BOTTOM:/* All local page mappings */ pte =pfn_pte (phys, prot);break ;
Greg Kroah-Hartman
maintainerPATCH 83/159 x86/kasan/64: Teach KASAN about the cpu_entry_area
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit 21506525fb8ddb0342f2a2370812d47f6a1f3833 upstream.
The cpu_entry_area will contain stacks. Make sure that KASAN has appropriate shadow mappings for them.
--- arch/x86/mm/kasan_init_64.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-)
arch/x86/mm/kasan_init_64.c +17 -1
@@ -277,6 +277,7 @@ void __init kasan_early_init(void)void __init kasan_init (void ) {int i; +void *shadow_cpu_entry_begin, *shadow_cpu_entry_end;#ifdef CONFIG_KASAN_INLINE register_die_notifier (&kasan_die_notifier);
@@ -329,8 +330,23 @@ void __init kasan_init(void) (unsigned long )kasan_mem_to_shadow (_end), early_pfn_to_nid(__pa(_stext))); + shadow_cpu_entry_begin = (void *)__fix_to_virt (FIX_CPU_ENTRY_AREA_BOTTOM ); + shadow_cpu_entry_begin =kasan_mem_to_shadow (shadow_cpu_entry_begin); + shadow_cpu_entry_begin = (void *)round_down ((unsigned long )shadow_cpu_entry_begin, +PAGE_SIZE ); + + shadow_cpu_entry_end = (void *)(__fix_to_virt (FIX_CPU_ENTRY_AREA_TOP ) +PAGE_SIZE ); + shadow_cpu_entry_end =kasan_mem_to_shadow (shadow_cpu_entry_end); + shadow_cpu_entry_end = (void *)round_up ((unsigned long )shadow_cpu_entry_end, +PAGE_SIZE ); +kasan_populate_zero_shadow (kasan_mem_to_shadow ((void *)MODULES_END ), - (void *)KASAN_SHADOW_END ); + shadow_cpu_entry_begin); + +kasan_populate_shadow ((unsigned long )shadow_cpu_entry_begin, + (unsigned long )shadow_cpu_entry_end,0 ); + +kasan_populate_zero_shadow (shadow_cpu_entry_end, (void *)KASAN_SHADOW_END );load_cr3 (init_top_pgt);__flush_tlb_all ();
Greg Kroah-Hartman
maintainerPATCH 84/159 x86/entry: Fix assumptions that the HW TSS is at the beginning of cpu_tss
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit 7fb983b4dd569e08564134a850dfd4eb1c63d9b8 upstream.
A future patch will move SYSENTER_stack to the beginning of cpu_tss to help detect overflow. Before this can happen, fix several code paths that hardcode assumptions about the old layout.
--- arch/x86/include/asm/desc.h | 2 +- arch/x86/include/asm/processor.h | 9 +++++++-- arch/x86/kernel/cpu/common.c | 8 ++++---- arch/x86/kernel/doublefault.c | 32 +++++++++++++++----------------- arch/x86/kvm/vmx.c | 2 +- arch/x86/power/cpu.c | 13 +++++++------ 6 files changed, 35 insertions(+), 31 deletions(-)
arch/x86/include/asm/desc.h +1 -1
@@ -178,7 +178,7 @@ static inline void set_tssldt_descriptor#endif } -static inline void __set_tss_desc (unsigned cpu,unsigned int entry,void *addr) +static inline void __set_tss_desc (unsigned cpu,unsigned int entry,struct x86_hw_tss *addr) {struct desc_struct *d =get_cpu_gdt_rw (cpu);tss_desc tss;
arch/x86/include/asm/processor.h +7 -2
@@ -162,7 +162,7 @@ enum cpuid_regs_idx {extern struct cpuinfo_x86 boot_cpu_data;extern struct cpuinfo_x86 new_cpu_data; -extern struct tss_struct doublefault_tss; +extern struct x86_hw_tss doublefault_tss;extern __u32 cpu_caps_cleared[NCAPINTS ];extern __u32 cpu_caps_set[NCAPINTS ];
@@ -252,6 +252,11 @@ static inline void load_cr3(pgd_t *pgdirwrite_cr3 (__sme_pa (pgdir)); } +/* +* Note that while the legacy 'TSS' name comes from 'Task State Segment', +* on modern x86 CPUs the TSS also holds information important to 64-bit mode, +* unrelated to the task-switch mechanism: +*/ #ifdef CONFIG_X86_32 /* This is the TSS defined by the hardware. */ struct x86_hw_tss {
@@ -322,7 +327,7 @@ struct x86_hw_tss {#define IO_BITMAP_BITS 65536#define IO_BITMAP_BYTES (IO_BITMAP_BITS/8)#define IO_BITMAP_LONGS (IO_BITMAP_BYTES/sizeof(long)) -#define IO_BITMAP_OFFSET offsetof(struct tss_struct, io_bitmap) +#define IO_BITMAP_OFFSET (offsetof(struct tss_struct, io_bitmap) - offsetof(struct tss_struct, x86_tss))#define INVALID_IO_BITMAP_OFFSET 0x8000struct tss_struct {
arch/x86/kernel/cpu/common.c +4 -4
@@ -1557,7 +1557,7 @@ void cpu_init(void) } } - t->x86_tss.io_bitmap_base = offsetof(struct tss_struct , io_bitmap); + t->x86_tss.io_bitmap_base =IO_BITMAP_OFFSET ;/* * <= is required because the CPU will access up to
@@ -1576,7 +1576,7 @@ void cpu_init(void)* Initialize the TSS. Don't bother initializing sp0, as the initial * task never enters user mode. */ -set_tss_desc (cpu, t); +set_tss_desc (cpu, &t->x86_tss);load_TR_desc ();load_mm_ldt (&init_mm);
@@ -1634,12 +1634,12 @@ void cpu_init(void)* Initialize the TSS. Don't bother initializing sp0, as the initial * task never enters user mode. */ -set_tss_desc (cpu, t); +set_tss_desc (cpu, &t->x86_tss);load_TR_desc ();load_mm_ldt (&init_mm); - t->x86_tss.io_bitmap_base = offsetof(struct tss_struct , io_bitmap); + t->x86_tss.io_bitmap_base =IO_BITMAP_OFFSET ;#ifdef CONFIG_DOUBLEFAULT /* Set up doublefault TSS pointer in the GDT */
arch/x86/kernel/doublefault.c +15 -17
@@ -50,25 +50,23 @@ static void doublefault_fn(void)cpu_relax (); } -struct tss_struct doublefault_tss __cacheline_aligned = { - .x86_tss = { - .sp0 =STACK_START , - .ss0 = __KERNEL_DS, - .ldt =0 , - .io_bitmap_base =INVALID_IO_BITMAP_OFFSET , +struct x86_hw_tss doublefault_tss __cacheline_aligned = { + .sp0 =STACK_START , + .ss0 = __KERNEL_DS, + .ldt =0 , + .io_bitmap_base =INVALID_IO_BITMAP_OFFSET , - .ip = (unsigned long ) doublefault_fn, -/* 0x2 bit is always set */ - .flags =X86_EFLAGS_SF |0x2 , - .sp =STACK_START , - .es = __USER_DS, - .cs = __KERNEL_CS, - .ss = __KERNEL_DS, - .ds = __USER_DS, - .fs = __KERNEL_PERCPU, + .ip = (unsigned long ) doublefault_fn, +/* 0x2 bit is always set */ + .flags =X86_EFLAGS_SF |0x2 , + .sp =STACK_START , + .es = __USER_DS, + .cs = __KERNEL_CS, + .ss = __KERNEL_DS, + .ds = __USER_DS, + .fs = __KERNEL_PERCPU, - .__cr3 =__pa_nodebug (swapper_pg_dir), - } + .__cr3 =__pa_nodebug (swapper_pg_dir), };/* dummy for do_double_fault() call */
arch/x86/kvm/vmx.c +1 -1
@@ -2295,7 +2295,7 @@ static void vmx_vcpu_load(struct kvm_vcp* processors. See 22.2.4. */ vmcs_writel (HOST_TR_BASE , - (unsigned long )this_cpu_ptr (&cpu_tss)); + (unsigned long )this_cpu_ptr (&cpu_tss.x86_tss));vmcs_writel (HOST_GDTR_BASE , (unsigned long )gdt);/* 22.2.4 */ /*
arch/x86/power/cpu.c +7 -6
@@ -165,12 +165,13 @@ static void fix_processor_context(void)struct desc_struct *desc =get_cpu_gdt_rw (cpu);tss_desc tss;#endif -set_tss_desc (cpu, t);/* -* This just modifies memory; should not be -* necessary. But... This is necessary, because -* 386 hardware has concept of busy TSS or some -* similar stupidity. -*/ + +/* +* This just modifies memory; should not be necessary. But... This is +* necessary, because 386 hardware has concept of busy TSS or some +* similar stupidity. +*/ +set_tss_desc (cpu, &t->x86_tss);#ifdef CONFIG_X86_64 memcpy (&tss, &desc[GDT_ENTRY_TSS ],sizeof (tss_desc));
Greg Kroah-Hartman
maintainerPATCH 85/159 x86/dumpstack: Handle stack overflow on all stacks
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit 6e60e583426c2f8751c22c2dfe5c207083b4483a upstream.
We currently special-case stack overflow on the task stack. We're going to start putting special stacks in the fixmap with a custom layout, so they'll have guard pages, too. Teach the unwinder to be able to unwind an overflow of any of the stacks.
--- arch/x86/kernel/dumpstack.c | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-)
arch/x86/kernel/dumpstack.c +14 -10
@@ -112,24 +112,28 @@ void show_trace_log_lvl(struct task_stru* - task stack * - interrupt stack * - HW exception stacks (double fault, nmi, debug, mce) +* - SYSENTER stack * -* x86-32 can have up to three stacks: +* x86-32 can have up to four stacks: * - task stack * - softirq stack * - hardirq stack +* - SYSENTER stack */ for (regs =NULL ; stack; stack =PTR_ALIGN (stack_info.next_sp,sizeof (long ))) {const char *stack_name; -/* -* If we overflowed the task stack into a guard page, jump back -* to the bottom of the usable stack. -*/ -if (task_stack_page (task) - (void *)stack <PAGE_SIZE ) - stack =task_stack_page (task); - -if (get_stack_info (stack, task, &stack_info, &visit_mask)) -break ; +if (get_stack_info (stack, task, &stack_info, &visit_mask)) { +/* +* We weren't on a valid stack. It's possible that +* we overflowed a valid stack into a guard page. +* See if the next page up is valid so that we can +* generate some kind of backtrace if this happens. +*/ + stack = (unsigned long *)PAGE_ALIGN ((unsigned long )stack); +if (get_stack_info (stack, task, &stack_info, &visit_mask)) +break ; + } stack_name =stack_type_name (stack_info.type);if (stack_name)
Greg Kroah-Hartman
maintainerPATCH 86/159 x86/entry: Move SYSENTER_stack to the beginning of struct tss_struct
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit 1a935bc3d4ea61556461a9e92a68ca3556232efd upstream.
SYSENTER_stack should have reliable overflow detection, which means that it needs to be at the bottom of a page, not the top. Move it to the beginning of struct tss_struct and page-align it.
Also add an assertion to make sure that the fixed hardware TSS doesn't cross a page boundary.
--- arch/x86/include/asm/processor.h | 21 ++++++++++++--------- arch/x86/kernel/cpu/common.c | 21 +++++++++++++++++++++ 2 files changed, 33 insertions(+), 9 deletions(-)
arch/x86/include/asm/processor.h +12 -9
@@ -332,7 +332,16 @@ struct x86_hw_tss {struct tss_struct {/* -* The hardware state: +* Space for the temporary SYSENTER stack, used for SYSENTER +* and the entry trampoline as well. +*/ +unsigned long SYSENTER_stack_canary; +unsigned long SYSENTER_stack[64 ]; + +/* +* The fixed hardware portion. This must not cross a page boundary +* at risk of violating the SDM's advice and potentially triggering +* errata. */ struct x86_hw_tss x86_tss;
@@ -343,15 +352,9 @@ struct tss_struct {* be within the limit. */ unsigned long io_bitmap[IO_BITMAP_LONGS +1 ]; +}__aligned(PAGE_SIZE) ; -/* -* Space for the temporary SYSENTER stack. -*/ -unsigned long SYSENTER_stack_canary; -unsigned long SYSENTER_stack[64 ]; -}____cacheline_aligned ; - -DECLARE_PER_CPU_SHARED_ALIGNED(struct tss_struct, cpu_tss); +DECLARE_PER_CPU_PAGE_ALIGNED(struct tss_struct, cpu_tss);/* * sizeof(unsigned long) coming from an extra "long" at the end
arch/x86/kernel/cpu/common.c +21 -0
@@ -487,6 +487,27 @@ static inline void setup_cpu_entry_area(#endif __set_fixmap (get_cpu_entry_area_index (cpu, gdt),get_cpu_gdt_paddr (cpu), gdt_prot); + +/* +* The Intel SDM says (Volume 3, 7.2.1): +* +* Avoid placing a page boundary in the part of the TSS that the +* processor reads during a task switch (the first 104 bytes). The +* processor may not correctly perform address translations if a +* boundary occurs in this area. During a task switch, the processor +* reads and writes into the first 104 bytes of each TSS (using +* contiguous physical addresses beginning with the physical address +* of the first byte of the TSS). So, after TSS access begins, if +* part of the 104 bytes is not physically contiguous, the processor +* will access incorrect information without generating a page-fault +* exception. +* +* There are also a lot of errata involving the TSS spanning a page +* boundary. Assert that we're not doing that. +*/ +BUILD_BUG_ON ((offsetof(struct tss_struct , x86_tss) ^ + offsetofend(struct tss_struct, x86_tss)) & PAGE_MASK); + }/* Load the original GDT from the per-cpu structure */
Greg Kroah-Hartman
maintainerPATCH 87/159 x86/entry: Remap the TSS into the CPU entry area
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit 72f5e08dbba2d01aa90b592cf76c378ea233b00b upstream.
This has a secondary purpose: it puts the entry stack into a region with a well-controlled layout. A subsequent patch will take advantage of this to streamline the SYSCALL entry code to be able to find it more easily.
--- arch/x86/entry/entry_32.S | 6 ++++-- arch/x86/include/asm/fixmap.h | 7 +++++++ arch/x86/kernel/asm-offsets.c | 3 +++ arch/x86/kernel/cpu/common.c | 41 +++++++++++++++++++++++++++++++++++------ arch/x86/kernel/dumpstack.c | 3 ++- arch/x86/kvm/vmx.c | 2 +- arch/x86/power/cpu.c | 11 ++++++----- 7 files changed, 58 insertions(+), 15 deletions(-)
arch/x86/entry/entry_32.S +4 -2
@@ -941,7 +941,8 @@ ENTRY(debug) movl %esp, %eax # pt_regs pointer /* Are we currently on the SYSENTER stack? */ - PER_CPU(cpu_tss + CPU_TSS_SYSENTER_stack + SIZEOF_SYSENTER_stack, %ecx) + movl PER_CPU_VAR(cpu_entry_area), %ecx + addl $CPU_ENTRY_AREA_tss + CPU_TSS_SYSENTER_stack + SIZEOF_SYSENTER_stack, %ecx subl %eax, %ecx /* ecx = (end of SYSENTER_stack) - esp */ cmpl $SIZEOF_SYSENTER_stack, %ecx jb .Ldebug_from_sysenter_stack
@@ -984,7 +985,8 @@ ENTRY(nmi) movl %esp, %eax # pt_regs pointer /* Are we currently on the SYSENTER stack? */ - PER_CPU(cpu_tss + CPU_TSS_SYSENTER_stack + SIZEOF_SYSENTER_stack, %ecx) + movl PER_CPU_VAR(cpu_entry_area), %ecx + addl $CPU_ENTRY_AREA_tss + CPU_TSS_SYSENTER_stack + SIZEOF_SYSENTER_stack, %ecx subl %eax, %ecx /* ecx = (end of SYSENTER_stack) - esp */ cmpl $SIZEOF_SYSENTER_stack, %ecx jb .Lnmi_from_sysenter_stack
arch/x86/include/asm/fixmap.h +7 -0
@@ -54,6 +54,13 @@ extern unsigned long __FIXADDR_TOP;*/ struct cpu_entry_area {char gdt[PAGE_SIZE ]; + +/* +* The GDT is just below cpu_tss and thus serves (on x86_64) as a +* a read-only guard page for the SYSENTER stack at the bottom +* of the TSS region. +*/ +struct tss_struct tss; };#define CPU_ENTRY_AREA_PAGES (sizeof(struct cpu_entry_area) / PAGE_SIZE)
arch/x86/kernel/asm-offsets.c +3 -0
@@ -98,4 +98,7 @@ void common(void) {OFFSET (CPU_TSS_SYSENTER_stack, tss_struct, SYSENTER_stack);/* Size of SYSENTER_stack */ DEFINE (SIZEOF_SYSENTER_stack,sizeof (((struct tss_struct *)0 )->SYSENTER_stack)); + +/* Layout info for cpu_entry_area */ +OFFSET (CPU_ENTRY_AREA_tss, cpu_entry_area, tss); }
arch/x86/kernel/cpu/common.c +35 -6
104 lines not on this page · raw message
arch/x86/kernel/dumpstack.c +2 -1
@@ -45,7 +45,8 @@ bool in_task_stack(unsigned long *stack,bool in_sysenter_stack (unsigned long *stack,struct stack_info *info) { -struct tss_struct *tss =this_cpu_ptr (&cpu_tss); +int cpu =smp_processor_id (); +struct tss_struct *tss = &get_cpu_entry_area (cpu)->tss;/* Treat the canary as part of the stack for unwinding purposes. */ void *begin = &tss->SYSENTER_stack_canary;
arch/x86/kvm/vmx.c +1 -1
@@ -2295,7 +2295,7 @@ static void vmx_vcpu_load(struct kvm_vcp* processors. See 22.2.4. */ vmcs_writel (HOST_TR_BASE , - (unsigned long )this_cpu_ptr (&cpu_tss.x86_tss)); + (unsigned long )&get_cpu_entry_area (cpu)->tss.x86_tss);vmcs_writel (HOST_GDTR_BASE , (unsigned long )gdt);/* 22.2.4 */ /*
arch/x86/power/cpu.c +6 -5
@@ -160,18 +160,19 @@ static void do_fpu_end(void)static void fix_processor_context (void ) {int cpu =smp_processor_id (); -struct tss_struct *t = &per_cpu (cpu_tss, cpu);#ifdef CONFIG_X86_64 struct desc_struct *desc =get_cpu_gdt_rw (cpu);tss_desc tss;#endif /* -* This just modifies memory; should not be necessary. But... This is -* necessary, because 386 hardware has concept of busy TSS or some -* similar stupidity. +* We need to reload TR, which requires that we change the +* GDT entry to indicate "available" first. +* +* XXX: This could probably all be replaced by a call to +* force_reload_TR(). */ -set_tss_desc (cpu, &t->x86_tss); +set_tss_desc (cpu, &get_cpu_entry_area (cpu)->tss.x86_tss);#ifdef CONFIG_X86_64 memcpy (&tss, &desc[GDT_ENTRY_TSS ],sizeof (tss_desc));
Greg Kroah-Hartman
maintainerPATCH 88/159 x86/entry/64: Separate cpu_current_top_of_stack from TSS.sp0
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit 9aaefe7b59ae00605256a7d6bd1c1456432495fc upstream.
On 64-bit kernels, we used to assume that TSS.sp0 was the current top of stack. With the addition of an entry trampoline, this will no longer be the case. Store the current top of stack in TSS.sp1, which is otherwise unused but shares the same cacheline.
--- arch/x86/include/asm/processor.h | 18 +++++++++++++----- arch/x86/include/asm/thread_info.h | 2 +- arch/x86/kernel/asm-offsets_64.c | 1 + arch/x86/kernel/process.c | 10 ++++++++++ arch/x86/kernel/process_64.c | 1 + 5 files changed, 26 insertions(+), 6 deletions(-)
arch/x86/include/asm/processor.h +13 -5
@@ -309,7 +309,13 @@ struct x86_hw_tss {struct x86_hw_tss {u32 reserved1;u64 sp0; + +/* +* We store cpu_current_top_of_stack in sp1 so it's always accessible. +* Linux does not use ring 1, so sp1 is not otherwise needed. +*/ u64 sp1; +u64 sp2;u64 reserved2;u64 ist[7 ];
@@ -368,6 +374,8 @@ DECLARE_PER_CPU_PAGE_ALIGNED(struct tss_#ifdef CONFIG_X86_32 DECLARE_PER_CPU(unsigned long, cpu_current_top_of_stack); +#else +#define cpu_current_top_of_stack cpu_tss.x86_tss.sp1#endif /*
@@ -539,12 +547,12 @@ static inline void native_swapgs(void)static inline unsigned long current_top_of_stack (void ) { -#ifdef CONFIG_X86_64 -return this_cpu_read_stable (cpu_tss.x86_tss.sp0); -#else -/* sp0 on x86_32 is special in and around vm86 mode. */ +/* +* We can't read directly from tss.sp0: sp0 on x86_32 is special in +* and around vm86 mode and sp0 on x86_64 is special because of the +* entry trampoline. +*/ return this_cpu_read_stable (cpu_current_top_of_stack); -#endif }static inline bool on_thread_stack (void )
arch/x86/include/asm/thread_info.h +1 -1
@@ -207,7 +207,7 @@ static inline int arch_within_stack_fram#else /* !__ASSEMBLY__ */ #ifdef CONFIG_X86_64 -# define cpu_current_top_of_stack (cpu_tss + TSS_sp0) +# define cpu_current_top_of_stack (cpu_tss + TSS_sp1)#endif #endif
arch/x86/kernel/asm-offsets_64.c +1 -0
@@ -66,6 +66,7 @@ int main(void)OFFSET (TSS_ist, tss_struct, x86_tss.ist);OFFSET (TSS_sp0, tss_struct, x86_tss.sp0); +OFFSET (TSS_sp1, tss_struct, x86_tss.sp1);BLANK ();#ifdef CONFIG_CC_STACKPROTECTOR
arch/x86/kernel/process.c +10 -0
@@ -56,6 +56,16 @@ __visible DEFINE_PER_CPU_SHARED_ALIGNED(* Poison it. */ .sp0 = (1UL << (BITS_PER_LONG-1)) + 1, + +#ifdef CONFIG_X86_64 +/* +* .sp1 is cpu_current_top_of_stack. The init task never +* runs user code, but cpu_current_top_of_stack should still +* be well defined before the first context switch. +*/ + .sp1 = TOP_OF_INIT_STACK, +#endif +#ifdef CONFIG_X86_32 .ss0 = __KERNEL_DS, .ss1 = __KERNEL_CS,
arch/x86/kernel/process_64.c +1 -0
@@ -461,6 +461,7 @@ __switch_to(struct task_struct *prev_p,* Switch the PDA and FPU contexts. */ this_cpu_write (current_task, next_p); +this_cpu_write (cpu_current_top_of_stack,task_top_of_stack (next_p));/* Reload sp0. */ update_sp0 (next_p);
Greg Kroah-Hartman
maintainerPATCH 89/159 x86/espfix/64: Stop assuming that pt_regs is on the entry stack
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit 6d9256f0a89eaff97fca6006100bcaea8d1d8bdb upstream.
When we start using an entry trampoline, a #GP from userspace will be delivered on the entry stack, not on the task stack. Fix the espfix64 #DF fixup to set up #GP according to TSS.SP0, rather than assuming that pt_regs + 1 == SP0. This won't change anything without an entry stack, but it will make the code continue to work when an entry stack is added.
While we're at it, improve the comments to explain what's actually going on.
--- arch/x86/kernel/traps.c | 37 ++++++++++++++++++++++++++++--------- 1 file changed, 28 insertions(+), 9 deletions(-)
arch/x86/kernel/traps.c +28 -9
@@ -348,9 +348,15 @@ dotraplinkage void do_double_fault(struc/* * If IRET takes a non-IST fault on the espfix64 stack, then we -* end up promoting it to a doublefault. In that case, modify -* the stack to make it look like we just entered the #GP -* handler from user space, similar to bad_iret. +* end up promoting it to a doublefault. In that case, take +* advantage of the fact that we're not using the normal (TSS.sp0) +* stack right now. We can write a fake #GP(0) frame at TSS.sp0 +* and then modify our own IRET frame so that, when we return, +* we land directly at the #GP(0) vector with the stack already +* set up according to its expectations. +* +* The net result is that our #GP handler will think that we +* entered from usermode with the bad user context. * * No need for ist_enter here because we don't use RCU. */
@@ -358,13 +364,26 @@ dotraplinkage void do_double_fault(struc regs->cs == __KERNEL_CS && regs->ip == (unsigned long)native_irq_return_iret) { -struct pt_regs *normal_regs =task_pt_regs (current); +struct pt_regs *gpregs = (struct pt_regs *)this_cpu_read (cpu_tss.x86_tss.sp0) -1 ; -/* Fake a #GP(0) from userspace. */ -memmove (&normal_regs->ip, (void *)regs->sp,5 *8 ); - normal_regs->orig_ax =0 ;/* Missing (lost) #GP error code */ +/* +* regs->sp points to the failing IRET frame on the +* ESPFIX64 stack. Copy it to the entry stack. This fills +* in gpregs->ss through gpregs->ip. +* +*/ +memmove (&gpregs->ip, (void *)regs->sp,5 *8 ); + gpregs->orig_ax =0 ;/* Missing (lost) #GP error code */ + +/* +* Adjust our frame so that we return straight to the #GP +* vector with the expected RSP value. This is safe because +* we won't enable interupts or schedule before we invoke +* general_protection, so nothing will clobber the stack +* frame we just set up. +*/ regs->ip = (unsigned long )general_protection; - regs->sp = (unsigned long )&normal_regs->orig_ax; + regs->sp = (unsigned long )&gpregs->orig_ax;return ; }
@@ -389,7 +408,7 @@ dotraplinkage void do_double_fault(struc* * Processors update CR2 whenever a page fault is detected. If a * second page fault occurs while an earlier page fault is being -* deliv- ered, the faulting linear address of the second fault will +* delivered, the faulting linear address of the second fault will * overwrite the contents of CR2 (replacing the previous * address). These updates to CR2 occur even if the page fault * results in a double fault or occurs during the delivery of a
Greg Kroah-Hartman
maintainerPATCH 90/159 x86/entry/64: Use a per-CPU trampoline stack for IDT entries
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit 7f2590a110b837af5679d08fc25c6227c5a8c497 upstream.
Historically, IDT entries from usermode have always gone directly to the running task's kernel stack. Rearrange it so that we enter on a per-CPU trampoline stack and then manually switch to the task's stack. This touches a couple of extra cachelines, but it gives us a chance to run some code before we touch the kernel stack.
The asm isn't exactly beautiful, but I think that fully refactoring it can wait.
--- arch/x86/entry/entry_64.S | 67 +++++++++++++++++++++++++++++---------- arch/x86/entry/entry_64_compat.S | 5 ++ arch/x86/include/asm/switch_to.h | 4 +- arch/x86/include/asm/traps.h | 1 arch/x86/kernel/cpu/common.c | 6 ++- arch/x86/kernel/traps.c | 21 ++++++------ 6 files changed, 72 insertions(+), 32 deletions(-)
arch/x86/entry/entry_64.S +50 -17
@@ -560,6 +560,13 @@ END(irq_entries_start) /* 0(%rsp): ~(interrupt number) */ .macro interrupt func cld + + testb $3, CS-ORIG_RAX(%rsp) + jz 1f + SWAPGS + call switch_to_thread_stack +1: + ALLOC_PT_GPREGS_ON_STACK SAVE_C_REGS SAVE_EXTRA_REGS
@@ -569,12 +576,8 @@ END(irq_entries_start) jz 1f /* - * IRQ from user mode. Switch to kernel gsbase and inform context - * tracking that we're in kernel mode. - */ - SWAPGS - - /* + * IRQ from user mode. + * * We need to tell lockdep that IRQs are off. We can't do this until * we fix gsbase, and we should do it before enter_from_user_mode * (which can take locks). Since TRACE_IRQS_OFF idempotent,
@@ -828,6 +831,32 @@ apicinterrupt IRQ_WORK_VECTOR irq_work */ #define CPU_TSS_IST(x) PER_CPU_VAR(cpu_tss) + (TSS_ist + ((x) - 1) * 8) +/* + * Switch to the thread stack. This is called with the IRET frame and + * orig_ax on the stack. (That is, RDI..R12 are not on the stack and + * space has not been allocated for them.) + */ +ENTRY(switch_to_thread_stack) + UNWIND_HINT_FUNC + + pushq %rdi + movq %rsp, %rdi + movq PER_CPU_VAR(cpu_current_top_of_stack), %rsp + UNWIND_HINT sp_offset=16 sp_reg=ORC_REG_DI + + pushq 7*8(%rdi) /* regs->ss */ + pushq 6*8(%rdi) /* regs->rsp */ + pushq 5*8(%rdi) /* regs->eflags */ + pushq 4*8(%rdi) /* regs->cs */ + pushq 3*8(%rdi) /* regs->ip */ + pushq 2*8(%rdi) /* regs->orig_ax */ + pushq 8(%rdi) /* return address */ + UNWIND_HINT_FUNC + + movq (%rdi), %rdi + ret +END(switch_to_thread_stack) + .macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1 ENTRY(\sym) UNWIND_HINT_IRET_REGS offset=\has_error_code*8
@@ -845,11 +874,12 @@ ENTRY(\sym) ALLOC_PT_GPREGS_ON_STACK - .if \paranoid - .if \paranoid == 1 + .if \paranoid < 2 testb $3, CS(%rsp) /* If coming from userspace, switch stacks */ - jnz 1f + jnz .Lfrom_usermode_switch_stack_\@ .endif + + .if \paranoid call paranoid_entry .else call error_entry
@@ -891,20 +921,15 @@ ENTRY(\sym) jmp error_exit .endif - .if \paranoid == 1 + .if \paranoid < 2 /* - * Paranoid entry from userspace. Switch stacks and treat it + * Entry from userspace. Switch stacks and treat it * as a normal entry. This means that paranoid handlers * run in real process context if user_mode(regs). */ -1: +.Lfrom_usermode_switch_stack_\@: call error_entry - - movq %rsp, %rdi /* pt_regs pointer */ - call sync_regs - movq %rax, %rsp /* switch stack */ - movq %rsp, %rdi /* pt_regs pointer */ .if \has_error_code
@@ -1165,6 +1190,14 @@ ENTRY(error_entry) SWAPGS .Lerror_entry_from_usermode_after_swapgs: + /* Put us onto the real thread stack. */ + popq %r12 /* save return addr in %12 */ + movq %rsp, %rdi /* arg0 = pt_regs pointer */ + call sync_regs + movq %rax, %rsp /* switch stack */ + ENCODE_FRAME_POINTER + pushq %r12 + /* * We need to tell lockdep that IRQs are off. We can't do this until * we fix gsbase, and we should do it before enter_from_user_mode
arch/x86/entry/entry_64_compat.S +4 -1
@@ -306,8 +306,11 @@ ENTRY(entry_INT80_compat) */ movl %eax, %eax - /* Construct struct pt_regs on stack (iret frame is already on stack) */ pushq %rax /* pt_regs->orig_ax */ + + /* switch to thread stack expects orig_ax to be pushed */ + call switch_to_thread_stack + pushq %rdi /* pt_regs->di */ pushq %rsi /* pt_regs->si */ pushq %rdx /* pt_regs->dx */
arch/x86/include/asm/switch_to.h +3 -1
@@ -90,10 +90,12 @@ static inline void refresh_sysenter_cs(s/* This is used when switching tasks or entering/exiting vm86 mode. */ static inline void update_sp0 (struct task_struct *task) { +/* On x86_64, sp0 always points to the entry trampoline stack, which is constant: */ #ifdef CONFIG_X86_32 load_sp0 (task->thread.sp0);#else -load_sp0 (task_top_of_stack (task)); +if (static_cpu_has (X86_FEATURE_XENPV )) +load_sp0 (task_top_of_stack (task));#endif }
arch/x86/include/asm/traps.h +0 -1
@@ -75,7 +75,6 @@ dotraplinkage void do_segment_not_presen dotraplinkage void do_stack_segment(struct pt_regs *, long);#ifdef CONFIG_X86_64 dotraplinkage void do_double_fault(struct pt_regs *, long); -asmlinkage struct pt_regs *sync_regs(struct pt_regs *);#endif dotraplinkage void do_general_protection(struct pt_regs *, long); dotraplinkage void do_page_fault(struct pt_regs *, unsigned long);
arch/x86/kernel/cpu/common.c +4 -2
@@ -1623,11 +1623,13 @@ void cpu_init(void)setup_cpu_entry_area (cpu);/* -* Initialize the TSS. Don't bother initializing sp0, as the initial -* task never enters user mode. +* Initialize the TSS. sp0 points to the entry trampoline stack +* regardless of what task is running. */ set_tss_desc (cpu, &get_cpu_entry_area (cpu)->tss.x86_tss);load_TR_desc (); +load_sp0 ((unsigned long )&get_cpu_entry_area (cpu)->tss + + offsetofend(struct tss_struct, SYSENTER_stack));load_mm_ldt (&init_mm);
arch/x86/kernel/traps.c +11 -10
@@ -619,14 +619,15 @@ NOKPROBE_SYMBOL(do_int3);#ifdef CONFIG_X86_64 /* -* Help handler running on IST stack to switch off the IST stack if the -* interrupted code was in user mode. The actual stack switch is done in -* entry_64.S +* Help handler running on a per-cpu (IST or entry trampoline) stack +* to switch to the normal thread stack if the interrupted code was in +* user mode. The actual stack switch is done in entry_64.S */ asmlinkage __visible notrace struct pt_regs *sync_regs(struct pt_regs *eregs) { -struct pt_regs *regs =task_pt_regs (current); - *regs = *eregs; +struct pt_regs *regs = (struct pt_regs *)this_cpu_read (cpu_current_top_of_stack) -1 ; +if (regs != eregs) + *regs = *eregs;return regs; }NOKPROBE_SYMBOL (sync_regs);
@@ -642,13 +643,13 @@ struct bad_iret_stack *fixup_bad_iret(st/* * This is called from entry_64.S early in handling a fault * caused by a bad iret to user mode. To handle the fault -* correctly, we want move our stack frame to task_pt_regs -* and we want to pretend that the exception came from the -* iret target. +* correctly, we want to move our stack frame to where it would +* be had we entered directly on the entry stack (rather than +* just below the IRET frame) and we want to pretend that the +* exception came from the IRET target. */ struct bad_iret_stack *new_stack = -container_of (task_pt_regs (current), - struct bad_iret_stack, regs); + (struct bad_iret_stack *)this_cpu_read (cpu_tss.x86_tss.sp0) -1 ;/* Copy the IRET target to the new stack. */ memmove (&new_stack->regs.ip, (void *)s->regs.sp,5 *8 );
Greg Kroah-Hartman
maintainerPATCH 91/159 x86/entry/64: Return to userspace from the trampoline stack
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit 3e3b9293d392c577b62e24e4bc9982320438e749 upstream.
By itself, this is useless. It gives us the ability to run some final code before exit that cannnot run on the kernel stack. This could include a CR3 switch a la PAGE_TABLE_ISOLATION or some kernel stack erasing, for example. (Or even weird things like *changing* which kernel stack gets used as an ASLR-strengthening mechanism.)
The SYSRET32 path is not covered yet. It could be in the future or we could just ignore it and force the slow path if needed.
--- arch/x86/entry/entry_64.S | 55 ++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 51 insertions(+), 4 deletions(-)
arch/x86/entry/entry_64.S +51 -4
@@ -326,8 +326,24 @@ syscall_return_via_sysret: popq %rsi /* skip rcx */ popq %rdx popq %rsi + + /* + * Now all regs are restored except RSP and RDI. + * Save old stack pointer and switch to trampoline stack. + */ + movq %rsp, %rdi + movq PER_CPU_VAR(cpu_tss + TSS_sp0), %rsp + + pushq RSP-RDI(%rdi) /* RSP */ + pushq (%rdi) /* RDI */ + + /* + * We are on the trampoline stack. All regs except RDI are live. + * We can do future final exit work right here. + */ + popq %rdi - movq RSP-ORIG_RAX(%rsp), %rsp + popq %rsp USERGS_SYSRET64 END(entry_SYSCALL_64)
@@ -630,10 +646,41 @@ GLOBAL(swapgs_restore_regs_and_return_to ud2 1: #endif - SWAPGS POP_EXTRA_REGS - POP_C_REGS - addq $8, %rsp /* skip regs->orig_ax */ + popq %r11 + popq %r10 + popq %r9 + popq %r8 + popq %rax + popq %rcx + popq %rdx + popq %rsi + + /* + * The stack is now user RDI, orig_ax, RIP, CS, EFLAGS, RSP, SS. + * Save old stack pointer and switch to trampoline stack. + */ + movq %rsp, %rdi + movq PER_CPU_VAR(cpu_tss + TSS_sp0), %rsp + + /* Copy the IRET frame to the trampoline stack. */ + pushq 6*8(%rdi) /* SS */ + pushq 5*8(%rdi) /* RSP */ + pushq 4*8(%rdi) /* EFLAGS */ + pushq 3*8(%rdi) /* CS */ + pushq 2*8(%rdi) /* RIP */ + + /* Push user RDI on the trampoline stack. */ + pushq (%rdi) + + /* + * We are on the trampoline stack. All regs except RDI are live. + * We can do future final exit work right here. + */ + + /* Restore RDI. */ + popq %rdi + SWAPGS INTERRUPT_RETURN
Greg Kroah-Hartman
maintainerPATCH 92/159 x86/entry/64: Create a per-CPU SYSCALL entry trampoline
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit 3386bc8aed825e9f1f65ce38df4b109b2019b71a upstream.
Handling SYSCALL is tricky: the SYSCALL handler is entered with every single register (except FLAGS), including RSP, live. It somehow needs to set RSP to point to a valid stack, which means it needs to save the user RSP somewhere and find its own stack pointer. The canonical way to do this is with SWAPGS, which lets us access percpu data using the %gs prefix.
With PAGE_TABLE_ISOLATION-like pagetable switching, this is problematic. Without a scratch register, switching CR3 is impossible, so %gs-based percpu memory would need to be mapped in the user pagetables. Doing that without information leaks is difficult or impossible.
Instead, use a different sneaky trick. Map a copy of the first part of the SYSCALL asm at a different address for each CPU. Now RIP varies depending on the CPU, so we can use RIP-relative memory access to access percpu memory. By putting the relevant information (one scratch slot and the stack address) at a constant offset relative to RIP, we can make SYSCALL work without relying on %gs.
A nice thing about this approach is that we can easily switch it on and off if we want pagetable switching to be configurable.
The compat variant of SYSCALL doesn't have this problem in the first place -- there are plenty of scratch registers, since we don't care about preserving r8-r15. This patch therefore doesn't touch SYSCALL32 at all.
This patch actually seems to be a small speedup. With this patch, SYSCALL touches an extra cache line and an extra virtual page, but the pipeline no longer stalls waiting for SWAPGS. It seems that, at least in a tight loop, the latter outweights the former.
Thanks to David Laight for an optimization tip.
--- arch/x86/entry/entry_64.S | 58 ++++++++++++++++++++++++++++++++++++++++++ arch/x86/include/asm/fixmap.h | 2 + arch/x86/kernel/asm-offsets.c | 1 arch/x86/kernel/cpu/common.c | 15 ++++++++++ arch/x86/kernel/vmlinux.lds.S | 9 ++++++ 5 files changed, 84 insertions(+), 1 deletion(-)
arch/x86/entry/entry_64.S +58 -0
@@ -136,6 +136,64 @@ END(native_usergs_sysret64) * with them due to bugs in both AMD and Intel CPUs. */ + .pushsection .entry_trampoline, "ax" + +/* + * The code in here gets remapped into cpu_entry_area's trampoline. This means + * that the assembler and linker have the wrong idea as to where this code + * lives (and, in fact, it's mapped more than once, so it's not even at a + * fixed address). So we can't reference any symbols outside the entry + * trampoline and expect it to work. + * + * Instead, we carefully abuse %rip-relative addressing. + * _entry_trampoline(%rip) refers to the start of the remapped) entry + * trampoline. We can thus find cpu_entry_area with this macro: + */ + +#define CPU_ENTRY_AREA \ + _entry_trampoline - CPU_ENTRY_AREA_entry_trampoline(%rip) + +/* The top word of the SYSENTER stack is hot and is usable as scratch space. */ +#define RSP_SCRATCH CPU_ENTRY_AREA_tss + CPU_TSS_SYSENTER_stack + \ + SIZEOF_SYSENTER_stack - 8 + CPU_ENTRY_AREA + +ENTRY(entry_SYSCALL_64_trampoline) + UNWIND_HINT_EMPTY + swapgs + + /* Stash the user RSP. */ + movq %rsp, RSP_SCRATCH + + /* Load the top of the task stack into RSP */ + movq CPU_ENTRY_AREA_tss + TSS_sp1 + CPU_ENTRY_AREA, %rsp + + /* Start building the simulated IRET frame. */ + pushq $__USER_DS /* pt_regs->ss */ + pushq RSP_SCRATCH /* pt_regs->sp */ + pushq %r11 /* pt_regs->flags */ + pushq $__USER_CS /* pt_regs->cs */ + pushq %rcx /* pt_regs->ip */ + + /* + * x86 lacks a near absolute jump, and we can't jump to the real + * entry text with a relative jump. We could push the target + * address and then use retq, but this destroys the pipeline on + * many CPUs (wasting over 20 cycles on Sandy Bridge). Instead, + * spill RDI and restore it in a second-stage trampoline. + */ + pushq %rdi + movq $entry_SYSCALL_64_stage2, %rdi + jmp *%rdi +END(entry_SYSCALL_64_trampoline) + + .popsection + +ENTRY(entry_SYSCALL_64_stage2) + UNWIND_HINT_EMPTY + popq %rdi + jmp entry_SYSCALL_64_after_hwframe +END(entry_SYSCALL_64_stage2) + ENTRY(entry_SYSCALL_64) UNWIND_HINT_EMPTY /*
arch/x86/include/asm/fixmap.h +2 -0
@@ -61,6 +61,8 @@ struct cpu_entry_area {* of the TSS region. */ struct tss_struct tss; + +char entry_trampoline[PAGE_SIZE ]; };#define CPU_ENTRY_AREA_PAGES (sizeof(struct cpu_entry_area) / PAGE_SIZE)
arch/x86/kernel/asm-offsets.c +1 -0
@@ -101,4 +101,5 @@ void common(void) {/* Layout info for cpu_entry_area */ OFFSET (CPU_ENTRY_AREA_tss, cpu_entry_area, tss); +OFFSET (CPU_ENTRY_AREA_entry_trampoline, cpu_entry_area, entry_trampoline); }
arch/x86/kernel/cpu/common.c +14 -1
@@ -486,6 +486,8 @@ DEFINE_PER_CPU(struct cpu_entry_area *,static inline void setup_cpu_entry_area (int cpu) {#ifdef CONFIG_X86_64 +extern char _entry_trampoline[]; +/* On 64-bit systems, we use a read-only fixmap GDT. */ pgprot_t gdt_prot =PAGE_KERNEL_RO ;#else
@@ -532,6 +534,11 @@ static inline void setup_cpu_entry_area(#ifdef CONFIG_X86_32 this_cpu_write (cpu_entry_area,get_cpu_entry_area (cpu));#endif + +#ifdef CONFIG_X86_64 +__set_fixmap (get_cpu_entry_area_index (cpu, entry_trampoline), +__pa_symbol (_entry_trampoline),PAGE_KERNEL_RX ); +#endif }/* Load the original GDT from the per-cpu structure */
@@ -1395,10 +1402,16 @@ static DEFINE_PER_CPU_PAGE_ALIGNED(char,/* May not be marked __init: used by software suspend */ void syscall_init (void ) { +extern char _entry_trampoline[]; +extern char entry_SYSCALL_64_trampoline[]; +int cpu =smp_processor_id (); +unsigned long SYSCALL64_entry_trampoline = + (unsigned long )get_cpu_entry_area (cpu)->entry_trampoline + + (entry_SYSCALL_64_trampoline - _entry_trampoline);wrmsr (MSR_STAR ,0 , (__USER32_CS <<16 ) | __KERNEL_CS); -wrmsrl (MSR_LSTAR , (unsigned long )entry_SYSCALL_64); +wrmsrl (MSR_LSTAR , SYSCALL64_entry_trampoline);#ifdef CONFIG_IA32_EMULATION wrmsrl (MSR_CSTAR , (unsigned long )entry_SYSCALL_compat);
arch/x86/kernel/vmlinux.lds.S +9 -0
@@ -107,6 +107,15 @@ SECTIONS SOFTIRQENTRY_TEXT *(.fixup) *(.gnu.warning) + +#ifdef CONFIG_X86_64 + . = ALIGN(PAGE_SIZE); + _entry_trampoline = .; + *(.entry_trampoline) + . = ALIGN(PAGE_SIZE); + ASSERT(. - _entry_trampoline == PAGE_SIZE, "entry trampoline is too big"); +#endif + /* End of text section */ _etext = .; } :text = 0x9090
Greg Kroah-Hartman
maintainerPATCH 93/159 x86/entry/64: Move the IST stacks into struct cpu_entry_area
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit 40e7f949e0d9a33968ebde5d67f7e3a47c97742a upstream.
The IST stacks are needed when an IST exception occurs and are accessed before any kernel code at all runs. Move them into struct cpu_entry_area.
The IST stacks are unlike the rest of cpu_entry_area: they're used even for entries from kernel mode. This means that they should be set up before we load the final IDT. Move cpu_entry_area setup to trap_init() for the boot CPU and set it up for all possible CPUs at once in native_smp_prepare_cpus().
--- arch/x86/include/asm/fixmap.h | 12 ++++++ arch/x86/kernel/cpu/common.c | 74 +++++++++++++++++++++++------------------- arch/x86/kernel/traps.c | 3 + 3 files changed, 57 insertions(+), 32 deletions(-)
arch/x86/include/asm/fixmap.h +12 -0
@@ -63,10 +63,22 @@ struct cpu_entry_area {struct tss_struct tss;char entry_trampoline[PAGE_SIZE ]; + +#ifdef CONFIG_X86_64 +/* +* Exception stacks used for IST entries. +* +* In the future, this should have a separate slot for each stack +* with guard pages between them. +*/ +char exception_stacks[(N_EXCEPTION_STACKS -1 ) *EXCEPTION_STKSZ +DEBUG_STKSZ ]; +#endif };#define CPU_ENTRY_AREA_PAGES (sizeof(struct cpu_entry_area) / PAGE_SIZE) +extern void setup_cpu_entry_areas (void ); +/* * Here we define all the compile-time 'special' virtual * addresses. The point is to have a constant address at
arch/x86/kernel/cpu/common.c +42 -32
124 lines not on this page · raw message
arch/x86/kernel/traps.c +3 -0
@@ -947,6 +947,9 @@ dotraplinkage void do_iret_error(structvoid __init trap_init (void ) { +/* Init cpu_entry_area before IST entries are set up */ +setup_cpu_entry_areas (); +idt_setup_traps ();/*
Greg Kroah-Hartman
maintainerPATCH 94/159 x86/entry/64: Remove the SYSENTER stack canary
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit 7fbbd5cbebf118a9e09f5453f686656a167c3d1c upstream.
Now that the SYSENTER stack has a guard page, there's no need for a canary to detect overflow after the fact.
--- arch/x86/include/asm/processor.h | 1 - arch/x86/kernel/dumpstack.c | 3 +-- arch/x86/kernel/process.c | 1 - arch/x86/kernel/traps.c | 7 ------- 4 files changed, 1 insertion(+), 11 deletions(-)
arch/x86/include/asm/processor.h +0 -1
@@ -341,7 +341,6 @@ struct tss_struct {* Space for the temporary SYSENTER stack, used for SYSENTER * and the entry trampoline as well. */ -unsigned long SYSENTER_stack_canary;unsigned long SYSENTER_stack[64 ];/*
arch/x86/kernel/dumpstack.c +1 -2
@@ -48,8 +48,7 @@ bool in_sysenter_stack(unsigned long *stint cpu =smp_processor_id ();struct tss_struct *tss = &get_cpu_entry_area (cpu)->tss; -/* Treat the canary as part of the stack for unwinding purposes. */ -void *begin = &tss->SYSENTER_stack_canary; +void *begin = &tss->SYSENTER_stack;void *end = (void *)&tss->SYSENTER_stack +sizeof (tss->SYSENTER_stack);if ((void *)stack < begin || (void *)stack >= end)
arch/x86/kernel/process.c +0 -1
@@ -81,7 +81,6 @@ __visible DEFINE_PER_CPU_SHARED_ALIGNED(*/ .io_bitmap = { [0 ... IO_BITMAP_LONGS] = ~0 },#endif - .SYSENTER_stack_canary =STACK_END_MAGIC , };EXPORT_PER_CPU_SYMBOL (cpu_tss);
arch/x86/kernel/traps.c +0 -7
@@ -814,13 +814,6 @@ dotraplinkage void do_debug(struct pt_redebug_stack_usage_dec (); exit: -/* -* This is the most likely code path that involves non-trivial use -* of the SYSENTER stack. Check that we haven't overrun it. -*/ -WARN (this_cpu_read (cpu_tss.SYSENTER_stack_canary) !=STACK_END_MAGIC , -"Overran or corrupted SYSENTER stack\n" ); -ist_exit (regs); }NOKPROBE_SYMBOL (do_debug);
Greg Kroah-Hartman
maintainerPATCH 95/159 x86/entry: Clean up the SYSENTER_stack code
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit 0f9a48100fba3f189724ae88a450c2261bf91c80 upstream.
The existing code was a mess, mainly because C arrays are nasty. Turn SYSENTER_stack into a struct, add a helper to find it, and do all the obvious cleanups this enables.
--- arch/x86/entry/entry_32.S | 4 ++-- arch/x86/entry/entry_64.S | 2 +- arch/x86/include/asm/fixmap.h | 5 +++++ arch/x86/include/asm/processor.h | 6 +++++- arch/x86/kernel/asm-offsets.c | 6 ++---- arch/x86/kernel/cpu/common.c | 14 +++----------- arch/x86/kernel/dumpstack.c | 7 +++---- 7 files changed, 21 insertions(+), 23 deletions(-)
arch/x86/entry/entry_32.S +2 -2
@@ -942,7 +942,7 @@ ENTRY(debug) /* Are we currently on the SYSENTER stack? */ movl PER_CPU_VAR(cpu_entry_area), %ecx - addl $CPU_ENTRY_AREA_tss + CPU_TSS_SYSENTER_stack + SIZEOF_SYSENTER_stack, %ecx + addl $CPU_ENTRY_AREA_tss + TSS_STRUCT_SYSENTER_stack + SIZEOF_SYSENTER_stack, %ecx subl %eax, %ecx /* ecx = (end of SYSENTER_stack) - esp */ cmpl $SIZEOF_SYSENTER_stack, %ecx jb .Ldebug_from_sysenter_stack
@@ -986,7 +986,7 @@ ENTRY(nmi) /* Are we currently on the SYSENTER stack? */ movl PER_CPU_VAR(cpu_entry_area), %ecx - addl $CPU_ENTRY_AREA_tss + CPU_TSS_SYSENTER_stack + SIZEOF_SYSENTER_stack, %ecx + addl $CPU_ENTRY_AREA_tss + TSS_STRUCT_SYSENTER_stack + SIZEOF_SYSENTER_stack, %ecx subl %eax, %ecx /* ecx = (end of SYSENTER_stack) - esp */ cmpl $SIZEOF_SYSENTER_stack, %ecx jb .Lnmi_from_sysenter_stack
arch/x86/entry/entry_64.S +1 -1
@@ -154,7 +154,7 @@ END(native_usergs_sysret64) _entry_trampoline - CPU_ENTRY_AREA_entry_trampoline(%rip) /* The top word of the SYSENTER stack is hot and is usable as scratch space. */ -#define RSP_SCRATCH CPU_ENTRY_AREA_tss + CPU_TSS_SYSENTER_stack + \ +#define RSP_SCRATCH CPU_ENTRY_AREA_tss + TSS_STRUCT_SYSENTER_stack + \ SIZEOF_SYSENTER_stack - 8 + CPU_ENTRY_AREA ENTRY(entry_SYSCALL_64_trampoline)
arch/x86/include/asm/fixmap.h +5 -0
@@ -245,5 +245,10 @@ static inline struct cpu_entry_area *getreturn (struct cpu_entry_area *)__fix_to_virt (__get_cpu_entry_area_page_index (cpu,0 )); } +static inline struct SYSENTER_stack *cpu_SYSENTER_stack (int cpu) +{ +return &get_cpu_entry_area (cpu)->tss.SYSENTER_stack; +} +#endif /* !__ASSEMBLY__ */ #endif /* _ASM_X86_FIXMAP_H */
arch/x86/include/asm/processor.h +5 -1
@@ -336,12 +336,16 @@ struct x86_hw_tss {#define IO_BITMAP_OFFSET (offsetof(struct tss_struct, io_bitmap) - offsetof(struct tss_struct, x86_tss))#define INVALID_IO_BITMAP_OFFSET 0x8000 +struct SYSENTER_stack { +unsigned long words[64 ]; +}; +struct tss_struct {/* * Space for the temporary SYSENTER stack, used for SYSENTER * and the entry trampoline as well. */ -unsigned long SYSENTER_stack[64 ]; +struct SYSENTER_stack SYSENTER_stack;/* * The fixed hardware portion. This must not cross a page boundary
arch/x86/kernel/asm-offsets.c +2 -4
@@ -94,10 +94,8 @@ void common(void) {BLANK ();DEFINE (PTREGS_SIZE ,sizeof (struct pt_regs )); -/* Offset from cpu_tss to SYSENTER_stack */ -OFFSET (CPU_TSS_SYSENTER_stack, tss_struct, SYSENTER_stack); -/* Size of SYSENTER_stack */ -DEFINE (SIZEOF_SYSENTER_stack,sizeof (((struct tss_struct *)0 )->SYSENTER_stack)); +OFFSET (TSS_STRUCT_SYSENTER_stack, tss_struct, SYSENTER_stack); +DEFINE (SIZEOF_SYSENTER_stack,sizeof (struct SYSENTER_stack ));/* Layout info for cpu_entry_area */ OFFSET (CPU_ENTRY_AREA_tss, cpu_entry_area, tss);
arch/x86/kernel/cpu/common.c +3 -11
@@ -1314,12 +1314,7 @@ void enable_sep_cpu(void) tss->x86_tss.ss1 = __KERNEL_CS;wrmsr (MSR_IA32_SYSENTER_CS , tss->x86_tss.ss1,0 ); - -wrmsr (MSR_IA32_SYSENTER_ESP , - (unsigned long )&get_cpu_entry_area (cpu)->tss + - offsetofend(struct tss_struct, SYSENTER_stack), -0 ); - +wrmsr (MSR_IA32_SYSENTER_ESP , (unsigned long )(cpu_SYSENTER_stack (cpu) +1 ),0 );wrmsr (MSR_IA32_SYSENTER_EIP , (unsigned long )entry_SYSENTER_32,0 );put_cpu ();
@@ -1436,9 +1431,7 @@ void syscall_init(void)* AMD doesn't allow SYSENTER in long mode (either 32- or 64-bit). */ wrmsrl_safe (MSR_IA32_SYSENTER_CS , (u64 )__KERNEL_CS); -wrmsrl_safe (MSR_IA32_SYSENTER_ESP , - (unsigned long )&get_cpu_entry_area (cpu)->tss + - offsetofend(struct tss_struct, SYSENTER_stack)); +wrmsrl_safe (MSR_IA32_SYSENTER_ESP , (unsigned long )(cpu_SYSENTER_stack (cpu) +1 ));wrmsrl_safe (MSR_IA32_SYSENTER_EIP , (u64 )entry_SYSENTER_compat);#else wrmsrl (MSR_CSTAR , (unsigned long )ignore_sysret);
@@ -1653,8 +1646,7 @@ void cpu_init(void)*/ set_tss_desc (cpu, &get_cpu_entry_area (cpu)->tss.x86_tss);load_TR_desc (); -load_sp0 ((unsigned long )&get_cpu_entry_area (cpu)->tss + - offsetofend(struct tss_struct, SYSENTER_stack)); +load_sp0 ((unsigned long )(cpu_SYSENTER_stack (cpu) +1 ));load_mm_ldt (&init_mm);
arch/x86/kernel/dumpstack.c +3 -4
@@ -45,11 +45,10 @@ bool in_task_stack(unsigned long *stack,bool in_sysenter_stack (unsigned long *stack,struct stack_info *info) { -int cpu =smp_processor_id (); -struct tss_struct *tss = &get_cpu_entry_area (cpu)->tss; +struct SYSENTER_stack *ss =cpu_SYSENTER_stack (smp_processor_id ()); -void *begin = &tss->SYSENTER_stack; -void *end = (void *)&tss->SYSENTER_stack +sizeof (tss->SYSENTER_stack); +void *begin = ss; +void *end = ss +1 ;if ((void *)stack < begin || (void *)stack >= end)return false;
Greg Kroah-Hartman
maintainerPATCH 96/159 x86/entry/64: Make cpu_entry_area.tss read-only
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit c482feefe1aeb150156248ba0fd3e029bc886605 upstream.
The TSS is a fairly juicy target for exploits, and, now that the TSS is in the cpu_entry_area, it's no longer protected by kASLR. Make it read-only on x86_64.
On x86_32, it can't be RO because it's written by the CPU during task switches, and we use a task gate for double faults. I'd also be nervous about errata if we tried to make it RO even on configurations without double fault handling.
[ tglx: AMD confirmed that there is no problem on 64-bit with TSS RO. So
it's probably safe to assume that it's a non issue, though Intel might have been creative in that area. Still waiting for confirmation. ]
--- arch/x86/entry/entry_32.S | 4 ++-- arch/x86/entry/entry_64.S | 8 ++++---- arch/x86/include/asm/fixmap.h | 13 +++++++++---- arch/x86/include/asm/processor.h | 17 ++++++++--------- arch/x86/include/asm/switch_to.h | 4 ++-- arch/x86/include/asm/thread_info.h | 2 +- arch/x86/kernel/asm-offsets.c | 5 ++--- arch/x86/kernel/asm-offsets_32.c | 4 ++-- arch/x86/kernel/cpu/common.c | 29 +++++++++++++++++++---------- arch/x86/kernel/ioport.c | 2 +- arch/x86/kernel/process.c | 6 +++--- arch/x86/kernel/process_32.c | 2 +- arch/x86/kernel/process_64.c | 2 +- arch/x86/kernel/traps.c | 4 ++-- arch/x86/lib/delay.c | 4 ++-- arch/x86/xen/enlighten_pv.c | 2 +- 16 files changed, 60 insertions(+), 48 deletions(-)
arch/x86/entry/entry_32.S +2 -2
@@ -942,7 +942,7 @@ ENTRY(debug) /* Are we currently on the SYSENTER stack? */ movl PER_CPU_VAR(cpu_entry_area), %ecx - addl $CPU_ENTRY_AREA_tss + TSS_STRUCT_SYSENTER_stack + SIZEOF_SYSENTER_stack, %ecx + addl $CPU_ENTRY_AREA_SYSENTER_stack + SIZEOF_SYSENTER_stack, %ecx subl %eax, %ecx /* ecx = (end of SYSENTER_stack) - esp */ cmpl $SIZEOF_SYSENTER_stack, %ecx jb .Ldebug_from_sysenter_stack
@@ -986,7 +986,7 @@ ENTRY(nmi) /* Are we currently on the SYSENTER stack? */ movl PER_CPU_VAR(cpu_entry_area), %ecx - addl $CPU_ENTRY_AREA_tss + TSS_STRUCT_SYSENTER_stack + SIZEOF_SYSENTER_stack, %ecx + addl $CPU_ENTRY_AREA_SYSENTER_stack + SIZEOF_SYSENTER_stack, %ecx subl %eax, %ecx /* ecx = (end of SYSENTER_stack) - esp */ cmpl $SIZEOF_SYSENTER_stack, %ecx jb .Lnmi_from_sysenter_stack
arch/x86/entry/entry_64.S +4 -4
@@ -154,7 +154,7 @@ END(native_usergs_sysret64) _entry_trampoline - CPU_ENTRY_AREA_entry_trampoline(%rip) /* The top word of the SYSENTER stack is hot and is usable as scratch space. */ -#define RSP_SCRATCH CPU_ENTRY_AREA_tss + TSS_STRUCT_SYSENTER_stack + \ +#define RSP_SCRATCH CPU_ENTRY_AREA_SYSENTER_stack + \ SIZEOF_SYSENTER_stack - 8 + CPU_ENTRY_AREA ENTRY(entry_SYSCALL_64_trampoline)
@@ -390,7 +390,7 @@ syscall_return_via_sysret: * Save old stack pointer and switch to trampoline stack. */ movq %rsp, %rdi - movq PER_CPU_VAR(cpu_tss + TSS_sp0), %rsp + movq PER_CPU_VAR(cpu_tss_rw + TSS_sp0), %rsp pushq RSP-RDI(%rdi) /* RSP */ pushq (%rdi) /* RDI */
@@ -719,7 +719,7 @@ GLOBAL(swapgs_restore_regs_and_return_to * Save old stack pointer and switch to trampoline stack. */ movq %rsp, %rdi - movq PER_CPU_VAR(cpu_tss + TSS_sp0), %rsp + movq PER_CPU_VAR(cpu_tss_rw + TSS_sp0), %rsp /* Copy the IRET frame to the trampoline stack. */ pushq 6*8(%rdi) /* SS */
@@ -934,7 +934,7 @@ apicinterrupt IRQ_WORK_VECTOR irq_work /* * Exception entry points. */ -#define CPU_TSS_IST(x) PER_CPU_VAR(cpu_tss) + (TSS_ist + ((x) - 1) * 8) +#define CPU_TSS_IST(x) PER_CPU_VAR(cpu_tss_rw) + (TSS_ist + ((x) - 1) * 8) /* * Switch to the thread stack. This is called with the IRET frame and
arch/x86/include/asm/fixmap.h +9 -4
@@ -56,9 +56,14 @@ struct cpu_entry_area {char gdt[PAGE_SIZE ];/* -* The GDT is just below cpu_tss and thus serves (on x86_64) as a -* a read-only guard page for the SYSENTER stack at the bottom -* of the TSS region. +* The GDT is just below SYSENTER_stack and thus serves (on x86_64) as +* a a read-only guard page. +*/ +struct SYSENTER_stack_page SYSENTER_stack_page; + +/* +* On x86_64, the TSS is mapped RO. On x86_32, it's mapped RW because +* we need task switches to work, and task switches write to the TSS. */ struct tss_struct tss;
@@ -247,7 +252,7 @@ static inline struct cpu_entry_area *getstatic inline struct SYSENTER_stack *cpu_SYSENTER_stack (int cpu) { -return &get_cpu_entry_area (cpu)->tss.SYSENTER_stack; +return &get_cpu_entry_area (cpu)->SYSENTER_stack_page.stack; }#endif /* !__ASSEMBLY__ */
arch/x86/include/asm/processor.h +8 -9
@@ -340,13 +340,11 @@ struct SYSENTER_stack {unsigned long words[64 ]; }; -struct tss_struct { -/* -* Space for the temporary SYSENTER stack, used for SYSENTER -* and the entry trampoline as well. -*/ -struct SYSENTER_stack SYSENTER_stack; +struct SYSENTER_stack_page { +struct SYSENTER_stack stack; +}__aligned(PAGE_SIZE) ; +struct tss_struct {/* * The fixed hardware portion. This must not cross a page boundary * at risk of violating the SDM's advice and potentially triggering
@@ -363,7 +361,7 @@ struct tss_struct {unsigned long io_bitmap[IO_BITMAP_LONGS +1 ]; }__aligned(PAGE_SIZE) ; -DECLARE_PER_CPU_PAGE_ALIGNED(struct tss_struct, cpu_tss); +DECLARE_PER_CPU_PAGE_ALIGNED(struct tss_struct, cpu_tss_rw);/* * sizeof(unsigned long) coming from an extra "long" at the end
@@ -378,7 +376,8 @@ DECLARE_PER_CPU_PAGE_ALIGNED(struct tss_#ifdef CONFIG_X86_32 DECLARE_PER_CPU(unsigned long, cpu_current_top_of_stack);#else -#define cpu_current_top_of_stack cpu_tss.x86_tss.sp1 +/* The RO copy can't be accessed with this_cpu_xyz(), so use the RW copy. */ +#define cpu_current_top_of_stack cpu_tss_rw.x86_tss.sp1#endif /*
@@ -538,7 +537,7 @@ static inline void native_set_iopl_mask(static inline void native_load_sp0 (unsigned long sp0) { -this_cpu_write (cpu_tss.x86_tss.sp0, sp0); +this_cpu_write (cpu_tss_rw.x86_tss.sp0, sp0); }static inline void native_swapgs (void )
arch/x86/include/asm/switch_to.h +2 -2
@@ -79,10 +79,10 @@ do { \static inline void refresh_sysenter_cs (struct thread_struct *thread) {/* Only happens when SEP is enabled, no need to test "SEP"arately: */ -if (unlikely (this_cpu_read (cpu_tss.x86_tss.ss1) == thread->sysenter_cs)) +if (unlikely (this_cpu_read (cpu_tss_rw.x86_tss.ss1) == thread->sysenter_cs))return ; -this_cpu_write (cpu_tss.x86_tss.ss1, thread->sysenter_cs); +this_cpu_write (cpu_tss_rw.x86_tss.ss1, thread->sysenter_cs);wrmsr (MSR_IA32_SYSENTER_CS , thread->sysenter_cs,0 ); }#endif
arch/x86/include/asm/thread_info.h +1 -1
@@ -207,7 +207,7 @@ static inline int arch_within_stack_fram#else /* !__ASSEMBLY__ */ #ifdef CONFIG_X86_64 -# define cpu_current_top_of_stack (cpu_tss + TSS_sp1) +# define cpu_current_top_of_stack (cpu_tss_rw + TSS_sp1)#endif #endif
arch/x86/kernel/asm-offsets.c +2 -3
@@ -94,10 +94,9 @@ void common(void) {BLANK ();DEFINE (PTREGS_SIZE ,sizeof (struct pt_regs )); -OFFSET (TSS_STRUCT_SYSENTER_stack, tss_struct, SYSENTER_stack); -DEFINE (SIZEOF_SYSENTER_stack,sizeof (struct SYSENTER_stack )); -/* Layout info for cpu_entry_area */ OFFSET (CPU_ENTRY_AREA_tss, cpu_entry_area, tss);OFFSET (CPU_ENTRY_AREA_entry_trampoline, cpu_entry_area, entry_trampoline); +OFFSET (CPU_ENTRY_AREA_SYSENTER_stack, cpu_entry_area, SYSENTER_stack_page); +DEFINE (SIZEOF_SYSENTER_stack,sizeof (struct SYSENTER_stack )); }
arch/x86/kernel/asm-offsets_32.c +2 -2
@@ -47,8 +47,8 @@ void foo(void)BLANK ();/* Offset from the sysenter stack to tss.sp0 */ - DEFINE(TSS_sysenter_sp0, offsetof(struct tss_struct, x86_tss.sp0) - - offsetofend(struct tss_struct, SYSENTER_stack)); + DEFINE(TSS_sysenter_sp0, offsetof(struct cpu_entry_area, tss.x86_tss.sp0) - + offsetofend(struct cpu_entry_area, SYSENTER_stack_page.stack));#ifdef CONFIG_CC_STACKPROTECTOR BLANK ();
arch/x86/kernel/cpu/common.c +19 -10
@@ -487,6 +487,9 @@ static DEFINE_PER_CPU_PAGE_ALIGNED(char, [(N_EXCEPTION_STACKS - 1) * EXCEPTION_STKSZ + DEBUG_STKSZ]);#endif +static DEFINE_PER_CPU_PAGE_ALIGNED(struct SYSENTER_stack_page, + SYSENTER_stack_storage); +static void __init set_percpu_fixmap_pages (int idx,void *ptr,int pages,pgprot_t prot) {
@@ -500,23 +503,29 @@ static void __init setup_cpu_entry_area(#ifdef CONFIG_X86_64 extern char _entry_trampoline[]; -/* On 64-bit systems, we use a read-only fixmap GDT. */ +/* On 64-bit systems, we use a read-only fixmap GDT and TSS. */ pgprot_t gdt_prot =PAGE_KERNEL_RO ; +pgprot_t tss_prot =PAGE_KERNEL_RO ;#else /* * On native 32-bit systems, the GDT cannot be read-only because * our double fault handler uses a task gate, and entering through -* a task gate needs to change an available TSS to busy. If the GDT -* is read-only, that will triple fault. +* a task gate needs to change an available TSS to busy. If the +* GDT is read-only, that will triple fault. The TSS cannot be +* read-only because the CPU writes to it on task switches. * -* On Xen PV, the GDT must be read-only because the hypervisor requires -* it. +* On Xen PV, the GDT must be read-only because the hypervisor +* requires it. */ pgprot_t gdt_prot =boot_cpu_has (X86_FEATURE_XENPV ) ?PAGE_KERNEL_RO :PAGE_KERNEL ; +pgprot_t tss_prot =PAGE_KERNEL ;#endif __set_fixmap (get_cpu_entry_area_index (cpu, gdt),get_cpu_gdt_paddr (cpu), gdt_prot); +set_percpu_fixmap_pages (get_cpu_entry_area_index (cpu, SYSENTER_stack_page), +per_cpu_ptr (&SYSENTER_stack_storage, cpu),1 , +PAGE_KERNEL );/* * The Intel SDM says (Volume 3, 7.2.1):
@@ -539,9 +548,9 @@ static void __init setup_cpu_entry_area( offsetofend(struct tss_struct, x86_tss)) & PAGE_MASK);BUILD_BUG_ON (sizeof (struct tss_struct ) %PAGE_SIZE !=0 );set_percpu_fixmap_pages (get_cpu_entry_area_index (cpu, tss), - &per_cpu (cpu_tss, cpu), + &per_cpu (cpu_tss_rw, cpu),sizeof (struct tss_struct ) /PAGE_SIZE , -PAGE_KERNEL ); + tss_prot);#ifdef CONFIG_X86_32 per_cpu (cpu_entry_area, cpu) =get_cpu_entry_area (cpu);
@@ -1305,7 +1314,7 @@ void enable_sep_cpu(void)return ; cpu =get_cpu (); - tss = &per_cpu (cpu_tss, cpu); + tss = &per_cpu (cpu_tss_rw, cpu);/* * We cache MSR_IA32_SYSENTER_CS's value in the TSS's ss1 field --
@@ -1575,7 +1584,7 @@ void cpu_init(void)if (cpu)load_ucode_ap (); - t = &per_cpu (cpu_tss, cpu); + t = &per_cpu (cpu_tss_rw, cpu); oist = &per_cpu (orig_ist, cpu);#ifdef CONFIG_NUMA
@@ -1667,7 +1676,7 @@ void cpu_init(void) {int cpu =smp_processor_id ();struct task_struct *curr = current; -struct tss_struct *t = &per_cpu (cpu_tss, cpu); +struct tss_struct *t = &per_cpu (cpu_tss_rw, cpu);wait_for_master_cpu (cpu);
arch/x86/kernel/ioport.c +1 -1
@@ -67,7 +67,7 @@ asmlinkage long sys_ioperm(unsigned long* because the ->io_bitmap_max value must match the bitmap * contents: */ - tss = &per_cpu (cpu_tss,get_cpu ()); + tss = &per_cpu (cpu_tss_rw,get_cpu ());if (turn_on)bitmap_clear (t->io_bitmap_ptr, from, num);
arch/x86/kernel/process.c +3 -3
@@ -47,7 +47,7 @@* section. Since TSS's are completely CPU-local, we want them * on exact cacheline boundaries, to eliminate cacheline ping-pong. */ -__visible DEFINE_PER_CPU_SHARED_ALIGNED (struct tss_struct ,cpu_tss ) = { +__visible DEFINE_PER_CPU_SHARED_ALIGNED (struct tss_struct ,cpu_tss_rw ) = { .x86_tss = {/* * .sp0 is only used when entering ring 0 from a lower
@@ -82,7 +82,7 @@ __visible DEFINE_PER_CPU_SHARED_ALIGNED( .io_bitmap = { [0 ... IO_BITMAP_LONGS] = ~0 },#endif }; -EXPORT_PER_CPU_SYMBOL (cpu_tss); +EXPORT_PER_CPU_SYMBOL (cpu_tss_rw);DEFINE_PER_CPU (bool, __tss_limit_invalid);EXPORT_PER_CPU_SYMBOL_GPL (__tss_limit_invalid);
@@ -111,7 +111,7 @@ void exit_thread(struct task_struct *tskstruct fpu *fpu = &t->fpu;if (bp) { -struct tss_struct *tss = &per_cpu (cpu_tss,get_cpu ()); +struct tss_struct *tss = &per_cpu (cpu_tss_rw,get_cpu ()); t->io_bitmap_ptr =NULL ;clear_thread_flag (TIF_IO_BITMAP );
arch/x86/kernel/process_32.c +1 -1
@@ -234,7 +234,7 @@ __switch_to(struct task_struct *prev_p,struct fpu *prev_fpu = &prev->fpu;struct fpu *next_fpu = &next->fpu;int cpu =smp_processor_id (); -struct tss_struct *tss = &per_cpu (cpu_tss, cpu); +struct tss_struct *tss = &per_cpu (cpu_tss_rw, cpu);/* never put a printk in __switch_to... printk() calls wake_up*() indirectly */
arch/x86/kernel/process_64.c +1 -1
@@ -399,7 +399,7 @@ __switch_to(struct task_struct *prev_p,struct fpu *prev_fpu = &prev->fpu;struct fpu *next_fpu = &next->fpu;int cpu =smp_processor_id (); -struct tss_struct *tss = &per_cpu (cpu_tss, cpu); +struct tss_struct *tss = &per_cpu (cpu_tss_rw, cpu);WARN_ON_ONCE (IS_ENABLED (CONFIG_DEBUG_ENTRY ) &&this_cpu_read (irq_count) !=-1 );
arch/x86/kernel/traps.c +2 -2
@@ -364,7 +364,7 @@ dotraplinkage void do_double_fault(struc regs->cs == __KERNEL_CS && regs->ip == (unsigned long)native_irq_return_iret) { -struct pt_regs *gpregs = (struct pt_regs *)this_cpu_read (cpu_tss.x86_tss.sp0) -1 ; +struct pt_regs *gpregs = (struct pt_regs *)this_cpu_read (cpu_tss_rw.x86_tss.sp0) -1 ;/* * regs->sp points to the failing IRET frame on the
@@ -649,7 +649,7 @@ struct bad_iret_stack *fixup_bad_iret(st* exception came from the IRET target. */ struct bad_iret_stack *new_stack = - (struct bad_iret_stack *)this_cpu_read (cpu_tss.x86_tss.sp0) -1 ; + (struct bad_iret_stack *)this_cpu_read (cpu_tss_rw.x86_tss.sp0) -1 ;/* Copy the IRET target to the new stack. */ memmove (&new_stack->regs.ip, (void *)s->regs.sp,5 *8 );
arch/x86/lib/delay.c +2 -2
@@ -107,10 +107,10 @@ static void delay_mwaitx(unsigned long _ delay =min_t (u64,MWAITX_MAX_LOOPS , loops);/* -* Use cpu_tss as a cacheline-aligned, seldomly +* Use cpu_tss_rw as a cacheline-aligned, seldomly * accessed per-cpu variable as the monitor target. */ -__monitorx (raw_cpu_ptr (&cpu_tss),0 ,0 ); +__monitorx (raw_cpu_ptr (&cpu_tss_rw),0 ,0 );/* * AMD, like Intel, supports the EAX hint and EAX=0xf
arch/x86/xen/enlighten_pv.c +1 -1
@@ -818,7 +818,7 @@ static void xen_load_sp0(unsigned long s mcs =xen_mc_entry (0 );MULTI_stack_switch (mcs.mc, __KERNEL_DS, sp0);xen_mc_issue (PARAVIRT_LAZY_CPU ); -this_cpu_write (cpu_tss.x86_tss.sp0, sp0); +this_cpu_write (cpu_tss_rw.x86_tss.sp0, sp0); }void xen_set_iopl_mask (unsigned mask)
Greg Kroah-Hartman
maintainerPATCH 97/159 x86/paravirt: Dont patch flush_tlb_single
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
commit a035795499ca1c2bd1928808d1a156eda1420383 upstream.
native_flush_tlb_single() will be changed with the upcoming PAGE_TABLE_ISOLATION feature. This requires to have more code in there than INVLPG.
Remove the paravirt patching for it.
--- arch/x86/kernel/paravirt_patch_64.c | 2 -- 1 file changed, 2 deletions(-)
arch/x86/kernel/paravirt_patch_64.c +0 -2
@@ -10,7 +10,6 @@ DEF_NATIVE(pv_irq_ops, save_fl, "pushfq;DEF_NATIVE (pv_mmu_ops, read_cr2,"movq %cr2, %rax" );DEF_NATIVE (pv_mmu_ops, read_cr3,"movq %cr3, %rax" );DEF_NATIVE (pv_mmu_ops, write_cr3,"movq %rdi, %cr3" ); -DEF_NATIVE (pv_mmu_ops, flush_tlb_single,"invlpg (%rdi)" );DEF_NATIVE (pv_cpu_ops, wbinvd,"wbinvd" );DEF_NATIVE (pv_cpu_ops, usergs_sysret64,"swapgs; sysretq" );
@@ -60,7 +59,6 @@ unsigned native_patch(u8 type, u16 clobbPATCH_SITE (pv_mmu_ops, read_cr2);PATCH_SITE (pv_mmu_ops, read_cr3);PATCH_SITE (pv_mmu_ops, write_cr3); -PATCH_SITE (pv_mmu_ops, flush_tlb_single);PATCH_SITE (pv_cpu_ops, wbinvd);#if defined(CONFIG_PARAVIRT_SPINLOCKS )case PARAVIRT_PATCH (pv_lock_ops.queued_spin_unlock):
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Greg Kroah-Hartman
maintainerPATCH 98/159 x86/paravirt: Provide a way to check for hypervisors
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
commit 79cc74155218316b9a5d28577c7077b2adba8e58 upstream.
There is no generic way to test whether a kernel is running on a specific hypervisor. But that's required to prevent the upcoming user address space separation feature in certain guest modes.
Make the hypervisor type enum unconditionally available and provide a helper function which allows to test for a specific type.
--- arch/x86/include/asm/hypervisor.h | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-)
arch/x86/include/asm/hypervisor.h +15 -10
@@ -20,16 +20,7 @@#ifndef _ASM_X86_HYPERVISOR_H#define _ASM_X86_HYPERVISOR_H -#ifdef CONFIG_HYPERVISOR_GUEST - -#include <asm/kvm_para.h> -#include <asm/x86_init.h> -#include <asm/xen/hypervisor.h> - -/* -* x86 hypervisor information -*/ - +/* x86 hypervisor types */ enum x86_hypervisor_type {X86_HYPER_NATIVE =0 , X86_HYPER_VMWARE,
@@ -39,6 +30,12 @@ enum x86_hypervisor_type { X86_HYPER_KVM, }; +#ifdef CONFIG_HYPERVISOR_GUEST + +#include <asm/kvm_para.h> +#include <asm/x86_init.h> +#include <asm/xen/hypervisor.h> + struct hypervisor_x86 { /* Hypervisor name */ const char *name;
@@ -58,7 +55,15 @@ struct hypervisor_x86 {extern enum x86_hypervisor_type x86_hyper_type;extern void init_hypervisor_platform (void ); +static inline bool hypervisor_is_type (enum x86_hypervisor_type type) +{ +return x86_hyper_type == type; +}#else static inline void init_hypervisor_platform (void ) { } +static inline bool hypervisor_is_type (enum x86_hypervisor_type type) +{ +return type ==X86_HYPER_NATIVE ; +}#endif /* CONFIG_HYPERVISOR_GUEST */ #endif /* _ASM_X86_HYPERVISOR_H */
Greg Kroah-Hartman
maintainerPATCH 99/159 x86/cpufeatures: Make CPU bugs sticky
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
commit 6cbd2171e89b13377261d15e64384df60ecb530e upstream.
There is currently no way to force CPU bug bits like CPU feature bits. That makes it impossible to set a bug bit once at boot and have it stick for all upcoming CPUs.
Extend the force set/clear arrays to handle bug bits as well.
--- arch/x86/include/asm/cpufeature.h | 2 ++ arch/x86/include/asm/processor.h | 4 ++-- arch/x86/kernel/cpu/common.c | 6 +++--- 3 files changed, 7 insertions(+), 5 deletions(-)
arch/x86/include/asm/cpufeature.h +2 -0
@@ -135,6 +135,8 @@ extern void clear_cpu_cap(struct cpuinfoset_bit (bit, (unsigned long *)cpu_caps_set); \ } while (0) +#define setup_force_cpu_bug (bit) setup_force_cpu_cap(bit) +#if defined(CC_HAVE_ASM_GOTO ) && defined(CONFIG_X86_FAST_FEATURE_TESTS )/* * Static testing of CPU features. Used the same as boot_cpu_has().
arch/x86/include/asm/processor.h +2 -2
@@ -163,8 +163,8 @@ extern struct cpuinfo_x86 boot_cpu_data;extern struct cpuinfo_x86 new_cpu_data;extern struct x86_hw_tss doublefault_tss; -extern __u32 cpu_caps_cleared[NCAPINTS ]; -extern __u32 cpu_caps_set[NCAPINTS ]; +extern __u32 cpu_caps_cleared[NCAPINTS +NBUGINTS ]; +extern __u32 cpu_caps_set[NCAPINTS +NBUGINTS ];#ifdef CONFIG_SMP DECLARE_PER_CPU_READ_MOSTLY(struct cpuinfo_x86, cpu_info);
arch/x86/kernel/cpu/common.c +3 -3
@@ -452,8 +452,8 @@ static const char *table_lookup_model(streturn NULL ;/* Not found */ } -__u32 cpu_caps_cleared[NCAPINTS ]; -__u32 cpu_caps_set[NCAPINTS ]; +__u32 cpu_caps_cleared[NCAPINTS +NBUGINTS ]; +__u32 cpu_caps_set[NCAPINTS +NBUGINTS ];void load_percpu_segment (int cpu) {
@@ -812,7 +812,7 @@ static void apply_forced_caps(struct cpu {int i; -for (i =0 ; i <NCAPINTS ; i++) { +for (i =0 ; i <NCAPINTS +NBUGINTS ; i++) { c->x86_capability[i] &= ~cpu_caps_cleared[i]; c->x86_capability[i] |= cpu_caps_set[i]; }
Greg Kroah-Hartman
maintainerPATCH 100/159 optee: fix invalid of_node_put() in optee_driver_init()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jens Wiklander <[email protected]>
commit f044113113dd95ba73916bde10e804d3cdfa2662 upstream.
The first node supplied to of_find_matching_node() has its reference counter decreased as part of call to that function. In optee_driver_init() after calling of_find_matching_node() it's invalid to call of_node_put() on the supplied node again.
So remove the invalid call to of_node_put().
--- drivers/tee/optee/core.c | 1 - 1 file changed, 1 deletion(-)
drivers/tee/optee/core.c +0 -1
@@ -590,7 +590,6 @@ static int __init optee_driver_init(voidreturn -ENODEV ; np =of_find_matching_node (fw_np, optee_match); -of_node_put (fw_np);if (!np)return -ENODEV ;
Greg Kroah-Hartman
maintainerPATCH 101/159 backlight: pwm_bl: Fix overflow condition
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Derek Basehore <[email protected]>
[ Upstream commit 5d0c49acebc9488e37db95f1d4a55644e545ffe7 ]
This fixes an overflow condition that can happen with high max brightness and period values in compute_duty_cycle. This fixes it by using a 64 bit variable for computing the duty cycle.
--- drivers/video/backlight/pwm_bl.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/video/backlight/pwm_bl.c +5 -2
@@ -79,14 +79,17 @@ static void pwm_backlight_power_off(strustatic int compute_duty_cycle (struct pwm_bl_data *pb,int brightness) {unsigned int lth = pb->lth_brightness; -int duty_cycle; +u64 duty_cycle;if (pb->levels) duty_cycle = pb->levels[brightness];else duty_cycle = brightness; -return (duty_cycle * (pb->period - lth) / pb->scale) + lth; + duty_cycle *= pb->period - lth; +do_div (duty_cycle, pb->scale); + +return duty_cycle + lth; }static int pwm_backlight_update_status (struct backlight_device *bl)
Greg Kroah-Hartman
maintainerPATCH 102/159 drm: Add retries for lspcon mode detection
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shashank Sharma <[email protected]>
[ Upstream commit f687e25a7a245952349f1f9f9cc238ac5a3be258 ]
Quoted 1 line
Quoted 1 line
From the CI builds, its been observed that during a driver
reload/insert, dp dual mode read function sometimes fails to read from LSPCON device over i2c-over-aux channel.
This patch:
- adds some delay and few retries, allowing a scope for these devices to settle down and respond.
- changes one error log's level from ERROR->DEBUG as we want to call it an error only after all the retries are exhausted.
V2: Addressed review comments from Jani (for loop for retry)
V3: Addressed review comments from Imre (break on partial read too)
V3: Addressed review comments from Ville/Imre (Add the retries
exclusively for LSPCON, not for all dp_dual_mode devices)
V4: Added r-b from Imre, sending it to dri-devel (Jani)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102294
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102295
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102359
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103186
--- drivers/gpu/drm/drm_dp_dual_mode_helper.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-)
drivers/gpu/drm/drm_dp_dual_mode_helper.c +13 -3
@@ -410,6 +410,7 @@ int drm_lspcon_get_mode(struct i2c_adapt {u8 data;int ret =0 ; +int retry;if (!mode) {DRM_ERROR ("NULL input\n" );
@@ -417,10 +418,19 @@ int drm_lspcon_get_mode(struct i2c_adapt }/* Read Status: i2c over aux */ - ret =drm_dp_dual_mode_read (adapter,DP_DUAL_MODE_LSPCON_CURRENT_MODE , - &data,sizeof (data)); +for (retry =0 ; retry <6 ; retry++) { +if (retry) +usleep_range (500 ,1000 ); + + ret =drm_dp_dual_mode_read (adapter, +DP_DUAL_MODE_LSPCON_CURRENT_MODE , + &data,sizeof (data)); +if (!ret) +break ; + } +if (ret <0 ) { -DRM_ERROR ("LSPCON read(0x80, 0x41) failed\n" ); +DRM_DEBUG_KMS ("LSPCON read(0x80, 0x41) failed\n" );return -EFAULT ; }
Greg Kroah-Hartman
maintainerPATCH 103/159 clk: sunxi-ng: nm: Check if requested rate is supported by fractional clock
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen-Yu Tsai <[email protected]>
[ Upstream commit 4cdbc40d64d4b8303a97e29a52862e4d99502beb ]
The round_rate callback for N-M-factor style clocks does not check if the requested clock rate is supported by the fractional clock mode. While this doesn't affect usage in practice, since the clock rates are also supported through N-M factors, it does not match the set_rate code.
Add a check to the round_rate callback so it matches the set_rate callback.
--- drivers/clk/sunxi-ng/ccu_nm.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/clk/sunxi-ng/ccu_nm.c +3 -0
@@ -99,6 +99,9 @@ static long ccu_nm_round_rate(struct clkstruct ccu_nm *nm =hw_to_ccu_nm (hw);struct _ccu_nm _nm; +if (ccu_frac_helper_has_rate (&nm->common, &nm->frac, rate)) +return rate; + _nm.min_n = nm->n.min ?:1 ; _nm.max_n = nm->n.max ?:1 << nm->n.width; _nm.min_m =1 ;
Greg Kroah-Hartman
maintainerPATCH 104/159 clk: sunxi-ng: sun5i: Fix bit offset of audio PLL post-divider
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen-Yu Tsai <[email protected]>
[ Upstream commit d51fe3ba9773c8b6fc79f82bbe75d64baf604292 ]
The post-divider for the audio PLL is in bits [29:26], as specified in the user manual, not [19:16] as currently programmed in the code. The post-divider has a default register value of 2, i.e. a divider of 3. This means the clock rate fed to the audio codec would be off.
This was discovered when porting sigma-delta modulation for the PLL to sun5i, which needs the post-divider to be 1.
Fix the bit offset, so we do actually force the post-divider to a certain value.
--- drivers/clk/sunxi-ng/ccu-sun5i.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/clk/sunxi-ng/ccu-sun5i.c +2 -2
@@ -982,8 +982,8 @@ static void __init sun5i_ccu_init(struct/* Force the PLL-Audio-1x divider to 4 */ val =readl (reg +SUN5I_PLL_AUDIO_REG ); - val &= ~GENMASK (19 ,16 ); -writel (val | (3 <<16 ), reg +SUN5I_PLL_AUDIO_REG ); + val &= ~GENMASK (29 ,26 ); +writel (val | (3 <<26 ), reg +SUN5I_PLL_AUDIO_REG );/* * Use the peripheral PLL as the AHB parent, instead of CPU /
Greg Kroah-Hartman
maintainerPATCH 105/159 crypto: crypto4xx - increase context and scatter ring buffer elements
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian Lamparter <[email protected]>
[ Upstream commit 778f81d6cdb7d25360f082ac0384d5103f04eca5 ]
If crypto4xx is used in conjunction with dm-crypt, the available ring buffer elements are not enough to handle the load properly.
On an aes-cbc-essiv:sha256 encrypted swap partition the read performance is abyssal: (tested with hdparm -t)
/dev/mapper/swap_crypt:
Timing buffered disk reads: 14 MB in 3.68 seconds = 3.81 MB/sec
The patch increases both PPC4XX_NUM_SD and PPC4XX_NUM_PD to 256. This improves the performance considerably:
/dev/mapper/swap_crypt:
Timing buffered disk reads: 104 MB in 3.03 seconds = 34.31 MB/sec
Furthermore, PPC4XX_LAST_SD, PPC4XX_LAST_GD and PPC4XX_LAST_PD can be easily calculated from their respective PPC4XX_NUM_* constant.
--- drivers/crypto/amcc/crypto4xx_core.h | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/crypto/amcc/crypto4xx_core.h +5 -5
@@ -34,12 +34,12 @@#define PPC405EX_CE_RESET 0x00000008#define CRYPTO4XX_CRYPTO_PRIORITY 300 -#define PPC4XX_LAST_PD 63 -#define PPC4XX_NUM_PD 64 -#define PPC4XX_LAST_GD 1023 +#define PPC4XX_NUM_PD 256 +#define PPC4XX_LAST_PD (PPC4XX_NUM_PD - 1)#define PPC4XX_NUM_GD 1024 -#define PPC4XX_LAST_SD 63 -#define PPC4XX_NUM_SD 64 +#define PPC4XX_LAST_GD (PPC4XX_NUM_GD - 1) +#define PPC4XX_NUM_SD 256 +#define PPC4XX_LAST_SD (PPC4XX_NUM_SD - 1)#define PPC4XX_SD_BUFFER_SIZE 2048#define PD_ENTRY_INUSE 1
Greg Kroah-Hartman
maintainerPATCH 106/159 crypto: lrw - Fix an error handling path in create()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe Jaillet <[email protected]>
[ Upstream commit 616129cc6e75fb4da6681c16c981fa82dfe5e4c7 ]
All error handling paths 'goto err_drop_spawn' except this one. In order to avoid some resources leak, we should do it as well here.
--- crypto/lrw.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
crypto/lrw.c +4 -2
@@ -610,8 +610,10 @@ static int create(struct crypto_template ecb_name[len -1 ] =0 ;if (snprintf (inst->alg.base.cra_name,CRYPTO_MAX_ALG_NAME , -"lrw(%s)" , ecb_name) >=CRYPTO_MAX_ALG_NAME ) -return -ENAMETOOLONG ; +"lrw(%s)" , ecb_name) >=CRYPTO_MAX_ALG_NAME ) { + err = -ENAMETOOLONG ; + goto err_drop_spawn; + } } inst->alg.base.cra_flags = alg->base.cra_flags &CRYPTO_ALG_ASYNC ;
Greg Kroah-Hartman
maintainerPATCH 107/159 rtc: pl031: make interrupt optional
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Russell King <[email protected]>
[ Upstream commit 5b64a2965dfdfca8039e93303c64e2b15c19ff0c ]
On some platforms, the interrupt for the PL031 is optional. Avoid trying to claim the interrupt if it's not specified.
--- drivers/rtc/rtc-pl031.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-)
drivers/rtc/rtc-pl031.c +8 -6
@@ -308,7 +308,8 @@ static int pl031_remove(struct amba_devidev_pm_clear_wake_irq (&adev->dev);device_init_wakeup (&adev->dev, false); -free_irq (adev->irq[0 ], ldata); +if (adev->irq[0 ]) +free_irq (adev->irq[0 ], ldata);rtc_device_unregister (ldata->rtc);iounmap (ldata->base);kfree (ldata);
@@ -381,12 +382,13 @@ static int pl031_probe(struct amba_devic goto out_no_rtc; } -if (request_irq (adev->irq[0 ], pl031_interrupt, - vendor->irqflags,"rtc-pl031" , ldata)) { - ret = -EIO ; - goto out_no_irq; +if (adev->irq[0 ]) { + ret =request_irq (adev->irq[0 ], pl031_interrupt, + vendor->irqflags,"rtc-pl031" , ldata); +if (ret) + goto out_no_irq; +dev_pm_set_wake_irq (&adev->dev, adev->irq[0 ]); } -dev_pm_set_wake_irq (&adev->dev, adev->irq[0 ]);return 0 ; out_no_irq:
Greg Kroah-Hartman
maintainerPATCH 108/159 kvm, mm: account kvm related kmem slabs to kmemcg
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shakeel Butt <[email protected]>
[ Upstream commit 46bea48ac241fe0b413805952dda74dd0c09ba8b ]
The kvm slabs can consume a significant amount of system memory and indeed in our production environment we have observed that a lot of machines are spending significant amount of memory that can not be left as system memory overhead. Also the allocations from these slabs can be triggered directly by user space applications which has access to kvm and thus a buggy application can leak such memory. So, these caches should be accounted to kmemcg.
--- arch/x86/kvm/mmu.c | 4 ++-- virt/kvm/kvm_main.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)
arch/x86/kvm/mmu.c +2 -2
@@ -5476,13 +5476,13 @@ int kvm_mmu_module_init(void) pte_list_desc_cache =kmem_cache_create ("pte_list_desc" ,sizeof (struct pte_list_desc ), -0 ,0 ,NULL ); +0 ,SLAB_ACCOUNT ,NULL );if (!pte_list_desc_cache) goto nomem; mmu_page_header_cache =kmem_cache_create ("kvm_mmu_page_header" ,sizeof (struct kvm_mmu_page ), -0 ,0 ,NULL ); +0 ,SLAB_ACCOUNT ,NULL );if (!mmu_page_header_cache) goto nomem;
virt/kvm/kvm_main.c +1 -1
@@ -4018,7 +4018,7 @@ int kvm_init(void *opaque, unsigned vcpuif (!vcpu_align) vcpu_align = __alignof__(struct kvm_vcpu ); kvm_vcpu_cache =kmem_cache_create ("kvm_vcpu" , vcpu_size, vcpu_align, -0 ,NULL ); +SLAB_ACCOUNT ,NULL );if (!kvm_vcpu_cache) { r = -ENOMEM ; goto out_free_3;
Re: [PATCH 4.14 108/159] kvm, mm: account kvm related kmem slabs to kmemcg
Quoted 17 lines · Greg KH
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shakeel Butt <[email protected]>
[ Upstream commit
46bea48ac241fe0b413805952dda74dd0c09ba8b]The kvm slabs can consume a significant amount of system memory and indeed in our production environment we have observed that a lot of machines are spending significant amount of memory that can not be left as system memory overhead. Also the allocations from these slabs can be triggered directly by user space applications which has access to kvm and thus a buggy application can leak such memory. So, these caches should be accounted to kmemcg.
Quoted 4 lines
Signed-off-by Shakeel Butt <[email protected]>Signed-off-by Paolo Bonzini <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>
The patch is not marked for stable, neither it fixes an existing bug. It is a nice to have thing for sure but I am wondering how this got through stable-filter.
Quoted 35 lines
--- arch/x86/kvm/mmu.c | 4 ++-- virt/kvm/kvm_main.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)arch/x86/kvm/mmu.c +2
-2@@ -5476,13 +5476,13 @@ int kvm_mmu_module_init(void) pte_list_desc_cache =kmem_cache_create ("pte_list_desc" ,sizeof (struct pte_list_desc ), -0 ,0 ,NULL ); +0 ,SLAB_ACCOUNT ,NULL );if (!pte_list_desc_cache) goto nomem; mmu_page_header_cache =kmem_cache_create ("kvm_mmu_page_header" ,sizeof (struct kvm_mmu_page ), -0 ,0 ,NULL ); +0 ,SLAB_ACCOUNT ,NULL );if (!mmu_page_header_cache) goto nomem;virt/kvm/kvm_main.c +1
-1@@ -4018,7 +4018,7 @@ int kvm_init(void *opaque, unsigned vcpuif (!vcpu_align) vcpu_align = __alignof__(struct kvm_vcpu ); kvm_vcpu_cache =kmem_cache_create ("kvm_vcpu" , vcpu_size, vcpu_align, -0 ,NULL ); +SLAB_ACCOUNT ,NULL );if (!kvm_vcpu_cache) { r = -ENOMEM ; goto out_free_3;
Signature · 2 lines
Michal Hocko SUSE Labs
Greg Kroah-Hartman
maintainerRe: [PATCH 4.14 108/159] kvm, mm: account kvm related kmem slabs to kmemcg
Quoted 18 lines · Michal Hocko
Quoted 17 lines · Greg KH
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shakeel Butt <[email protected]>
[ Upstream commit
46bea48ac241fe0b413805952dda74dd0c09ba8b]The kvm slabs can consume a significant amount of system memory and indeed in our production environment we have observed that a lot of machines are spending significant amount of memory that can not be left as system memory overhead. Also the allocations from these slabs can be triggered directly by user space applications which has access to kvm and thus a buggy application can leak such memory. So, these caches should be accounted to kmemcg.
Quoted 8 lines
Quoted 4 lines
Signed-off-by Shakeel Butt <[email protected]>Signed-off-by Paolo Bonzini <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>The patch is not marked for stable, neither it fixes an existing bug. It is a nice to have thing for sure but I am wondering how this got through stable-filter.
Sasha picked it out, and it seemed like a sane thing to backport. If you think it's not worthy, I'll gladly drop it, but it seemed like such a simple bugfix to include.
thanks,
greg k-h
Re: [PATCH 4.14 108/159] kvm, mm: account kvm related kmem slabs to kmemcg
Quoted 24 lines · Greg KH
Quoted 23 lines · Michal Hocko
Quoted 21 lines · Greg KH
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shakeel Butt <[email protected]>
[ Upstream commit
46bea48ac241fe0b413805952dda74dd0c09ba8b]The kvm slabs can consume a significant amount of system memory and indeed in our production environment we have observed that a lot of machines are spending significant amount of memory that can not be left as system memory overhead. Also the allocations from these slabs can be triggered directly by user space applications which has access to kvm and thus a buggy application can leak such memory. So, these caches should be accounted to kmemcg.
Signed-off-by Shakeel Butt <[email protected]>Signed-off-by Paolo Bonzini <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>
Quoted 7 lines
Quoted 3 lines
The patch is not marked for stable, neither it fixes an existing bug. It is a nice to have thing for sure but I am wondering how this got through stable-filter.
Sasha picked it out, and it seemed like a sane thing to backport. If you think it's not worthy, I'll gladly drop it, but it seemed like such a simple bugfix to include.
It is not that I would have some specific concerns about this particular patch. It is more of a worry about the overal process. I thought that _any_ patch backported to the stable tree would require a specific bug to be fixed or in exceptional cases a performance issue. I have experienced this pushback myself when trying to push "no real bug report but better to have this plugged" patches.
So something has apparently changed in the process, I just haven't noticed it. I am worried this might lead to more regression in future. Not that my worry counts all that much as I am not a stable kernel user though. So this is just my 2c worth of worry.
Signature · 2 lines
Michal Hocko SUSE Labs
Re: [PATCH 4.14 108/159] kvm, mm: account kvm related kmem slabs to kmemcg
Quoted 40 lines · Michal Hocko
Quoted 24 lines · Greg KH
Quoted 23 lines · Michal Hocko
Quoted 21 lines · Greg KH
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shakeel Butt <[email protected]>
[ Upstream commit
46bea48ac241fe0b413805952dda74dd0c09ba8b]The kvm slabs can consume a significant amount of system memory and indeed in our production environment we have observed that a lot of machines are spending significant amount of memory that can not be left as system memory overhead. Also the allocations from these slabs can be triggered directly by user space applications which has access to kvm and thus a buggy application can leak such memory. So, these caches should be accounted to kmemcg.
Signed-off-by Shakeel Butt <[email protected]>Signed-off-by Paolo Bonzini <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>Quoted 7 lines
Quoted 3 lines
The patch is not marked for stable, neither it fixes an existing bug. It is a nice to have thing for sure but I am wondering how this got through stable-filter.
Sasha picked it out, and it seemed like a sane thing to backport. If you think it's not worthy, I'll gladly drop it, but it seemed like such a simple bugfix to include.
It is not that I would have some specific concerns about this particular patch. It is more of a worry about the overal process. I thought that _any_ patch backported to the stable tree would require a specific bug to be fixed or in exceptional cases a performance issue. I have experienced this pushback myself when trying to push "no real bug report but better to have this plugged" patches.
Quoted 4 lines
So something has apparently changed in the process, I just haven't noticed it. I am worried this might lead to more regression in future. Not that my worry counts all that much as I am not a stable kernel user though. So this is just my 2c worth of worry.
The way I see it is that stable commits are supposed to fix a bug that a user can hit/exploit, it doesn't have to have an actual user complaining about it.
For this particular commit, the way I read it is that a user can avoid his kmemcg limits (maybe maliciously), which would qualify as an actual bug we want to get fixed.
Signature · 2 lines
Thanks, Sasha
Re: [PATCH 4.14 108/159] kvm, mm: account kvm related kmem slabs to kmemcg
Quoted 46 lines · Sasha Levin
Quoted 40 lines · Michal Hocko
Quoted 24 lines · Greg KH
Quoted 23 lines · Michal Hocko
Quoted 21 lines · Greg KH
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shakeel Butt <[email protected]>
[ Upstream commit
46bea48ac241fe0b413805952dda74dd0c09ba8b]The kvm slabs can consume a significant amount of system memory and indeed in our production environment we have observed that a lot of machines are spending significant amount of memory that can not be left as system memory overhead. Also the allocations from these slabs can be triggered directly by user space applications which has access to kvm and thus a buggy application can leak such memory. So, these caches should be accounted to kmemcg.
Signed-off-by Shakeel Butt <[email protected]>Signed-off-by Paolo Bonzini <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>Quoted 7 lines
Quoted 3 lines
The patch is not marked for stable, neither it fixes an existing bug. It is a nice to have thing for sure but I am wondering how this got through stable-filter.
Sasha picked it out, and it seemed like a sane thing to backport. If you think it's not worthy, I'll gladly drop it, but it seemed like such a simple bugfix to include.
It is not that I would have some specific concerns about this particular patch. It is more of a worry about the overal process. I thought that _any_ patch backported to the stable tree would require a specific bug to be fixed or in exceptional cases a performance issue. I have experienced this pushback myself when trying to push "no real bug report but better to have this plugged" patches.
Quoted 4 lines
So something has apparently changed in the process, I just haven't noticed it. I am worried this might lead to more regression in future. Not that my worry counts all that much as I am not a stable kernel user though. So this is just my 2c worth of worry.
Quoted 7 lines
The way I see it is that stable commits are supposed to fix a bug that a user can hit/exploit, it doesn't have to have an actual user complaining about it.
For this particular commit, the way I read it is that a user can avoid his kmemcg limits (maybe maliciously), which would qualify as an actual bug we want to get fixed.
How are you going to judge all the possible relations to other subsystems? I mean there is a good reason maintainers mark patches for stable trees. How do you want to competently decide this for them? Can you do that for all subsystems?
I do not want to underestimate your judgment or misinterpret your process here but I _believe_ that picking patches based on the changelog without a deep understanding of the subsystem is really risky. We do not really have to go a long way to see that. Just look at other patch in this very thread [1]. But maybe our our understanding of the stable trees are different.
[1] http://lkml.kernel.org/r/20171222141810.dpeozmylmnj253do@xps
Signature · 2 lines
Michal Hocko SUSE Labs
Re: [PATCH 4.14 108/159] kvm, mm: account kvm related kmem slabs to kmemcg
Quoted 60 lines · Michal Hocko
Quoted 46 lines · Sasha Levin
Quoted 40 lines · Michal Hocko
Quoted 24 lines · Greg KH
Quoted 23 lines · Michal Hocko
Quoted 21 lines · Greg KH
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shakeel Butt <[email protected]>
[ Upstream commit
46bea48ac241fe0b413805952dda74dd0c09ba8b]The kvm slabs can consume a significant amount of system memory and indeed in our production environment we have observed that a lot of machines are spending significant amount of memory that can not be left as system memory overhead. Also the allocations from these slabs can be triggered directly by user space applications which has access to kvm and thus a buggy application can leak such memory. So, these caches should be accounted to kmemcg.
Signed-off-by Shakeel Butt <[email protected]>Signed-off-by Paolo Bonzini <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>Quoted 7 lines
Quoted 3 lines
The patch is not marked for stable, neither it fixes an existing bug. It is a nice to have thing for sure but I am wondering how this got through stable-filter.
Sasha picked it out, and it seemed like a sane thing to backport. If you think it's not worthy, I'll gladly drop it, but it seemed like such a simple bugfix to include.
It is not that I would have some specific concerns about this particular patch. It is more of a worry about the overal process. I thought that _any_ patch backported to the stable tree would require a specific bug to be fixed or in exceptional cases a performance issue. I have experienced this pushback myself when trying to push "no real bug report but better to have this plugged" patches.
Quoted 4 lines
So something has apparently changed in the process, I just haven't noticed it. I am worried this might lead to more regression in future. Not that my worry counts all that much as I am not a stable kernel user though. So this is just my 2c worth of worry.
Quoted 7 lines
The way I see it is that stable commits are supposed to fix a bug that a user can hit/exploit, it doesn't have to have an actual user complaining about it.
For this particular commit, the way I read it is that a user can avoid his kmemcg limits (maybe maliciously), which would qualify as an actual bug we want to get fixed.
How are you going to judge all the possible relations to other subsystems? I mean there is a good reason maintainers mark patches for stable trees. How do you want to competently decide this for them? Can you do that for all subsystems?
Quoted 6 lines
I do not want to underestimate your judgment or misinterpret your process here but I _believe_ that picking patches based on the changelog without a deep understanding of the subsystem is really risky. We do not really have to go a long way to see that. Just look at other patch in this very thread [1]. But maybe our our understanding of the stable trees are different.
I don't try and override maintainers, I mostly try to get fixes out of subsystems where maintainers/authors partially (or just don't) mark their commits for stable.
These patches also go through a much longer review process than commits that are marked for stable (there are at least 3 emails issued for each such commit, and at least 1 week (usually much more) is given for reviews).
Signature · 2 lines
Thanks, Sasha
Re: [PATCH 4.14 108/159] kvm, mm: account kvm related kmem slabs to kmemcg
Quoted 68 lines · Sasha Levin
Quoted 60 lines · Michal Hocko
Quoted 46 lines · Sasha Levin
Quoted 40 lines · Michal Hocko
Quoted 24 lines · Greg KH
Quoted 23 lines · Michal Hocko
Quoted 21 lines · Greg KH
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shakeel Butt <[email protected]>
[ Upstream commit
46bea48ac241fe0b413805952dda74dd0c09ba8b]The kvm slabs can consume a significant amount of system memory and indeed in our production environment we have observed that a lot of machines are spending significant amount of memory that can not be left as system memory overhead. Also the allocations from these slabs can be triggered directly by user space applications which has access to kvm and thus a buggy application can leak such memory. So, these caches should be accounted to kmemcg.
Signed-off-by Shakeel Butt <[email protected]>Signed-off-by Paolo Bonzini <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>Quoted 7 lines
Quoted 3 lines
The patch is not marked for stable, neither it fixes an existing bug. It is a nice to have thing for sure but I am wondering how this got through stable-filter.
Sasha picked it out, and it seemed like a sane thing to backport. If you think it's not worthy, I'll gladly drop it, but it seemed like such a simple bugfix to include.
It is not that I would have some specific concerns about this particular patch. It is more of a worry about the overal process. I thought that _any_ patch backported to the stable tree would require a specific bug to be fixed or in exceptional cases a performance issue. I have experienced this pushback myself when trying to push "no real bug report but better to have this plugged" patches.
Quoted 4 lines
So something has apparently changed in the process, I just haven't noticed it. I am worried this might lead to more regression in future. Not that my worry counts all that much as I am not a stable kernel user though. So this is just my 2c worth of worry.
Quoted 7 lines
The way I see it is that stable commits are supposed to fix a bug that a user can hit/exploit, it doesn't have to have an actual user complaining about it.
For this particular commit, the way I read it is that a user can avoid his kmemcg limits (maybe maliciously), which would qualify as an actual bug we want to get fixed.
How are you going to judge all the possible relations to other subsystems? I mean there is a good reason maintainers mark patches for stable trees. How do you want to competently decide this for them? Can you do that for all subsystems?
Quoted 6 lines
I do not want to underestimate your judgment or misinterpret your process here but I _believe_ that picking patches based on the changelog without a deep understanding of the subsystem is really risky. We do not really have to go a long way to see that. Just look at other patch in this very thread [1]. But maybe our our understanding of the stable trees are different.
Quoted 3 lines
I don't try and override maintainers, I mostly try to get fixes out of subsystems where maintainers/authors partially (or just don't) mark their commits for stable.
Well, I have see quite some MM patches and I believe we are quite good at marking patches for stable trees... I also think we we (as the whole kernel) are much better are using Fixes tag (although it is over used sometimes).
Moreover it makes more sense to push on those maintainers than try to substitude them without being so closely familiar with the subsystem. If missing backports result in bug reports then this just increase the pressure on those maintainers /me think.
Quoted 4 lines
These patches also go through a much longer review process than commits that are marked for stable (there are at least 3 emails issued for each such commit, and at least 1 week (usually much more) is given for reviews).
Does any of the maintainers read those emails? How many acks/reviewes do you get for those patches for the stable tree? To be honest I tend to ignore those patchbombs most of the time because it is simply impossible to handle them for me. I try to help backporting obvious fixes but reviewing seemingly randomly selected patch which applies and changelog looks reasonaly is simply out of my time budget. Not to mention that this is not just about the patch itself but also the tree it is applied to and other patches that are in the same pile.
Signature · 2 lines
Michal Hocko SUSE Labs
Re: [PATCH 4.14 108/159] kvm, mm: account kvm related kmem slabs to kmemcg
Quoted 9 lines · Michal Hocko
Quoted 3 lines · Sasha Levin
I don't try and override maintainers, I mostly try to get fixes out of subsystems where maintainers/authors partially (or just don't) mark their commits for stable.
Well, I have see quite some MM patches and I believe we are quite good at marking patches for stable trees... I also think we we (as the whole kernel) are much better are using Fixes tag (although it is over used sometimes).
Indeed, mm/ is probably as good as it gets in the kernel.
Quoted 4 lines
Moreover it makes more sense to push on those maintainers than try to substitude them without being so closely familiar with the subsystem. If missing backports result in bug reports then this just increase the pressure on those maintainers /me think.
Both is happening, but it's difficult to force maintainers into doing anything, as you might have guessed...
I'm hoping that one result of this work is a tool we can stick into scripts/ (maybe glue it to checkpatch) that'll alert when the patch is -stable material and suggest adding tags.
Quoted 7 lines
Quoted 4 lines
These patches also go through a much longer review process than commits that are marked for stable (there are at least 3 emails issued for each such commit, and at least 1 week (usually much more) is given for reviews).
Does any of the maintainers read those emails? How many acks/reviewes do you get for those patches for the stable tree? To be honest I tend to
I get a fair amount of reviews which seems to be slightly above what -stable tagged patches get, which is good.
Acks are not expected, and are not happening too often.
Quoted 6 lines
ignore those patchbombs most of the time because it is simply impossible to handle them for me. I try to help backporting obvious fixes but reviewing seemingly randomly selected patch which applies and changelog looks reasonaly is simply out of my time budget. Not to mention that this is not just about the patch itself but also the tree it is applied to and other patches that are in the same pile.
I'd hope that these patches aren't "random" :)
For some background, this is based on Julia Lawall's work (and paper
https://soarsmu.github.io/papers/icse12-patch.pdf).
Signature · 2 lines
Thanks, Sasha
Greg Kroah-Hartman
maintainerRe: [PATCH 4.14 108/159] kvm, mm: account kvm related kmem slabs to kmemcg
In reply to Michal HockoQuoted 60 lines · Michal Hocko
Quoted 46 lines · Sasha Levin
Quoted 40 lines · Michal Hocko
Quoted 24 lines · Greg KH
Quoted 23 lines · Michal Hocko
Quoted 21 lines · Greg KH
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shakeel Butt <[email protected]>
[ Upstream commit
46bea48ac241fe0b413805952dda74dd0c09ba8b]The kvm slabs can consume a significant amount of system memory and indeed in our production environment we have observed that a lot of machines are spending significant amount of memory that can not be left as system memory overhead. Also the allocations from these slabs can be triggered directly by user space applications which has access to kvm and thus a buggy application can leak such memory. So, these caches should be accounted to kmemcg.
Signed-off-by Shakeel Butt <[email protected]>Signed-off-by Paolo Bonzini <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>Quoted 7 lines
Quoted 3 lines
The patch is not marked for stable, neither it fixes an existing bug. It is a nice to have thing for sure but I am wondering how this got through stable-filter.
Sasha picked it out, and it seemed like a sane thing to backport. If you think it's not worthy, I'll gladly drop it, but it seemed like such a simple bugfix to include.
It is not that I would have some specific concerns about this particular patch. It is more of a worry about the overal process. I thought that _any_ patch backported to the stable tree would require a specific bug to be fixed or in exceptional cases a performance issue. I have experienced this pushback myself when trying to push "no real bug report but better to have this plugged" patches.
Quoted 4 lines
So something has apparently changed in the process, I just haven't noticed it. I am worried this might lead to more regression in future. Not that my worry counts all that much as I am not a stable kernel user though. So this is just my 2c worth of worry.
Quoted 7 lines
The way I see it is that stable commits are supposed to fix a bug that a user can hit/exploit, it doesn't have to have an actual user complaining about it.
For this particular commit, the way I read it is that a user can avoid his kmemcg limits (maybe maliciously), which would qualify as an actual bug we want to get fixed.
How are you going to judge all the possible relations to other subsystems? I mean there is a good reason maintainers mark patches for stable trees. How do you want to competently decide this for them? Can you do that for all subsystems?
Quoted 6 lines
I do not want to underestimate your judgment or misinterpret your process here but I _believe_ that picking patches based on the changelog without a deep understanding of the subsystem is really risky. We do not really have to go a long way to see that. Just look at other patch in this very thread [1]. But maybe our our understanding of the stable trees are different.
For many subsystems, the maintainers _never_ mark patches for stable. Others, they catch maybe half of the things they should be applying.
KVM is one such example of the "half" group, they mark patches as resolving CVE issues at times, yet don't mark them for stable. So when I see a patch like this, it triggers the "oh, look, KVM doing the same thing again", so I take the patch and of course cc: the developers/maintainers so they can object if they want to.
Over time you get to know what subsystems are like this and what are not. MM is one that is really good, I almost never take a mm patch without being told explicitly to do so. Others are horrible and never mark anything, so stuff has to be picked up manually through Sasha's process or through other ways.
So it's not a perfect system, but it seems to work "good enough", and if you ever have any questions about any patch, always feel free to ask, there's usually a story behind almost every one...
thanks,
greg k-h
Paolo Bonzini
maintainerRe: [PATCH 4.14 108/159] kvm, mm: account kvm related kmem slabs to kmemcg
Quoted 8 lines · Greg Kroah-Hartman
For many subsystems, the maintainers _never_ mark patches for stable. Others, they catch maybe half of the things they should be applying.
KVM is one such example of the "half" group, they mark patches as resolving CVE issues at times, yet don't mark them for stable. So when I see a patch like this, it triggers the "oh, look, KVM doing the same thing again", so I take the patch and of course cc: the developers/maintainers so they can object if they want to.
In general there are some cases where I tend to be conservative on applying the "stable" tag, for example:
1) sometimes I'm not very familiar with API changes in the other subsystems (this was the case for this patch). If I am not sure of the amount of backporting effort required, and the bug is not super important, I don't mark it as stable because I don't want to later drop a complex backport on the floor. I prefer to have fewer patches applied, but know that the fixes are backported to all branches.
2) not all bugs are equal; a WARN_ON_ONCE from a syzkaller testcase for example doesn't really matter to a cloud provider that uses KVM, because invalid API usage is not controlled by the customer. But an oops or BUG_ON probably *will* get CCed to stable. So some patches for syzkaller bugs may be CCed, some may not.
IIRC the CVE that you mention was a guest user->kernel escalation, but it didn't affect Linux guests at all, and it couldn't be fixed completely on Windows guests because Windows has another bug in the same area. Plus, I knew there would be different conflicts on all LTS branches, so I decided to not mark it for stable. I did dutifully provide a backport when someone (either you or Ben Hutchings) asked for one, though.
It does happen that Radim or I forget to Cc stable, so I'm okay with you picking up more patches than what I mark and I will happily do the backports for you. Still, there is some thought put into whether to CC stable or not. :)
Thanks,
Paolo
Quoted 9 lines
Over time you get to know what subsystems are like this and what are not. MM is one that is really good, I almost never take a mm patch without being told explicitly to do so. Others are horrible and never mark anything, so stuff has to be picked up manually through Sasha's process or through other ways.
So it's not a perfect system, but it seems to work "good enough", and if you ever have any questions about any patch, always feel free to ask, there's usually a story behind almost every one...
Greg Kroah-Hartman
maintainerPATCH 109/159 net: phy: at803x: Change error to EINVAL for invalid MAC
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Murphy <[email protected]>
[ Upstream commit fc7556877d1748ac00958822a0a3bba1d4bd9e0d ]
Change the return error code to EINVAL if the MAC address is not valid in the set_wol function.
--- drivers/net/phy/at803x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/phy/at803x.c +1 -1
@@ -167,7 +167,7 @@ static int at803x_set_wol(struct phy_dev mac = (const u8 *) ndev->dev_addr;if (!is_valid_ether_addr (mac)) -return -EFAULT ; +return -EINVAL ;for (i =0 ; i <3 ; i++) { phy_write(phydev, AT803X_MMD_ACCESS_CONTROL,
Greg Kroah-Hartman
maintainerPATCH 110/159 PCI: Avoid bus reset if bridge itself is broken
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Daney <[email protected]>
[ Upstream commit 357027786f3523d26f42391aa4c075b8495e5d28 ]
When checking to see if a PCI bus can safely be reset, we previously checked to see if any of the children had their PCI_DEV_FLAGS_NO_BUS_RESET flag set. Children marked with that flag are known not to behave well after a bus reset.
Some PCIe root port bridges also do not behave well after a bus reset, sometimes causing the devices behind the bridge to become unusable.
Add a check for PCI_DEV_FLAGS_NO_BUS_RESET being set in the bridge device to allow these bridges to be flagged, and prevent their secondary buses from being reset.
--- drivers/pci/pci.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/pci/pci.c +4 -0
@@ -4356,6 +4356,10 @@ static bool pci_bus_resetable(struct pci {struct pci_dev *dev; + +if (bus->self && (bus->self->dev_flags &PCI_DEV_FLAGS_NO_BUS_RESET )) +return false; +list_for_each_entry (dev, &bus->devices, bus_list) {if (dev->dev_flags &PCI_DEV_FLAGS_NO_BUS_RESET || (dev->subordinate && !pci_bus_resetable (dev->subordinate)))
Greg Kroah-Hartman
maintainerPATCH 111/159 scsi: cxgb4i: fix Tx skb leak
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Varun Prakash <[email protected]>
[ Upstream commit 9b3a081fb62158b50bcc90522ca2423017544367 ]
In case of connection reset Tx skb queue can have some skbs which are not transmitted so purge Tx skb queue in release_offload_resources() to avoid skb leak.
--- drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 1 + 1 file changed, 1 insertion(+)
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c +1 -0
@@ -1575,6 +1575,7 @@ static void release_offload_resources(st csk, csk->state, csk->flags, csk->tid);cxgbi_sock_free_cpl_skbs (csk); +cxgbi_sock_purge_write_queue (csk);if (csk->wr_cred != csk->wr_max_cred) {cxgbi_sock_purge_wr_queue (csk);cxgbi_sock_reset_wr_list (csk);
Greg Kroah-Hartman
maintainerPATCH 112/159 scsi: mpt3sas: Fix IO error occurs on pulling out a drive from RAID1 volume created on two SATA drive
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sreekanth Reddy <[email protected]>
[ Upstream commit 2ce9a3645299ba1752873d333d73f67620f4550b ]
Whenever an I/O for a RAID volume fails with IOCStatus MPI2_IOCSTATUS_SCSI_IOC_TERMINATED and SCSIStatus equal to (MPI2_SCSI_STATE_TERMINATED | MPI2_SCSI_STATE_NO_SCSI_STATUS) then return the I/O to SCSI midlayer with "DID_RESET" (i.e. retry the IO infinite times) set in the host byte.
Previously, the driver was completing the I/O with "DID_SOFT_ERROR" which causes the I/O to be quickly retried. However, firmware needed more time and hence I/Os were failing.
--- drivers/scsi/mpt3sas/mpt3sas_scsih.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/scsi/mpt3sas/mpt3sas_scsih.c +5 -0
@@ -4804,6 +4804,11 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *i }else if (log_info ==VIRTUAL_IO_FAILED_RETRY ) { scmd->result =DID_RESET <<16 ;break ; + }else if ((scmd->device->channel ==RAID_CHANNEL ) && + (scsi_state == (MPI2_SCSI_STATE_TERMINATED | +MPI2_SCSI_STATE_NO_SCSI_STATUS ))) { + scmd->result =DID_RESET <<16 ; +break ; } scmd->result =DID_SOFT_ERROR <<16 ;break ;
Greg Kroah-Hartman
maintainerPATCH 113/159 PCI: Create SR-IOV virtfn/physfn links before attaching driver
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stuart Hayes <[email protected]>
[ Upstream commit 27d6162944b9b34c32cd5841acd21786637ee743 ]
When creating virtual functions, create the "virtfn%u" and "physfn" links in sysfs *before* attaching the driver instead of after. When we attach the driver to the new virtual network interface first, there is a race when the driver attaches to the new sends out an "add" udev event, and the network interface naming software (biosdevname or systemd, for example) tries to look at these links.
--- drivers/pci/iov.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/pci/iov.c +2 -1
@@ -162,7 +162,6 @@ int pci_iov_add_virtfn(struct pci_dev *dpci_device_add (virtfn, virtfn->bus); -pci_bus_add_device (virtfn);sprintf (buf,"virtfn%u" , id); rc =sysfs_create_link (&dev->dev.kobj, &virtfn->dev.kobj, buf);if (rc)
@@ -173,6 +172,8 @@ int pci_iov_add_virtfn(struct pci_dev *dkobject_uevent (&virtfn->dev.kobj,KOBJ_CHANGE ); +pci_bus_add_device (virtfn); +return 0 ; failed2:
Greg Kroah-Hartman
maintainerPATCH 114/159 PM / OPP: Move error message to debug level
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Fabio Estevam <[email protected]>
[ Upstream commit 035ed07208dc501d023873447113f3f178592156 ]
On some i.MX6 platforms which do not have speed grading check, opp table will not be created in platform code, so cpufreq driver prints the following error message:
cpu cpu0: dev_pm_opp_get_opp_count: OPP table not found (-19)
However, this is not really an error in this case because the imx6q-cpufreq driver first calls dev_pm_opp_get_opp_count() and if it fails, it means that platform code does not provide OPP and then dev_pm_opp_of_add_table() will be called.
In order to avoid such confusing error message, move it to debug level.
It is up to the caller of dev_pm_opp_get_opp_count() to check its return value and decide if it will print an error or not.
--- drivers/base/power/opp/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/base/power/opp/core.c +1 -1
@@ -296,7 +296,7 @@ int dev_pm_opp_get_opp_count(struct devi opp_table =_find_opp_table (dev);if (IS_ERR (opp_table)) { count =PTR_ERR (opp_table); -dev_err (dev,"%s: OPP table not found (%d)\n" , +dev_dbg (dev,"%s: OPP table not found (%d)\n" , __func__, count);return count; }
Greg Kroah-Hartman
maintainerPATCH 115/159 igb: check memory allocation failure
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe JAILLET <[email protected]>
[ Upstream commit 18eb86362a52f0af933cc0fd5e37027317eb2d1c ]
Check memory allocation failures and return -ENOMEM in such cases, as already done for other memory allocations in this function.
This avoids NULL pointers dereference.
--- drivers/net/ethernet/intel/igb/igb_main.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/ethernet/intel/igb/igb_main.c +2 -0
@@ -3162,6 +3162,8 @@ static int igb_sw_init(struct igb_adapte/* Setup and initialize a copy of the hw vlan table array */ adapter->shadow_vfta =kcalloc (E1000_VLAN_FILTER_TBL_SIZE ,sizeof (u32),GFP_ATOMIC ); +if (!adapter->shadow_vfta) +return -ENOMEM ;/* This call may decrease the number of queues */ if (igb_init_interrupt_scheme (adapter, true)) {
Greg Kroah-Hartman
maintainerPATCH 116/159 i40e: use the safe hash table iterator when deleting mac filters
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lihong Yang <[email protected]>
[ Upstream commit 784548c40d6f43eff2297220ad7800dc04be03c6 ]
This patch replaces hash_for_each function with hash_for_each_safe when calling __i40e_del_filter. The hash_for_each_safe function is the right one to use when iterating over a hash table to safely remove a hash entry. Otherwise, incorrect values may be read from freed memory.
Detected by CoverityScan, CID 1402048 Read from pointer after free
--- drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c +2 -1
@@ -2779,6 +2779,7 @@ int i40e_ndo_set_vf_mac(struct net_devicstruct i40e_mac_filter *f;struct i40e_vf *vf;int ret =0 ; +struct hlist_node *h;int bkt;/* validate the request */
@@ -2817,7 +2818,7 @@ int i40e_ndo_set_vf_mac(struct net_devic/* Delete all the filters for this VSI - we're going to kill it * anyway. */ -hash_for_each (vsi->mac_filter_hash, bkt, f, hlist) +hash_for_each_safe (vsi->mac_filter_hash, bkt, h, f, hlist)__i40e_del_filter (vsi, f);spin_unlock_bh (&vsi->mac_filter_hash_lock);
Greg Kroah-Hartman
maintainerPATCH 117/159 iio: st_sensors: add register mask for status register
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lorenzo Bianconi <[email protected]>
[ Upstream commit e72a060151e5bb673af24993665e270fc4f674a7 ]
Introduce register mask for data-ready status register since pressure sensors (e.g. LPS22HB) export just two channels (BIT(0) and BIT(1)) and BIT(2) is marked reserved while in st_sensors_new_samples_available() value read from status register is masked using 0x7.
Moreover do not mask status register using active_scan_mask since now status value is properly masked and if the result is not zero the interrupt has to be consumed by the driver. This fix an issue on LPS25H and LPS331AP where channel definition is swapped respect to status register.
Furthermore that change allows to properly support new devices (e.g LIS2DW12) that report just ZYXDA (data-ready) field in status register to figure out if the interrupt has been generated by the device.
--- drivers/iio/accel/st_accel_core.c | 35 ++++++++++++++++----- drivers/iio/common/st_sensors/st_sensors_core.c | 2 - drivers/iio/common/st_sensors/st_sensors_trigger.c | 16 ++------- drivers/iio/gyro/st_gyro_core.c | 15 +++++++-- drivers/iio/magnetometer/st_magn_core.c | 10 ++++-- drivers/iio/pressure/st_pressure_core.c | 15 +++++++-- include/linux/iio/common/st_sensors.h | 7 +++- 7 files changed, 70 insertions(+), 30 deletions(-)
drivers/iio/accel/st_accel_core.c +28 -7
@@ -164,7 +164,10 @@ static const struct st_sensor_settings s .mask_int2 = 0x00, .addr_ihl = 0x25, .mask_ihl = 0x02, - .addr_stat_drdy = ST_SENSORS_DEFAULT_STAT_ADDR, + .stat_drdy = { + .addr = ST_SENSORS_DEFAULT_STAT_ADDR, + .mask = 0x07, + }, }, .sim = { .addr = 0x23,
@@ -236,7 +239,10 @@ static const struct st_sensor_settings s .mask_ihl = 0x80, .addr_od = 0x22, .mask_od = 0x40, - .addr_stat_drdy = ST_SENSORS_DEFAULT_STAT_ADDR, + .stat_drdy = { + .addr = ST_SENSORS_DEFAULT_STAT_ADDR, + .mask = 0x07, + }, }, .sim = { .addr = 0x23,
@@ -318,7 +324,10 @@ static const struct st_sensor_settings s .mask_int2 = 0x00, .addr_ihl = 0x23, .mask_ihl = 0x40, - .addr_stat_drdy = ST_SENSORS_DEFAULT_STAT_ADDR, + .stat_drdy = { + .addr = ST_SENSORS_DEFAULT_STAT_ADDR, + .mask = 0x07, + }, .ig1 = { .en_addr = 0x23, .en_mask = 0x08,
@@ -389,7 +398,10 @@ static const struct st_sensor_settings s .drdy_irq = { .addr = 0x21, .mask_int1 = 0x04, - .addr_stat_drdy = ST_SENSORS_DEFAULT_STAT_ADDR, + .stat_drdy = { + .addr = ST_SENSORS_DEFAULT_STAT_ADDR, + .mask = 0x07, + }, }, .sim = { .addr = 0x21,
@@ -451,7 +463,10 @@ static const struct st_sensor_settings s .mask_ihl = 0x80, .addr_od = 0x22, .mask_od = 0x40, - .addr_stat_drdy = ST_SENSORS_DEFAULT_STAT_ADDR, + .stat_drdy = { + .addr = ST_SENSORS_DEFAULT_STAT_ADDR, + .mask = 0x07, + }, }, .sim = { .addr = 0x21,
@@ -569,7 +584,10 @@ static const struct st_sensor_settings s .drdy_irq = { .addr = 0x21, .mask_int1 = 0x04, - .addr_stat_drdy = ST_SENSORS_DEFAULT_STAT_ADDR, + .stat_drdy = { + .addr = ST_SENSORS_DEFAULT_STAT_ADDR, + .mask = 0x07, + }, }, .sim = { .addr = 0x21,
@@ -640,7 +658,10 @@ static const struct st_sensor_settings s .mask_int2 = 0x00, .addr_ihl = 0x25, .mask_ihl = 0x02, - .addr_stat_drdy = ST_SENSORS_DEFAULT_STAT_ADDR, + .stat_drdy = { + .addr = ST_SENSORS_DEFAULT_STAT_ADDR, + .mask = 0x07, + }, }, .sim = { .addr = 0x23,
drivers/iio/common/st_sensors/st_sensors_core.c +1 -1
@@ -470,7 +470,7 @@ int st_sensors_set_dataready_irq(struct* different one. Take into account irq status register * to understand if irq trigger can be properly supported */ -if (sdata->sensor_settings->drdy_irq.addr_stat_drdy) +if (sdata->sensor_settings->drdy_irq.stat_drdy.addr) sdata->hw_irq_trigger = enable;return 0 ; }
drivers/iio/common/st_sensors/st_sensors_trigger.c +4 -12
@@ -31,7 +31,7 @@ static int st_sensors_new_samples_availaint ret;/* How would I know if I can't check it? */ -if (!sdata->sensor_settings->drdy_irq.addr_stat_drdy) +if (!sdata->sensor_settings->drdy_irq.stat_drdy.addr)return -EINVAL ;/* No scan mask, no interrupt */
@@ -39,23 +39,15 @@ static int st_sensors_new_samples_availareturn 0 ; ret = sdata->tf->read_byte (&sdata->tb, sdata->dev, - sdata->sensor_settings->drdy_irq.addr_stat_drdy, + sdata->sensor_settings->drdy_irq.stat_drdy.addr, &status);if (ret <0 ) {dev_err (sdata->dev,"error checking samples available\n" );return ret; } -/* -* the lower bits of .active_scan_mask[0] is directly mapped -* to the channels on the sensor: either bit 0 for -* one-dimensional sensors, or e.g. x,y,z for accelerometers, -* gyroscopes or magnetometers. No sensor use more than 3 -* channels, so cut the other status bits here. -*/ - status &=0x07 ; -if (status & (u8 )indio_dev->active_scan_mask[0 ]) +if (status & sdata->sensor_settings->drdy_irq.stat_drdy.mask)return 1 ;return 0 ;
@@ -212,7 +204,7 @@ int st_sensors_allocate_trigger(struct i* it was "our" interrupt. */ if (sdata->int_pin_open_drain && - sdata->sensor_settings->drdy_irq.addr_stat_drdy) + sdata->sensor_settings->drdy_irq.stat_drdy.addr) irq_trig |=IRQF_SHARED ; err = request_threaded_irq(sdata->get_irq_data_ready(indio_dev),
drivers/iio/gyro/st_gyro_core.c +12 -3
@@ -118,7 +118,10 @@ static const struct st_sensor_settings s* drain settings, but only for INT1 and not * for the DRDY line on INT2. */ - .addr_stat_drdy = ST_SENSORS_DEFAULT_STAT_ADDR, + .stat_drdy = { + .addr = ST_SENSORS_DEFAULT_STAT_ADDR, + .mask = 0x07, + }, }, .multi_read_bit = true, .bootime = 2,
@@ -188,7 +191,10 @@ static const struct st_sensor_settings s* drain settings, but only for INT1 and not * for the DRDY line on INT2. */ - .addr_stat_drdy = ST_SENSORS_DEFAULT_STAT_ADDR, + .stat_drdy = { + .addr = ST_SENSORS_DEFAULT_STAT_ADDR, + .mask = 0x07, + }, }, .multi_read_bit = true, .bootime = 2,
@@ -253,7 +259,10 @@ static const struct st_sensor_settings s* drain settings, but only for INT1 and not * for the DRDY line on INT2. */ - .addr_stat_drdy = ST_SENSORS_DEFAULT_STAT_ADDR, + .stat_drdy = { + .addr = ST_SENSORS_DEFAULT_STAT_ADDR, + .mask = 0x07, + }, }, .multi_read_bit = true, .bootime = 2,
drivers/iio/magnetometer/st_magn_core.c +8 -2
@@ -317,7 +317,10 @@ static const struct st_sensor_settings s }, .drdy_irq = {/* drdy line is routed drdy pin */ - .addr_stat_drdy = ST_SENSORS_DEFAULT_STAT_ADDR, + .stat_drdy = { + .addr = ST_SENSORS_DEFAULT_STAT_ADDR, + .mask = 0x07, + }, }, .multi_read_bit = true, .bootime = 2,
@@ -361,7 +364,10 @@ static const struct st_sensor_settings s .drdy_irq = { .addr = 0x62, .mask_int1 = 0x01, - .addr_stat_drdy = 0x67, + .stat_drdy = { + .addr = 0x67, + .mask = 0x07, + }, }, .multi_read_bit = false, .bootime = 2,
drivers/iio/pressure/st_pressure_core.c +12 -3
@@ -287,7 +287,10 @@ static const struct st_sensor_settings s .mask_ihl = 0x80, .addr_od = 0x22, .mask_od = 0x40, - .addr_stat_drdy = ST_SENSORS_DEFAULT_STAT_ADDR, + .stat_drdy = { + .addr = ST_SENSORS_DEFAULT_STAT_ADDR, + .mask = 0x03, + }, }, .multi_read_bit = true, .bootime = 2,
@@ -395,7 +398,10 @@ static const struct st_sensor_settings s .mask_ihl = 0x80, .addr_od = 0x22, .mask_od = 0x40, - .addr_stat_drdy = ST_SENSORS_DEFAULT_STAT_ADDR, + .stat_drdy = { + .addr = ST_SENSORS_DEFAULT_STAT_ADDR, + .mask = 0x03, + }, }, .multi_read_bit = true, .bootime = 2,
@@ -454,7 +460,10 @@ static const struct st_sensor_settings s .mask_ihl = 0x80, .addr_od = 0x12, .mask_od = 0x40, - .addr_stat_drdy = ST_SENSORS_DEFAULT_STAT_ADDR, + .stat_drdy = { + .addr = ST_SENSORS_DEFAULT_STAT_ADDR, + .mask = 0x03, + }, }, .multi_read_bit = false, .bootime = 2,
include/linux/iio/common/st_sensors.h +5 -2
@@ -139,7 +139,7 @@ struct st_sensor_das {* @mask_ihl: mask to enable/disable active low on the INT lines. * @addr_od: address to enable/disable Open Drain on the INT lines. * @mask_od: mask to enable/disable Open Drain on the INT lines. -* @addr_stat_drdy: address to read status of DRDY (data ready) interrupt +* struct stat_drdy - status register of DRDY (data ready) interrupt. * struct ig1 - represents the Interrupt Generator 1 of sensors. * @en_addr: address of the enable ig1 register. * @en_mask: mask to write the on/off value for enable.
@@ -152,7 +152,10 @@ struct st_sensor_data_ready_irq {u8 mask_ihl;u8 addr_od;u8 mask_od; -u8 addr_stat_drdy; +struct { +u8 addr; +u8 mask; + } stat_drdy;struct {u8 en_addr;u8 en_mask;
Greg Kroah-Hartman
maintainerPATCH 118/159 ixgbe: fix use of uninitialized padding
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Emil Tantilov <[email protected]>
[ Upstream commit dcfd6b839c998bc9838e2a47f44f37afbdf3099c ]
This patch is resolving Coverity hits where padding in a structure could be used uninitialized.
- Initialize fwd_cmd.pad/2 before ixgbe_calculate_checksum()
- Initialize buffer.pad2/3 before ixgbe_hic_unlocked()
--- drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 4 ++-- drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 2 ++ 2 files changed, 4 insertions(+), 2 deletions(-)
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c +2 -2
@@ -3781,10 +3781,10 @@ s32 ixgbe_set_fw_drv_ver_generic(struct fw_cmd.ver_build = build; fw_cmd.ver_sub = sub; fw_cmd.hdr.checksum =0 ; - fw_cmd.hdr.checksum =ixgbe_calculate_checksum ((u8 *)&fw_cmd, - (FW_CEM_HDR_LEN + fw_cmd.hdr.buf_len)); fw_cmd.pad =0 ; fw_cmd.pad2 =0 ; + fw_cmd.hdr.checksum =ixgbe_calculate_checksum ((u8 *)&fw_cmd, + (FW_CEM_HDR_LEN + fw_cmd.hdr.buf_len));for (i =0 ; i <=FW_CEM_MAX_RETRIES ; i++) { ret_val = ixgbe_host_interface_command(hw, &fw_cmd,
drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c +2 -0
@@ -900,6 +900,8 @@ static s32 ixgbe_read_ee_hostif_buffer_X/* convert offset from words to bytes */ buffer.address =cpu_to_be32 ((offset + current_word) *2 ); buffer.length =cpu_to_be16 (words_to_read *2 ); + buffer.pad2 =0 ; + buffer.pad3 =0 ; status =ixgbe_hic_unlocked (hw, (u32 *)&buffer,sizeof (buffer),IXGBE_HI_COMMAND_TIMEOUT );
Greg Kroah-Hartman
maintainerPATCH 119/159 IB/rxe: check for allocation failure on elem
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Colin Ian King <[email protected]>
[ Upstream commit 4831ca9e4a8e48cb27e0a792f73250390827a228 ]
The allocation for elem may fail (especially because we're using GFP_ATOMIC) so best to check for a null return. This fixes a potential null pointer dereference when assigning elem->pool.
Detected by CoverityScan CID#1357507 ("Dereference null return value")
--- drivers/infiniband/sw/rxe/rxe_pool.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/infiniband/sw/rxe/rxe_pool.c +2 -0
@@ -404,6 +404,8 @@ void *rxe_alloc(struct rxe_pool *pool) elem =kmem_cache_zalloc (pool_cache (pool), (pool->flags &RXE_POOL_ATOMIC ) ?GFP_ATOMIC :GFP_KERNEL ); +if (!elem) +return NULL ; elem->pool = pool;kref_init (&elem->ref_cnt);
Greg Kroah-Hartman
maintainerPATCH 120/159 block,bfq: Disable writeback throttling
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luca Miccio <[email protected]>
[ Upstream commit b5dc5d4d1f4ff9032eb6c21a3c571a1317dc9289 ]
Similarly to CFQ, BFQ has its write-throttling heuristics, and it is better not to combine them with further write-throttling heuristics of a different nature.
So this commit disables write-back throttling for a device if BFQ is used as I/O scheduler for that device.
--- block/bfq-iosched.c | 3 ++- block/blk-wbt.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-)
block/bfq-iosched.c +2 -1
@@ -108,6 +108,7 @@#include "blk-mq-tag.h" #include "blk-mq-sched.h" #include "bfq-iosched.h" +#include "blk-wbt.h" #define BFQ_BFQQ_FNS (name) \ void bfq_mark_bfqq_##name(struct bfq_queue *bfqq) \
@@ -4775,7 +4776,7 @@ static int bfq_init_queue(struct requestbfq_init_root_group (bfqd->root_group, bfqd);bfq_init_entity (&bfqd->oom_bfqq.entity, bfqd->root_group); - +wbt_disable_default (q);return 0 ; out_free:
block/blk-wbt.c +1 -1
@@ -654,7 +654,7 @@ void wbt_set_write_cache(struct rq_wb *r }/* -* Disable wbt, if enabled by default. Only called from CFQ. +* Disable wbt, if enabled by default. */ void wbt_disable_default (struct request_queue *q) {
Greg Kroah-Hartman
maintainerPATCH 121/159 md: always set THREAD_WAKEUP and wake up wqueue if thread existed
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guoqing Jiang <[email protected]>
[ Upstream commit d1d90147c9680aaec4a5757932c2103c42c9c23b ]
Since commit 4ad23a976413 ("MD: use per-cpu counter for writes_pending"), the wait_queue is only got invoked if THREAD_WAKEUP is not set previously.
With above change, I can see process_metadata_update could always hang on the wait queue, because mddev->thread could stay on 'D' status and the THREAD_WAKEUP flag is not cleared since there are lots of place to wake up mddev->thread. Then deadlock happened as follows:
linux175:~ # ps aux|grep md|grep D
root 20117 0.0 0.0 0 0 ? D 03:45 0:00 [md0_raid1] root 20125 0.0 0.0 0 0 ? D 03:45 0:00 [md0_cluster_rec] linux175:~ # cat /proc/20117/stack [<ffffffffa0635604>] dlm_lock_sync+0x94/0xd0 [md_cluster] [<ffffffffa0635674>] lock_token+0x34/0xd0 [md_cluster] [<ffffffffa0635804>] metadata_update_start+0x64/0x110 [md_cluster] [<ffffffffa04d985b>] md_update_sb.part.58+0x9b/0x860 [md_mod] [<ffffffffa04da035>] md_update_sb+0x15/0x30 [md_mod] [<ffffffffa04dc066>] md_check_recovery+0x266/0x490 [md_mod] [<ffffffffa06450e2>] raid1d+0x42/0x810 [raid1] [<ffffffffa04d2252>] md_thread+0x122/0x150 [md_mod] [<ffffffff81091741>] kthread+0x101/0x140 linux175:~ # cat /proc/20125/stack [<ffffffffa0636679>] recv_daemon+0x3f9/0x5c0 [md_cluster] [<ffffffffa04d2252>] md_thread+0x122/0x150 [md_mod] [<ffffffff81091741>] kthread+0x101/0x140
So let's revert the part of code in the commit to resovle the problem since we can't get lots of benefits of previous change.
--- drivers/md/md.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/md/md.c +2 -2
@@ -7468,8 +7468,8 @@ void md_wakeup_thread(struct md_thread * {if (thread) {pr_debug ("md: waking up MD thread %s.\n" , thread->tsk->comm); -if (!test_and_set_bit (THREAD_WAKEUP , &thread->flags)) -wake_up (&thread->wqueue); +set_bit (THREAD_WAKEUP , &thread->flags); +wake_up (&thread->wqueue); } }EXPORT_SYMBOL (md_wakeup_thread);
Greg Kroah-Hartman
maintainerPATCH 122/159 ip_gre: check packet length and mtu correctly in erspan tx
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: William Tu <[email protected]>
[ Upstream commit f192970de860d3ab90aa9e2a22853201a57bde78 ]
Similarly to early patch for erspan_xmit(), the ARPHDR_ETHER device is the length of the whole ether packet. So skb->len should subtract the dev->hard_header_len.
--- net/ipv4/ip_gre.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
net/ipv4/ip_gre.c +4 -4
@@ -579,8 +579,8 @@ static void erspan_fb_xmit(struct sk_bufif (gre_handle_offloads (skb, false)) goto err_free_rt; -if (skb->len > dev->mtu) { -pskb_trim (skb, dev->mtu); +if (skb->len > dev->mtu + dev->hard_header_len) { +pskb_trim (skb, dev->mtu + dev->hard_header_len); truncate = true; }
@@ -731,8 +731,8 @@ static netdev_tx_t erspan_xmit(struct skif (skb_cow_head (skb, dev->needed_headroom)) goto free_skb; -if (skb->len - dev->hard_header_len > dev->mtu) { -pskb_trim (skb, dev->mtu); +if (skb->len > dev->mtu + dev->hard_header_len) { +pskb_trim (skb, dev->mtu + dev->hard_header_len); truncate = true; }
Greg Kroah-Hartman
maintainerPATCH 123/159 ipv6: grab rt->rt6i_ref before allocating pcpu rt
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Wang <[email protected]>
[ Upstream commit a94b9367e044ba672c9f4105eb1516ff6ff4948a ]
After rwlock is replaced with rcu and spinlock, ip6_pol_route() will be called with only rcu held. That means rt6 route deletion could happen simultaneously with rt6_make_pcpu_rt(). This could potentially cause memory leak if rt6_release() is called right before rt6_make_pcpu_rt() on the same route.
This patch grabs rt->rt6i_ref safely before calling rt6_make_pcpu_rt() to make sure rt6_release() will not get triggered while rt6_make_pcpu_rt() is in progress. And rt6_release() is called after rt6_make_pcpu_rt() is finished.
Note: As we are incrementing rt->rt6i_ref in ip6_pol_route(), there is a very slim chance that fib6_purge_rt() will be triggered unnecessarily when deleting a route if ip6_pol_route() running on another thread picks this route as well and tries to make pcpu cache for it.
--- net/ipv6/route.c | 58 +++++++++++++++++++++++++++---------------------------- 1 file changed, 29 insertions(+), 29 deletions(-)
net/ipv6/route.c +29 -29
@@ -1055,7 +1055,6 @@ static struct rt6_info *rt6_get_pcpu_roustatic struct rt6_info *rt6_make_pcpu_route (struct rt6_info *rt) { -struct fib6_table *table = rt->rt6i_table;struct rt6_info *pcpu_rt, *prev, **p; pcpu_rt =ip6_rt_pcpu_alloc (rt);
@@ -1066,28 +1065,20 @@ static struct rt6_info *rt6_make_pcpu_roreturn net->ipv6.ip6_null_entry; } -read_lock_bh (&table->tb6_lock); -if (rt->rt6i_pcpu) { - p =this_cpu_ptr (rt->rt6i_pcpu); - prev =cmpxchg (p,NULL , pcpu_rt); -if (prev) { -/* If someone did it before us, return prev instead */ -dst_release_immediate (&pcpu_rt->dst); - pcpu_rt = prev; - } - }else { -/* rt has been removed from the fib6 tree -* before we have a chance to acquire the read_lock. -* In this case, don't brother to create a pcpu rt -* since rt is going away anyway. The next -* dst_check() will trigger a re-lookup. -*/ +dst_hold (&pcpu_rt->dst); + p =this_cpu_ptr (rt->rt6i_pcpu); + prev =cmpxchg (p,NULL , pcpu_rt); +if (prev) { +/* If someone did it before us, return prev instead */ +/* release refcnt taken by ip6_rt_pcpu_alloc() */ +dst_release_immediate (&pcpu_rt->dst); +/* release refcnt taken by above dst_hold() */ dst_release_immediate (&pcpu_rt->dst); - pcpu_rt = rt; +dst_hold (&prev->dst); + pcpu_rt = prev; } -dst_hold (&pcpu_rt->dst); +rt6_dst_from_metrics_check (pcpu_rt); -read_unlock_bh (&table->tb6_lock);return pcpu_rt; }
@@ -1177,19 +1168,28 @@ redo_rt6_select:if (pcpu_rt) {read_unlock_bh (&table->tb6_lock); }else { -/* We have to do the read_unlock first -* because rt6_make_pcpu_route() may trigger -* ip6_dst_gc() which will take the write_lock. -*/ -dst_hold (&rt->dst); -read_unlock_bh (&table->tb6_lock); - pcpu_rt =rt6_make_pcpu_route (rt); -dst_release (&rt->dst); +/* atomic_inc_not_zero() is needed when using rcu */ +if (atomic_inc_not_zero (&rt->rt6i_ref)) { +/* We have to do the read_unlock first +* because rt6_make_pcpu_route() may trigger +* ip6_dst_gc() which will take the write_lock. +* +* No dst_hold() on rt is needed because grabbing +* rt->rt6i_ref makes sure rt can't be released. +*/ +read_unlock_bh (&table->tb6_lock); + pcpu_rt =rt6_make_pcpu_route (rt); +rt6_release (rt); + }else { +/* rt is already removed from tree */ +read_unlock_bh (&table->tb6_lock); + pcpu_rt = net->ipv6.ip6_null_entry; +dst_hold (&pcpu_rt->dst); + } }trace_fib6_table_lookup (net, pcpu_rt, table->tb6_id, fl6);return pcpu_rt; - } }EXPORT_SYMBOL_GPL (ip6_pol_route);
Greg Kroah-Hartman
maintainerPATCH 125/159 Bluetooth: hci_uart_set_flow_control: Fix NULL deref when using serdev
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
[ Upstream commit 7841d554809b518a22349e7e39b6b63f8a48d0fb ]
Fix a NULL pointer deref (hu->tty) when calling hci_uart_set_flow_control on hci_uart-s using serdev.
--- drivers/bluetooth/hci_ldisc.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/bluetooth/hci_ldisc.c +7 -0
@@ -41,6 +41,7 @@#include <linux/ioctl.h> #include <linux/skbuff.h> #include <linux/firmware.h> +#include <linux/serdev.h> #include <net/bluetooth/bluetooth.h> #include <net/bluetooth/hci_core.h>
@@ -298,6 +299,12 @@ void hci_uart_set_flow_control(struct hcunsigned int set =0 ;unsigned int clear =0 ; +if (hu->serdev) { +serdev_device_set_flow_control (hu->serdev, !enable); +serdev_device_set_rts (hu->serdev, !enable); +return ; + } +if (enable) {/* Disable hardware flow control */ ktermios = tty->termios;
Greg Kroah-Hartman
maintainerPATCH 126/159 Bluetooth: hci_bcm: Fix setting of irq trigger type
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
[ Upstream commit 227630cccdbb8f8a1b24ac26517b75079c9a69c9 ]
This commit fixes 2 issues with host-wake irq trigger type handling in hci_bcm:
1) bcm_setup_sleep sets sleep_params.host_wake_active based on bcm_device.irq_polarity, but bcm_request_irq was always requesting IRQF_TRIGGER_RISING as trigger type independent of irq_polarity.
This was a problem when the irq is described as a GpioInt rather then an Interrupt in the DSDT as for GpioInt-s the value passed to request_irq is honored. This commit fixes this by requesting the correct trigger type depending on bcm_device.irq_polarity.
2) bcm_device.irq_polarity was used to directly store an ACPI polarity value (ACPI_ACTIVE_*). This is undesirable because hci_bcm is also used with device-tree and checking for something like ACPI_ACTIVE_LOW in a non ACPI specific function like bcm_request_irq feels wrong.
This commit fixes this by renaming irq_polarity to irq_active_low and changing its type to a bool.
--- drivers/bluetooth/hci_bcm.c | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-)
drivers/bluetooth/hci_bcm.c +10 -13
@@ -68,7 +68,7 @@ struct bcm_device {u32 init_speed;u32 oper_speed;int irq; -u8 irq_polarity; +bool irq_active_low;#ifdef CONFIG_PM struct hci_uart *hu;
@@ -213,7 +213,9 @@ static int bcm_request_irq(struct bcm_da } err =devm_request_irq (&bdev->pdev->dev, bdev->irq, bcm_host_wake, -IRQF_TRIGGER_RISING ,"host_wake" , bdev); + bdev->irq_active_low ?IRQF_TRIGGER_FALLING : +IRQF_TRIGGER_RISING , +"host_wake" , bdev);if (err) goto unlock;
@@ -253,7 +255,7 @@ static int bcm_setup_sleep(struct hci_uastruct sk_buff *skb;struct bcm_set_sleep_mode sleep_params = default_sleep_params; - sleep_params.host_wake_active = !bcm->dev->irq_polarity; + sleep_params.host_wake_active = !bcm->dev->irq_active_low; skb =__hci_cmd_sync (hu->hdev,0xfc27 ,sizeof (sleep_params), &sleep_params,HCI_INIT_TIMEOUT );
@@ -690,10 +692,8 @@ static const struct acpi_gpio_mapping ac }; #ifdef CONFIG_ACPI -static u8 acpi_active_low = ACPI_ACTIVE_LOW; - /* IRQ polarity of some chipsets are not defined correctly in ACPI table. */ -static const struct dmi_system_id bcm_wrong_irq_dmi_table[] = { +static const struct dmi_system_id bcm_active_low_irq_dmi_table[] = { { .ident = "Asus T100TA", .matches = {
@@ -701,7 +701,6 @@ static const struct dmi_system_id bcm_wr "ASUSTeK COMPUTER INC."), DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100TA"), }, - .driver_data = &acpi_active_low, }, { .ident = "Asus T100CHI",
@@ -710,7 +709,6 @@ static const struct dmi_system_id bcm_wr "ASUSTeK COMPUTER INC."), DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100CHI"), }, - .driver_data = &acpi_active_low, }, {/* Handle ThinkPad 8 tablets with BCM2E55 chipset ACPI ID */ .ident = "Lenovo ThinkPad 8",
@@ -718,7 +716,6 @@ static const struct dmi_system_id bcm_wr DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"), DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "ThinkPad 8"), }, - .driver_data = &acpi_active_low, }, { } };
@@ -733,13 +730,13 @@ static int bcm_resource(struct acpi_resoswitch (ares->type) {case ACPI_RESOURCE_TYPE_EXTENDED_IRQ : irq = &ares->data.extended_irq; - dev->irq_polarity = irq->polarity; + dev->irq_active_low = irq->polarity ==ACPI_ACTIVE_LOW ;break ;case ACPI_RESOURCE_TYPE_GPIO : gpio = &ares->data.gpio;if (gpio->connection_type ==ACPI_RESOURCE_GPIO_TYPE_INT ) - dev->irq_polarity = gpio->polarity; + dev->irq_active_low = gpio->polarity ==ACPI_ACTIVE_LOW ;break ;case ACPI_RESOURCE_TYPE_SERIAL_BUS :
@@ -834,11 +831,11 @@ static int bcm_acpi_probe(struct bcm_devreturn ret;acpi_dev_free_resource_list (&resources); - dmi_id =dmi_first_match (bcm_wrong_irq_dmi_table); + dmi_id =dmi_first_match (bcm_active_low_irq_dmi_table);if (dmi_id) {bt_dev_warn (dev,"%s: Overwriting IRQ polarity to active low" , dmi_id->ident); - dev->irq_polarity = *(u8 *)dmi_id->driver_data; + dev->irq_active_low = true; }return 0 ;
Greg Kroah-Hartman
maintainerPATCH 127/159 i40e/i40evf: spread CPU affinity hints across online CPUs only
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jacob Keller <[email protected]>
[ Upstream commit be664cbefc50977aaefc868ba6a1109ec9b7449d ]
Currently, when setting up the IRQ for a q_vector, we set an affinity hint based on the v_idx of that q_vector. Meaning a loop iterates on v_idx, which is an incremental value, and the cpumask is created based on this value.
This is a problem in systems with multiple logical CPUs per core (like in simultaneous multithreading (SMT) scenarios). If we disable some logical CPUs, by turning SMT off for example, we will end up with a sparse cpu_online_mask, i.e., only the first CPU in a core is online, and incremental filling in q_vector cpumask might lead to multiple offline CPUs being assigned to q_vectors.
Example: if we have a system with 8 cores each one containing 8 logical CPUs (SMT == 8 in this case), we have 64 CPUs in total. But if SMT is disabled, only the 1st CPU in each core remains online, so the cpu_online_mask in this case would have only 8 bits set, in a sparse way.
In general case, when SMT is off the cpu_online_mask has only C bits set:
0, 1*N, 2*N, ..., C*(N-1) where
C == # of cores;
N == # of logical CPUs per core.
In our example, only bits 0, 8, 16, 24, 32, 40, 48, 56 would be set.
Instead, we should only assign hints for CPUs which are online. Even better, the kernel already provides a function, cpumask_local_spread() which takes an index and returns a CPU, spreading the interrupts across local NUMA nodes first, and then remote ones if necessary.
Since we generally have a 1:1 mapping between vectors and CPUs, there is no real advantage to spreading vectors to local CPUs first. In order to avoid mismatch of the default XPS hints, we'll pass -1 so that it spreads across all CPUs without regard to the node locality.
Note that we don't need to change the q_vector->affinity_mask as this is initialized to cpu_possible_mask, until an actual affinity is set and then notified back to us.
--- drivers/net/ethernet/intel/i40e/i40e_main.c | 16 +++++++++++----- drivers/net/ethernet/intel/i40evf/i40evf_main.c | 9 ++++++--- 2 files changed, 17 insertions(+), 8 deletions(-)
drivers/net/ethernet/intel/i40e/i40e_main.c +11 -5
@@ -2874,14 +2874,15 @@ static void i40e_vsi_free_rx_resources(sstatic void i40e_config_xps_tx_ring (struct i40e_ring *ring) {struct i40e_vsi *vsi = ring->vsi; +int cpu;if (!ring->q_vector || !ring->netdev)return ;if ((vsi->tc_config.numtc <=1 ) && !test_and_set_bit (__I40E_TX_XPS_INIT_DONE, &ring->state)) { -netif_set_xps_queue (ring->netdev, -get_cpu_mask (ring->q_vector->v_idx), + cpu =cpumask_local_spread (ring->q_vector->v_idx,-1 ); +netif_set_xps_queue (ring->netdev,get_cpu_mask (cpu), ring->queue_index); }
@@ -3471,6 +3472,7 @@ static int i40e_vsi_request_irq_msix(strint tx_int_idx =0 ;int vector, err;int irq_num; +int cpu;for (vector =0 ; vector < q_vectors; vector++) {struct i40e_q_vector *q_vector = vsi->q_vectors[vector];
@@ -3506,10 +3508,14 @@ static int i40e_vsi_request_irq_msix(str q_vector->affinity_notify.notify = i40e_irq_affinity_notify; q_vector->affinity_notify.release = i40e_irq_affinity_release;irq_set_affinity_notifier (irq_num, &q_vector->affinity_notify); -/* get_cpu_mask returns a static constant mask with -* a permanent lifetime so it's ok to use here. +/* Spread affinity hints out across online CPUs. +* +* get_cpu_mask returns a static constant mask with +* a permanent lifetime so it's ok to pass to +* irq_set_affinity_hint without making a copy. */ -irq_set_affinity_hint (irq_num,get_cpu_mask (q_vector->v_idx)); + cpu =cpumask_local_spread (q_vector->v_idx,-1 ); +irq_set_affinity_hint (irq_num,get_cpu_mask (cpu)); } vsi->irqs_ready = true;
drivers/net/ethernet/intel/i40evf/i40evf_main.c +6 -3
@@ -546,6 +546,7 @@ i40evf_request_traffic_irqs(struct i40evunsigned int vector, q_vectors;unsigned int rx_int_idx =0 , tx_int_idx =0 ;int irq_num, err; +int cpu;i40evf_irq_disable (adapter);/* Decrement for Other and TCP Timer vectors */
@@ -584,10 +585,12 @@ i40evf_request_traffic_irqs(struct i40ev q_vector->affinity_notify.release = i40evf_irq_affinity_release;irq_set_affinity_notifier (irq_num, &q_vector->affinity_notify); -/* get_cpu_mask returns a static constant mask with -* a permanent lifetime so it's ok to use here. +/* Spread the IRQ affinity hints across online CPUs. Note that +* get_cpu_mask returns a mask with a permanent lifetime so +* it's safe to use as a hint for irq_set_affinity_hint. */ -irq_set_affinity_hint (irq_num,get_cpu_mask (q_vector->v_idx)); + cpu =cpumask_local_spread (q_vector->v_idx,-1 ); +irq_set_affinity_hint (irq_num,get_cpu_mask (cpu)); }return 0 ;
Greg Kroah-Hartman
maintainerPATCH 128/159 PCI/AER: Report non-fatal errors only to the affected endpoint
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gabriele Paoloni <[email protected]>
[ Upstream commit 86acc790717fb60fb51ea3095084e331d8711c74 ]
Previously, if an non-fatal error was reported by an endpoint, we called report_error_detected() for the endpoint, every sibling on the bus, and their descendents. If any of them did not implement the .error_detected() method, do_recovery() failed, leaving all these devices unrecovered.
For example, the system described in the bugzilla below has two devices:
0000:74:02.0 [19e5:a230] SAS controller, driver has .error_detected() 0000:74:03.0 [19e5:a235] SATA controller, driver lacks .error_detected()
When a device such as 74:02.0 reported a non-fatal error, do_recovery() failed because 74:03.0 lacked an .error_detected() method. But per PCIe r3.1, sec 6.2.2.2.2, such an error does not compromise the Link and does not affect 74:03.0:
Non-fatal errors are uncorrectable errors which cause a particular transaction to be unreliable but the Link is otherwise fully functional. Isolating Non-fatal from Fatal errors provides Requester/Receiver logic in a device or system management software the opportunity to recover from the error without resetting the components on the Link and disturbing other transactions in progress. Devices not associated with the transaction in error are not impacted by the error.
Report non-fatal errors only to the endpoint that reported them. We really want to check for AER_NONFATAL here, but the current code structure doesn't allow that. Looking for pci_channel_io_normal is the best we can do now.
--- drivers/pci/pcie/aer/aerdrv_core.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/pci/pcie/aer/aerdrv_core.c +8 -1
@@ -390,7 +390,14 @@ static pci_ers_result_t broadcast_error_* If the error is reported by an end point, we think this * error is related to the upstream link of the end point. */ -pci_walk_bus (dev->bus, cb, &result_data); +if (state == pci_channel_io_normal) +/* +* the error is non fatal so the bus is ok, just invoke +* the callback for the function that logged the error. +*/ +cb (dev, &result_data); +else +pci_walk_bus (dev->bus, cb, &result_data); }return result_data.result;
Greg Kroah-Hartman
maintainerPATCH 129/159 tracing: Exclude generic fields from histograms
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tom Zanussi <[email protected]>
[ Upstream commit a15f7fc20389a8827d5859907568b201234d4b79 ]
There are a small number of 'generic fields' (comm/COMM/cpu/CPU) that are found by trace_find_event_field() but are only meant for filtering. Specifically, they unlike normal fields, they have a size of 0 and thus wreak havoc when used as a histogram key.
Exclude these (return -EINVAL) when used as histogram keys.
--- kernel/trace/trace_events_hist.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/trace/trace_events_hist.c +2 -2
@@ -450,7 +450,7 @@ static int create_val_field(struct hist_ } field =trace_find_event_field (file->event_call, field_name); -if (!field) { +if (!field || !field->size) { ret = -EINVAL ; goto out; }
@@ -548,7 +548,7 @@ static int create_key_field(struct hist_ } field =trace_find_event_field (file->event_call, field_name); -if (!field) { +if (!field || !field->size) { ret = -EINVAL ; goto out; }
Greg Kroah-Hartman
maintainerPATCH 131/159 ASoC: img-parallel-out: Add pm_runtime_get/put to set_fmt callback
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ed Blake <[email protected]>
[ Upstream commit c70458890ff15d858bd347fa9f563818bcd6e457 ]
Add pm_runtime_get_sync and pm_runtime_put calls to set_fmt callback function. This fixes a bus error during boot when CONFIG_SUSPEND is defined when this function gets called while the device is runtime disabled and device registers are accessed while the clock is disabled.
--- sound/soc/img/img-parallel-out.c | 2 ++ 1 file changed, 2 insertions(+)
sound/soc/img/img-parallel-out.c +2 -0
@@ -164,9 +164,11 @@ static int img_prl_out_set_fmt(struct snreturn -EINVAL ; } +pm_runtime_get_sync (prl->dev); reg =img_prl_out_readl (prl,IMG_PRL_OUT_CTL ); reg = (reg & ~IMG_PRL_OUT_CTL_EDGE_MASK ) | control_set;img_prl_out_writel (prl, reg,IMG_PRL_OUT_CTL ); +pm_runtime_put (prl->dev);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 132/159 powerpc/xmon: Avoid tripping SMP hardlockup watchdog
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Piggin <[email protected]>
[ Upstream commit 064996d62a33ffe10264b5af5dca92d54f60f806 ]
The SMP hardlockup watchdog cross-checks other CPUs for lockups, which causes xmon headaches because it's assuming interrupts hard disabled means no watchdog troubles. Try to improve that by calling touch_nmi_watchdog() in obvious places where secondaries are spinning.
Also annotate these spin loops with spin_begin/end calls.
--- arch/powerpc/xmon/xmon.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-)
arch/powerpc/xmon/xmon.c +13 -4
@@ -530,14 +530,19 @@ static int xmon_core(struct pt_regs *reg waiting: secondary =1 ; +spin_begin ();while (secondary && !xmon_gate) {if (in_xmon ==0 ) { -if (fromipi) +if (fromipi) { +spin_end (); goto leave; + } secondary =test_and_set_bit (0 , &in_xmon); } -barrier (); +spin_cpu_relax (); +touch_nmi_watchdog (); } +spin_end ();if (!secondary && !xmon_gate) {/* we are the first cpu to come in */
@@ -568,21 +573,25 @@ static int xmon_core(struct pt_regs *regmb (); xmon_gate =1 ;barrier (); +touch_nmi_watchdog (); } cmdloop:while (in_xmon) {if (secondary) { +spin_begin ();if (cpu == xmon_owner) {if (!test_and_set_bit (0 , &xmon_taken)) { secondary =0 ; +spin_end ();continue ; }/* missed it */ while (cpu == xmon_owner) -barrier (); +spin_cpu_relax (); } -barrier (); +spin_cpu_relax (); +touch_nmi_watchdog (); }else { cmd =cmds (regs);if (cmd !=0 ) {
Greg Kroah-Hartman
maintainerPATCH 133/159 powerpc/watchdog: Do not trigger SMP crash from touch_nmi_watchdog
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Piggin <[email protected]>
[ Upstream commit 80e4d70b06863e0104e5a0dc78aa3710297fbd4b ]
In xmon, touch_nmi_watchdog() is not expected to be checking that other CPUs have not touched the watchdog, so the code will just call touch_nmi_watchdog() once before re-enabling hard interrupts.
Just update our CPU's state, and ignore apparently stuck SMP threads.
Arguably touch_nmi_watchdog should check for SMP lockups, and callers should be fixed, but that's not trivial for the input code of xmon.
--- arch/powerpc/kernel/watchdog.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
arch/powerpc/kernel/watchdog.c +5 -2
@@ -276,9 +276,12 @@ void arch_touch_nmi_watchdog(void) {unsigned long ticks = tb_ticks_per_usec * wd_timer_period_ms *1000 ;int cpu =smp_processor_id (); +u64 tb =get_tb (); -if (get_tb () -per_cpu (wd_timer_tb, cpu) >= ticks) -watchdog_timer_interrupt (cpu); +if (tb -per_cpu (wd_timer_tb, cpu) >= ticks) { +per_cpu (wd_timer_tb, cpu) = tb; +wd_smp_clear_cpu_pending (cpu, tb); + } }EXPORT_SYMBOL (arch_touch_nmi_watchdog);
Greg Kroah-Hartman
maintainerPATCH 134/159 sctp: silence warns on sctp_stream_init allocations
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marcelo Ricardo Leitner <[email protected]>
[ Upstream commit 1ae2eaaa229bc350b6f38fbf4ab9c873532aecfb ]
As SCTP supports up to 65535 streams, that can lead to very large allocations in sctp_stream_init(). As Xin Long noticed, systems with small amounts of memory are more prone to not have enough memory and dump warnings on dmesg initiated by user actions. Thus, silence them.
Also, if the reallocation of stream->out is not necessary, skip it and keep the memory we already have.
--- net/sctp/stream.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
net/sctp/stream.c +7 -1
@@ -40,9 +40,14 @@ int sctp_stream_init(struct sctp_stream {int i; + gfp |= __GFP_NOWARN; +/* Initial stream->out size may be very big, so free it and alloc -* a new one with new outcnt to save memory. +* a new one with new outcnt to save memory if needed. */ +if (outcnt == stream->outcnt) + goto in; +kfree (stream->out); stream->out =kcalloc (outcnt,sizeof (*stream->out), gfp);
@@ -53,6 +58,7 @@ int sctp_stream_init(struct sctp_streamfor (i =0 ; i < stream->outcnt; i++) stream->out[i].state =SCTP_STREAM_OPEN ; +in:if (!incnt)return 0 ;
Greg Kroah-Hartman
maintainerPATCH 135/159 ASoC: codecs: msm8916-wcd-analog: fix module autoload
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolas Dechesne <[email protected]>
[ Upstream commit 46d69e141d479585c105a4d5b2337cd2ce6967e5 ]
If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module.
Export the module alias information using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo snd_soc_msm8916_analog | grep alias $
After this patch:
$ modinfo snd_soc_msm8916_analog | grep alias alias: of:N*T*Cqcom,pm8916-wcd-analog-codecC* alias: of:N*T*Cqcom,pm8916-wcd-analog-codec
--- sound/soc/codecs/msm8916-wcd-analog.c | 2 ++ 1 file changed, 2 insertions(+)
sound/soc/codecs/msm8916-wcd-analog.c +2 -0
@@ -1242,6 +1242,8 @@ static const struct of_device_id pm8916_ { } }; +MODULE_DEVICE_TABLE (of, pm8916_wcd_analog_spmi_match_table); +static struct platform_driver pm8916_wcd_analog_spmi_driver = { .driver = { .name ="qcom,pm8916-wcd-spmi-codec" ,
Greg Kroah-Hartman
maintainerPATCH 136/159 fm10k: fix mis-ordered parameters in declaration for .ndo_set_vf_bw
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jacob Keller <[email protected]>
[ Upstream commit 3e256ac5b1ec307e5dd5a4c99fbdbc651446c738 ]
We've had support for setting both a minimum and maximum bandwidth via .ndo_set_vf_bw since commit 883a9ccbae56 ("fm10k: Add support for SR-IOV to driver", 2014-09-20).
Likely because we do not support minimum rates, the declaration mis-ordered the "unused" parameter, which causes warnings when analyzed with cppcheck.
Fix this warning by properly declaring the min_rate and max_rate variables in the declaration and definition (rather than using "unused"). Also rename "rate" to max_rate so as to clarify that we only support setting the maximum rate.
--- drivers/net/ethernet/intel/fm10k/fm10k.h | 4 ++-- drivers/net/ethernet/intel/fm10k/fm10k_iov.c | 9 +++++---- 2 files changed, 7 insertions(+), 6 deletions(-)
drivers/net/ethernet/intel/fm10k/fm10k.h +2 -2
@@ -526,8 +526,8 @@ s32 fm10k_iov_update_pvid(struct fm10k_iint fm10k_ndo_set_vf_mac (struct net_device *netdev,int vf_idx,u8 *mac);int fm10k_ndo_set_vf_vlan (struct net_device *netdev,int vf_idx,u16 vid,u8 qos,__be16 vlan_proto); -int fm10k_ndo_set_vf_bw (struct net_device *netdev,int vf_idx,int rate, -int unused); +int fm10k_ndo_set_vf_bw (struct net_device *netdev,int vf_idx, +int __always_unused min_rate,int max_rate);int fm10k_ndo_get_vf_config (struct net_device *netdev,int vf_idx,struct ifla_vf_info *ivi);
drivers/net/ethernet/intel/fm10k/fm10k_iov.c +5 -4
@@ -482,7 +482,7 @@ int fm10k_ndo_set_vf_vlan(struct net_dev }int fm10k_ndo_set_vf_bw (struct net_device *netdev,int vf_idx, -int __always_unused unused,int rate) +int __always_unused min_rate,int max_rate) {struct fm10k_intfc *interface =netdev_priv (netdev);struct fm10k_iov_data *iov_data = interface->iov_data;
@@ -493,14 +493,15 @@ int fm10k_ndo_set_vf_bw(struct net_devicreturn -EINVAL ;/* rate limit cannot be less than 10Mbs or greater than link speed */ -if (rate && ((rate <FM10K_VF_TC_MIN ) || rate >FM10K_VF_TC_MAX )) +if (max_rate && + (max_rate <FM10K_VF_TC_MIN || max_rate >FM10K_VF_TC_MAX ))return -EINVAL ;/* store values */ - iov_data->vf_info[vf_idx].rate = rate; + iov_data->vf_info[vf_idx].rate = max_rate;/* update hardware configuration */ - hw->iov.ops.configure_tc (hw, vf_idx, rate); + hw->iov.ops.configure_tc (hw, vf_idx, max_rate);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 137/159 scsi: lpfc: Fix secure firmware updates
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dick Kennedy <[email protected]>
[ Upstream commit 184fc2b9a8bcbda9c14d0a1e7fbecfc028c7702e ]
Firmware update fails with: status x17 add_status x56 on the final write
If multiple DMA buffers are used for the download, some firmware revs have difficulty with signatures and crcs split across the dma buffer boundaries. Resolve by making all writes be a single 4k page in length.
--- drivers/scsi/lpfc/lpfc_hw4.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/lpfc/lpfc_hw4.h +1 -1
@@ -3636,7 +3636,7 @@ struct lpfc_mbx_get_port_name {#define MB_CEQ_STATUS_QUEUE_FLUSHING 0x4#define MB_CQE_STATUS_DMA_FAILED 0x5 -#define LPFC_MBX_WR_CONFIG_MAX_BDE 8 +#define LPFC_MBX_WR_CONFIG_MAX_BDE 1struct lpfc_mbx_wr_object {struct mbox_header header;union {
Greg Kroah-Hartman
maintainerPATCH 138/159 scsi: lpfc: PLOGI failures during NPIV testing
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dick Kennedy <[email protected]>
[ Upstream commit e8bcf0ae4c0346fdc78ebefe0eefcaa6a6622d38 ]
Local Reject/Invalid RPI errors seen during discovery.
Temporary RPI cleanup was occurring regardless of SLI rev. It's only necessary on SLI-4.
Adjust the test for whether cleanup is necessary.
--- drivers/scsi/lpfc/lpfc_hbadisc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/scsi/lpfc/lpfc_hbadisc.c +2 -1
@@ -4983,7 +4983,8 @@ lpfc_nlp_remove(struct lpfc_vport *vportlpfc_cancel_retry_delay_tmo (vport, ndlp);if ((ndlp->nlp_flag &NLP_DEFER_RM ) && !(ndlp->nlp_flag &NLP_REG_LOGIN_SEND ) && - !(ndlp->nlp_flag &NLP_RPI_REGISTERED )) { + !(ndlp->nlp_flag &NLP_RPI_REGISTERED ) && + phba->sli_rev !=LPFC_SLI_REV4 ) {/* For this case we need to cleanup the default rpi * allocated by the firmware. */
Greg Kroah-Hartman
maintainerPATCH 139/159 scsi: lpfc: Fix warning messages when NVME_TARGET_FC not defined
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dick Kennedy <[email protected]>
[ Upstream commit 2299e4323d2bf6e0728fdc6b9e8e9704978d2dd7 ]
Warning messages when NVME_TARGET_FC not defined on ppc builds
The lpfc_nvmet_replenish_context() function is only meaningful when NVME target mode enabled. Surround the function body with ifdefs for target mode enablement.
--- drivers/scsi/lpfc/lpfc_nvmet.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/scsi/lpfc/lpfc_nvmet.c +2 -0
@@ -1464,6 +1464,7 @@ static struct lpfc_nvmet_ctxbuf * lpfc_nvmet_replenish_context(struct lpfc_hba *phba, struct lpfc_nvmet_ctx_info *current_infop) { +#if (IS_ENABLED(CONFIG_NVME_TARGET_FC)) struct lpfc_nvmet_ctxbuf *ctx_buf = NULL;struct lpfc_nvmet_ctx_info *get_infop;int i;
@@ -1511,6 +1512,7 @@ lpfc_nvmet_replenish_context(struct lpfc get_infop = get_infop->nvmet_ctx_next_cpu; } +#endif /* Nothing found, all contexts for the MRQ are in-flight */ return NULL ; }
Greg Kroah-Hartman
maintainerPATCH 140/159 i40e: fix client notify of VF reset
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Brady <[email protected]>
[ Upstream commit c53d11f669c0e7d0daf46a717b6712ad0b09de99 ]
Currently there is a bug in which the PF driver fails to inform clients of a VF reset which then causes clients to leak resources. The bug exists because we were incorrectly checking the I40E_VF_STATE_PRE_ENABLE bit.
When a VF is first init we go through a reset to initialize variables and allocate resources but we don't want to inform clients of this first reset since the client isn't fully enabled yet so we set a state bit signifying we're in a "pre-enabled" client state. During the first reset we should be clearing the bit, allowing all following resets to notify the client of the reset when the bit is not set. This patch fixes the issue by negating the 'test_and_clear_bit' check to accurately reflect the behavior we want.
--- drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c +2 -2
@@ -1008,8 +1008,8 @@ static void i40e_cleanup_reset_vf(structset_bit (I40E_VF_STATE_ACTIVE , &vf->vf_states);clear_bit (I40E_VF_STATE_DISABLED , &vf->vf_states);/* Do not notify the client during VF init */ -if (test_and_clear_bit (I40E_VF_STATE_PRE_ENABLE , - &vf->vf_states)) +if (!test_and_clear_bit (I40E_VF_STATE_PRE_ENABLE , + &vf->vf_states))i40e_notify_client_of_vf_reset (pf, abs_vf_id); vf->num_vlan =0 ; }
Greg Kroah-Hartman
maintainerPATCH 141/159 vfio/pci: Virtualize Maximum Payload Size
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Williamson <[email protected]>
[ Upstream commit 523184972b282cd9ca17a76f6ca4742394856818 ]
With virtual PCI-Express chipsets, we now see userspace/guest drivers trying to match the physical MPS setting to a virtual downstream port. Of course a lone physical device surrounded by virtual interconnects cannot make a correct decision for a proper MPS setting. Instead, let's virtualize the MPS control register so that writes through to hardware are disallowed. Userspace drivers like QEMU assume they can write anything to the device and we'll filter out anything dangerous. Since mismatched MPS can lead to AER and other faults, let's add it to the kernel side rather than relying on userspace virtualization to handle it.
--- drivers/vfio/pci/vfio_pci_config.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/vfio/pci/vfio_pci_config.c +4 -2
@@ -849,11 +849,13 @@ static int __init init_pci_cap_exp_perm(/* * Allow writes to device control fields, except devctl_phantom, -* which could confuse IOMMU, and the ARI bit in devctl2, which +* which could confuse IOMMU, MPS, which can break communication +* with other physical devices, and the ARI bit in devctl2, which * is set at probe time. FLR gets virtualized via our writefn. */ p_setw (perm,PCI_EXP_DEVCTL , -PCI_EXP_DEVCTL_BCR_FLR , ~PCI_EXP_DEVCTL_PHANTOM ); +PCI_EXP_DEVCTL_BCR_FLR |PCI_EXP_DEVCTL_PAYLOAD , + ~PCI_EXP_DEVCTL_PHANTOM );p_setw (perm,PCI_EXP_DEVCTL2 ,NO_VIRT , ~PCI_EXP_DEVCTL2_ARI );return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 142/159 ARM: exynos_defconfig: Enable UAS support for Odroid HC1 board
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marek Szyprowski <[email protected]>
[ Upstream commit a99897f550de96841aecb811455a67ad7a4e39a7 ]
Odroid HC1 board has built-in JMicron USB to SATA bridge, which supports UAS protocol. Compile-in support for it (instead of enabling it as module) to make sure that all built-in storage devices are available for rootfs. The bridge itself also supports fallback to standard USB Mass Storage protocol, but USB Mass Storage class doesn't bind to it when UAS is compiled as module and modules are not (yet) available.
--- arch/arm/configs/exynos_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/configs/exynos_defconfig +1 -1
@@ -244,7 +244,7 @@ CONFIG_USB_STORAGE_ONETOUCH=m CONFIG_USB_STORAGE_KARMA=m CONFIG_USB_STORAGE_CYPRESS_ATACB=m CONFIG_USB_STORAGE_ENE_UB6250=m -CONFIG_USB_UAS=m +CONFIG_USB_UAS=y CONFIG_USB_DWC3=y CONFIG_USB_DWC2=y CONFIG_USB_HSIC_USB3503=y
Greg Kroah-Hartman
maintainerPATCH 143/159 fm10k: ensure we process SM mbx when processing VF mbx
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jacob Keller <[email protected]>
[ Upstream commit 17a91809942ca32c70026d2d5ba3348a2c4fdf8f ]
When we process VF mailboxes, the driver is likely going to also queue up messages to the switch manager. This process merely queues up the FIFO, but doesn't actually begin the transmission process. Because we hold the mailbox lock during this VF processing, the PF<->SM mailbox is not getting processed at this time. Ensure that we actually process the PF<->SM mailbox in between each PF<->VF mailbox.
This should ensure prompt transmission of the messages queued up after each VF message is received and handled.
--- drivers/net/ethernet/intel/fm10k/fm10k_iov.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/ethernet/intel/fm10k/fm10k_iov.c +3 -0
@@ -126,6 +126,9 @@ process_mbx:struct fm10k_mbx_info *mbx = &vf_info->mbx;u16 glort = vf_info->glort; +/* process the SM mailbox first to drain outgoing messages */ + hw->mbx.ops.process (hw, &hw->mbx); +/* verify port mapping is valid, if not reset port */ if (vf_info->vf_flags && !fm10k_glort_valid_pf (hw, glort)) hw->iov.ops.reset_lport (hw, vf_info);
Greg Kroah-Hartman
maintainerPATCH 144/159 ibmvnic: Set state UP
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mick Tarsel <[email protected]>
[ Upstream commit e876a8a7e9dd89dc88c12ca2e81beb478dbe9897 ]
State is initially reported as UNKNOWN. Before register call netif_carrier_off(). Once the device is opened, call netif_carrier_on() in order to set the state to UP.
--- drivers/net/ethernet/ibm/ibmvnic.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/ethernet/ibm/ibmvnic.c +2 -0
@@ -927,6 +927,7 @@ static int ibmvnic_open(struct net_devic } rc =__ibmvnic_open (netdev); +netif_carrier_on (netdev);mutex_unlock (&adapter->reset_lock);return rc;
@@ -3899,6 +3900,7 @@ static int ibmvnic_probe(struct vio_devif (rc) goto ibmvnic_init_fail; +netif_carrier_off (netdev); rc =register_netdev (netdev);if (rc) {dev_err (&dev->dev,"failed to register netdev rc=%d\n" , rc);
Greg Kroah-Hartman
maintainerPATCH 145/159 net: ipv6: send NS for DAD when link operationally up
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mike Manning <[email protected]>
[ Upstream commit 1f372c7bfb23286d2bf4ce0423ab488e86b74bb2 ]
The NS for DAD are sent on admin up as long as a valid qdisc is found. A race condition exists by which these packets will not egress the interface if the operational state of the lower device is not yet up. The solution is to delay DAD until the link is operationally up according to RFC2863. Rather than only doing this, follow the existing code checks by deferring IPv6 device initialization altogether. The fix allows DAD on devices like tunnels that are controlled by userspace control plane. The fix has no impact on regular deployments, but means that there is no IPv6 connectivity until the port has been opened in the case of port-based network access control, which should be desirable.
--- net/ipv6/addrconf.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
net/ipv6/addrconf.c +6 -6
@@ -303,10 +303,10 @@ static struct ipv6_devconf ipv6_devconf_ .disable_policy = 0, }; -/* Check if a valid qdisc is available */ -static inline bool addrconf_qdisc_ok (const struct net_device *dev) +/* Check if link is ready: is it up and is a valid qdisc available */ +static inline bool addrconf_link_ready (const struct net_device *dev) { -return !qdisc_tx_is_noop (dev); +return netif_oper_up (dev) && !qdisc_tx_is_noop (dev); }static void addrconf_del_rs_timer (struct inet6_dev *idev)
@@ -451,7 +451,7 @@ static struct inet6_dev *ipv6_add_dev(st ndev->token = in6addr_any; -if (netif_running (dev) &&addrconf_qdisc_ok (dev)) +if (netif_running (dev) &&addrconf_link_ready (dev)) ndev->if_flags |=IF_READY ;ipv6_mc_init_dev (ndev);
@@ -3404,7 +3404,7 @@ static int addrconf_notify(struct notifi/* restore routes for permanent addresses */ addrconf_permanent_addr (dev); -if (!addrconf_qdisc_ok (dev)) { +if (!addrconf_link_ready (dev)) {/* device is not ready yet. */ pr_info ("ADDRCONF(NETDEV_UP): %s: link is not ready\n" , dev->name);
@@ -3419,7 +3419,7 @@ static int addrconf_notify(struct notifi run_pending =1 ; } }else if (event ==NETDEV_CHANGE ) { -if (!addrconf_qdisc_ok (dev)) { +if (!addrconf_link_ready (dev)) {/* device is still not ready. */ break ; }
Greg Kroah-Hartman
maintainerPATCH 146/159 RDMA/hns: Avoid NULL pointer exception
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Wei Hu(Xavier)" <[email protected]>
[ Upstream commit 5e437b1d7e8d31ff9a4b8e898eb3a6cee309edd9 ]
After the loop in hns_roce_v1_mr_free_work_fn function, it is possible that all qps will have been freed (in which case ne will be 0). If that happens, then later in the function when we dereference hr_qp we will get an exception. Check ne is not 0 to make sure we actually have an hr_qp left to work on.
This patch fixes the smatch error as below:drivers/infiniband/hw/hns/hns_roce_hw_v1.c:1009 hns_roce_v1_mr_free_work_fn()
error: we previously assumed 'hr_qp' could be null
--- drivers/infiniband/hw/hns/hns_roce_hw_v1.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/infiniband/hw/hns/hns_roce_hw_v1.c +5 -0
@@ -1001,6 +1001,11 @@ static void hns_roce_v1_mr_free_work_fn( } } +if (!ne) { +dev_err (dev,"Reseved loop qp is absent!\n" ); + goto free_work; + } + do { ret = hns_roce_v1_poll_cq(&mr_free_cq->ib_cq, ne, wc); if (ret < 0) {
Greg Kroah-Hartman
maintainerPATCH 147/159 staging: greybus: light: Release memory obtained by kasprintf
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arvind Yadav <[email protected]>
[ Upstream commit 04820da21050b35eed68aa046115d810163ead0c ]
Free memory region, if gb_lights_channel_config is not successful.
--- drivers/staging/greybus/light.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/staging/greybus/light.c +2 -0
@@ -925,6 +925,8 @@ static void __gb_lights_led_unregister(sreturn ;led_classdev_unregister (cdev); +kfree (cdev->name); + cdev->name =NULL ; channel->led =NULL ; }
Greg Kroah-Hartman
maintainerPATCH 148/159 clk: sunxi-ng: sun6i: Rename HDMI DDC clock to avoid name collision
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen-Yu Tsai <[email protected]>
[ Upstream commit 7f3ed79188f2f094d0ee366fa858857fb7f511ba ]
The HDMI DDC clock found in the CCU is the parent of the actual DDC clock within the HDMI controller. That clock is also named "hdmi-ddc".
Rename the one in the CCU to "ddc". This makes more sense than renaming the one in the HDMI controller to something else.
--- drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/sunxi-ng/ccu-sun6i-a31.c +1 -1
@@ -608,7 +608,7 @@ static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_cl0x150 ,0 ,4 ,24 ,2 ,BIT (31 ), CLK_SET_RATE_PARENT); -static SUNXI_CCU_GATE(hdmi_ddc_clk, "hdmi-ddc", "osc24M", 0x150, BIT(30), 0); +static SUNXI_CCU_GATE(hdmi_ddc_clk, "ddc", "osc24M", 0x150, BIT(30), 0); static SUNXI_CCU_GATE(ps_clk, "ps", "lcd1-ch1", 0x140, BIT(31), 0);
Greg Kroah-Hartman
maintainerPATCH 149/159 tcp: fix under-evaluated ssthresh in TCP Vegas
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hoang Tran <[email protected]>
[ Upstream commit cf5d74b85ef40c202c76d90959db4d850f301b95 ]
With the commit 76174004a0f19785 (tcp: do not slow start when cwnd equals ssthresh), the comparison to the reduced cwnd in tcp_vegas_ssthresh() would under-evaluate the ssthresh.
--- net/ipv4/tcp_vegas.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv4/tcp_vegas.c +1 -1
@@ -158,7 +158,7 @@ EXPORT_SYMBOL_GPL(tcp_vegas_cwnd_event);static inline u32 tcp_vegas_ssthresh (struct tcp_sock *tp) { -return min (tp->snd_ssthresh, tp->snd_cwnd-1 ); +return min (tp->snd_ssthresh, tp->snd_cwnd); }static void tcp_vegas_cong_avoid (struct sock *sk,u32 ack,u32 acked)
Greg Kroah-Hartman
maintainerPATCH 150/159 rtc: set the alarm to the next expiring timer
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexandre Belloni <[email protected]>
[ Upstream commit 74717b28cb32e1ad3c1042cafd76b264c8c0f68d ]
If there is any non expired timer in the queue, the RTC alarm is never set. This is an issue when adding a timer that expires before the next non expired timer.
Ensure the RTC alarm is set in that case.
--- drivers/rtc/interface.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/rtc/interface.c +1 -1
@@ -779,7 +779,7 @@ static int rtc_timer_enqueue(struct rtc_ }timerqueue_add (&rtc->timerqueue, &timer->node); -if (!next) { +if (!next ||ktime_before (timer->node.expires, next->expires)) {struct rtc_wkalrm alarm;int err; alarm.time =rtc_ktime_to_tm (timer->node.expires);
Greg Kroah-Hartman
maintainerPATCH 151/159 cpuidle: fix broadcast control when broadcast can not be entered
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Piggin <[email protected]>
[ Upstream commit f187851b9b4a76952b1158b86434563dd2031103 ]
When failing to enter broadcast timer mode for an idle state that requires it, a new state is selected that does not require broadcast, but the broadcast variable remains set. This causes tick_broadcast_exit to be called despite not having entered broadcast mode.
This causes the WARN_ON_ONCE(!irqs_disabled()) to trigger in some cases. It does not appear to cause problems for code today, but seems to violate the interface so should be fixed.
--- drivers/cpuidle/cpuidle.c | 1 + 1 file changed, 1 insertion(+)
drivers/cpuidle/cpuidle.c +1 -0
@@ -208,6 +208,7 @@ int cpuidle_enter_state(struct cpuidle_dreturn -EBUSY ; } target_state = &drv->states[index]; + broadcast = false; }/* Take note of the planned idle state. */
Greg Kroah-Hartman
maintainerPATCH 152/159 drm/vc4: Avoid using vrefresh==0 mode in DSI htotal math.
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Anholt <[email protected]>
[ Upstream commit af2eca53206c59ce9308a4f5f46c4a104a179b6b ]
The incoming mode might have a missing vrefresh field if it came from drmModeSetCrtc(), which the kernel is supposed to calculate using drm_mode_vrefresh(). We could either use that or the adjusted_mode's original vrefresh value.
However, we can maintain a more exact vrefresh value (not just the integer approximation), by scaling by the ratio of our clocks.
v2: Use math suggested by Andrzej Hajda instead.
v3: Simplify math now that adjusted_mode->clock isn't padded.
v4: Drop some parens.
--- drivers/gpu/drm/vc4/vc4_dsi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/vc4/vc4_dsi.c +2 -1
@@ -866,7 +866,8 @@ static bool vc4_dsi_encoder_mode_fixup(s adjusted_mode->clock = pixel_clock_hz /1000 +1 ;/* Given the new pixel clock, adjust HFP to keep vrefresh the same. */ - adjusted_mode->htotal = pixel_clock_hz / (mode->vrefresh * mode->vtotal); + adjusted_mode->htotal = adjusted_mode->clock * mode->htotal / + mode->clock; adjusted_mode->hsync_end += adjusted_mode->htotal - mode->htotal; adjusted_mode->hsync_start += adjusted_mode->htotal - mode->htotal;
Greg Kroah-Hartman
maintainerPATCH 153/159 IB/opa_vnic: Properly clear Mac Table Digest
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Scott Franco <[email protected]>
[ Upstream commit 4bbdfe25600c1909c26747d0b5c39fd0e409bb87 ]
Clear the MAC table digest when the MAC table is freed.
--- drivers/infiniband/ulp/opa_vnic/opa_vnic_encap.c | 1 + 1 file changed, 1 insertion(+)
drivers/infiniband/ulp/opa_vnic/opa_vnic_encap.c +1 -0
@@ -139,6 +139,7 @@ void opa_vnic_release_mac_tbl(struct oparcu_assign_pointer (adapter->mactbl,NULL );synchronize_rcu ();opa_vnic_free_mac_tbl (mactbl); + adapter->info.vport.mac_tbl_digest =0 ;mutex_unlock (&adapter->mactbl_lock); }
Greg Kroah-Hartman
maintainerPATCH 154/159 IB/opa_vnic: Properly return the total MACs in UC MAC list
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Niranjana Vishwanathapura <[email protected]>
[ Upstream commit b77eb45e0d9c324245d165656ab3b38b6f386436 ]
Do not include EM specified MAC address in total MACs of the UC MAC list.
--- drivers/infiniband/ulp/opa_vnic/opa_vnic_vema_iface.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/infiniband/ulp/opa_vnic/opa_vnic_vema_iface.c +5 -3
@@ -348,7 +348,7 @@ void opa_vnic_query_mcast_macs(struct opvoid opa_vnic_query_ucast_macs (struct opa_vnic_adapter *adapter,struct opa_veswport_iface_macs *macs) { -u16 start_idx, tot_macs, num_macs, idx =0 , count =0 ; +u16 start_idx, tot_macs, num_macs, idx =0 , count =0 , em_macs =0 ;struct netdev_hw_addr *ha; start_idx =be16_to_cpu (macs->start_idx);
@@ -359,8 +359,10 @@ void opa_vnic_query_ucast_macs(struct op/* Do not include EM specified MAC address */ if (!memcmp (adapter->info.vport.base_mac_addr, ha->addr, -ARRAY_SIZE (adapter->info.vport.base_mac_addr))) +ARRAY_SIZE (adapter->info.vport.base_mac_addr))) { + em_macs++;continue ; + }if (start_idx > idx++)continue ;
@@ -383,7 +385,7 @@ void opa_vnic_query_ucast_macs(struct op } tot_macs =netdev_hw_addr_list_count (&adapter->netdev->dev_addrs) + -netdev_uc_count (adapter->netdev); +netdev_uc_count (adapter->netdev) - em_macs; macs->tot_macs_in_lst =cpu_to_be16 (tot_macs); macs->num_macs_in_msg =cpu_to_be16 (count); macs->gen_count =cpu_to_be16 (adapter->info.vport.uc_macs_gen_count);
Greg Kroah-Hartman
maintainerPATCH 155/159 thermal/drivers/hisi: Fix missing interrupt enablement
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Lezcano <[email protected]>
commit c176b10b025acee4dc8f2ab1cd64eb73b5ccef53 upstream.
The interrupt for the temperature threshold is not enabled at the end of the probe function, enable it after the setup is complete.
On the other side, the irq_enabled is not correctly set as we are checking if the interrupt is masked where 'yes' means irq_enabled=false.
irq_get_irqchip_state(data->irq, IRQCHIP_STATE_MASKED, &data->irq_enabled);
As we are always enabling the interrupt, it is pointless to check if the interrupt is masked or not, just set irq_enabled to 'true'.
--- drivers/thermal/hisi_thermal.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/thermal/hisi_thermal.c +3 -2
@@ -345,8 +345,7 @@ static int hisi_thermal_probe(struct pla }hisi_thermal_enable_bind_irq_sensor (data); -irq_get_irqchip_state (data->irq,IRQCHIP_STATE_MASKED , - &data->irq_enabled); + data->irq_enabled = true;for (i =0 ; i <HISI_MAX_SENSORS ; ++i) { ret = hisi_thermal_register_sensor(pdev, data,
@@ -358,6 +357,8 @@ static int hisi_thermal_probe(struct plahisi_thermal_toggle_sensor (&data->sensors[i], true); } +enable_irq (data->irq); +return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 156/159 thermal/drivers/hisi: Fix kernel panic on alarm interrupt
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Lezcano <[email protected]>
commit 2cb4de785c40d4a2132cfc13e63828f5a28c3351 upstream.
The threaded interrupt for the alarm interrupt is requested before the temperature controller is setup. This one can fire an interrupt immediately leading to a kernel panic as the sensor data is not initialized.
In order to prevent that, move the threaded irq after the Tsensor is setup.
--- drivers/thermal/hisi_thermal.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
drivers/thermal/hisi_thermal.c +9 -9
@@ -317,15 +317,6 @@ static int hisi_thermal_probe(struct plaif (data->irq <0 )return data->irq; - ret =devm_request_threaded_irq (&pdev->dev, data->irq, - hisi_thermal_alarm_irq, - hisi_thermal_alarm_irq_thread, -0 ,"hisi_thermal" , data); -if (ret <0 ) { -dev_err (&pdev->dev,"failed to request alarm irq: %d\n" , ret); -return ret; - } -platform_set_drvdata (pdev, data); data->clk =devm_clk_get (&pdev->dev,"thermal_clk" );
@@ -357,6 +348,15 @@ static int hisi_thermal_probe(struct plahisi_thermal_toggle_sensor (&data->sensors[i], true); } + ret =devm_request_threaded_irq (&pdev->dev, data->irq, + hisi_thermal_alarm_irq, + hisi_thermal_alarm_irq_thread, +0 ,"hisi_thermal" , data); +if (ret <0 ) { +dev_err (&pdev->dev,"failed to request alarm irq: %d\n" , ret); +return ret; + } +enable_irq (data->irq);return 0 ;
Greg Kroah-Hartman
maintainerPATCH 157/159 thermal/drivers/hisi: Simplify the temperature/step computation
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Lezcano <[email protected]>
commit 48880b979cdc9ef5a70af020f42b8ba1e51dbd34 upstream.
The step and the base temperature are fixed values, we can simplify the computation by converting the base temperature to milli celsius and use a pre-computed step value. That saves us a lot of mult + div for nothing at runtime.
Take also the opportunity to change the function names to be consistent with the rest of the code.
--- drivers/thermal/hisi_thermal.c | 41 ++++++++++++++++++++++++++++------------- 1 file changed, 28 insertions(+), 13 deletions(-)
drivers/thermal/hisi_thermal.c +28 -13
@@ -35,8 +35,9 @@#define TEMP0_RST_MSK (0x1C)#define TEMP0_VALUE (0x28) -#define HISI_TEMP_BASE (-60) +#define HISI_TEMP_BASE (-60000)#define HISI_TEMP_RESET (100000) +#define HISI_TEMP_STEP (784)#define HISI_MAX_SENSORS 4
@@ -61,19 +62,32 @@ struct hisi_thermal_data {void __iomem *regs; }; -/* in millicelsius */ -static inline int _step_to_temp (int step) +/* +* The temperature computation on the tsensor is as follow: +* Unit: millidegree Celsius +* Step: 255/200 (0.7843) +* Temperature base: -60°C +* +* The register is programmed in temperature steps, every step is 784 +* millidegree and begins at -60 000 m°C +* +* The temperature from the steps: +* +* Temp = TempBase + (steps x 784) +* +* and the steps from the temperature: +* +* steps = (Temp - TempBase) / 784 +* +*/ +static inline int hisi_thermal_step_to_temp (int step) { -/* -* Every step equals (1 * 200) / 255 celsius, and finally -* need convert to millicelsius. -*/ -return (HISI_TEMP_BASE *1000 + (step *200000 /255 )); +return HISI_TEMP_BASE + (step *HISI_TEMP_STEP ); } -static inline long _temp_to_step (long temp) +static inline long hisi_thermal_temp_to_step (long temp) { -return ((temp -HISI_TEMP_BASE *1000 ) *255 ) /200000 ; +return (temp -HISI_TEMP_BASE ) /HISI_TEMP_STEP ; } static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data,
@@ -99,7 +113,7 @@ static long hisi_thermal_get_sensor_tempusleep_range (3000 ,5000 ); val =readl (data->regs +TEMP0_VALUE ); - val =_step_to_temp (val); + val =hisi_thermal_step_to_temp (val);mutex_unlock (&data->thermal_lock);
@@ -126,10 +140,11 @@ static void hisi_thermal_enable_bind_irqwritel ((sensor->id <<12 ), data->regs +TEMP0_CFG );/* enable for interrupt */ -writel (_temp_to_step (sensor->thres_temp) |0x0FFFFFF00 , +writel (hisi_thermal_temp_to_step (sensor->thres_temp) |0x0FFFFFF00 , data->regs +TEMP0_TH ); -writel (_temp_to_step (HISI_TEMP_RESET ), data->regs +TEMP0_RST_TH ); +writel (hisi_thermal_temp_to_step (HISI_TEMP_RESET ), + data->regs +TEMP0_RST_TH );/* enable module */ writel (0x1 , data->regs +TEMP0_RST_MSK );
Greg Kroah-Hartman
maintainerPATCH 158/159 thermal/drivers/hisi: Fix multiple alarm interrupts firing
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Lezcano <[email protected]>
commit db2b0332608c8e648ea1e44727d36ad37cdb56cb upstream.
The DT specifies a threshold of 65000, we setup the register with a value in the temperature resolution for the controller, 64656.
When we reach 64656, the interrupt fires, the interrupt is disabled. Then the irq thread runs and calls thermal_zone_device_update() which will call in turn hisi_thermal_get_temp().
The function will look if the temperature decreased, assuming it was more than 65000, but that is not the case because the current temperature is 64656 (because of the rounding when setting the threshold). This condition being true, we re-enable the interrupt which fires immediately after exiting the irq thread. That happens again and again until the temperature goes to more than 65000.
Potentially, there is here an interrupt storm if the temperature stabilizes at this temperature. A very unlikely case but possible.
In any case, it does not make sense to handle dozens of alarm interrupt for nothing.
Fix this by rounding the threshold value to the controller resolution so the check against the threshold is consistent with the one set in the controller.
--- drivers/thermal/hisi_thermal.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
drivers/thermal/hisi_thermal.c +8 -2
@@ -90,6 +90,12 @@ static inline long hisi_thermal_temp_to_return (temp -HISI_TEMP_BASE ) /HISI_TEMP_STEP ; } +static inline long hisi_thermal_round_temp (int temp) +{ +return hisi_thermal_step_to_temp ( +hisi_thermal_temp_to_step (temp)); +} +static long hisi_thermal_get_sensor_temp (struct hisi_thermal_data *data,struct hisi_thermal_sensor *sensor) {
@@ -245,7 +251,7 @@ static irqreturn_t hisi_thermal_alarm_ir sensor = &data->sensors[data->irq_bind_sensor];dev_crit (&data->pdev->dev,"THERMAL ALARM: T > %d\n" , - sensor->thres_temp /1000 ); + sensor->thres_temp);mutex_unlock (&data->thermal_lock);for (i =0 ; i <HISI_MAX_SENSORS ; i++) {
@@ -284,7 +290,7 @@ static int hisi_thermal_register_sensor(for (i =0 ; i <of_thermal_get_ntrips (sensor->tzd); i++) {if (trip[i].type ==THERMAL_TRIP_PASSIVE ) { - sensor->thres_temp = trip[i].temperature; + sensor->thres_temp =hisi_thermal_round_temp (trip[i].temperature);break ; } }
Greg Kroah-Hartman
maintainerPATCH 159/159 platform/x86: asus-wireless: send an EV_SYN/SYN_REPORT between state changes
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Hutterer <[email protected]>
commit bff5bf9db1c9453ffd0a78abed3e2d040c092fd9 upstream.
Sending the switch state change twice within the same frame is invalid evdev protocol and only works if the client handles keys immediately as well. Processing events immediately is incorrect, it forces a fake order of events that does not exist on the device.
Recent versions of libinput changed to only process the device state and SYN_REPORT time, so now the key event is lost.
https://bugs.freedesktop.org/show_bug.cgi?id=104041
--- drivers/platform/x86/asus-wireless.c | 1 + 1 file changed, 1 insertion(+)
drivers/platform/x86/asus-wireless.c +1 -0
@@ -118,6 +118,7 @@ static void asus_wireless_notify(structreturn ; }input_report_key (data->idev,KEY_RFKILL ,1 ); +input_sync (data->idev);input_report_key (data->idev,KEY_RFKILL ,0 );input_sync (data->idev); }
Greg Kroah-Hartman
maintainerQuoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.9 release. There are 159 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 8 lines
Responses should be made by Sun Dec 24 08:45:36 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.9-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.
Ok, that blew up hard on arm64, there's now a -rc2 out with a fix for that. Hopefully :)
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.9-rc2.gz
thanks,
greg k-h
Greg Kroah-Hartman
maintainerQuoted 15 lines · Greg Kroah-Hartman
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.9 release. There are 159 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 8 lines
Responses should be made by Sun Dec 24 08:45:36 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.9-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.
Quoted 4 lines
Ok, that blew up hard on arm64, there's now a -rc2 out with a fix for that. Hopefully :)
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.9-rc2.gz
And because it's just been one of those weeks, there's now a -rc3 out due to a bunch of important BPF patches.
I'll stop now to give you all a chance to test...
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.9-rc3.gz
thanks,
greg k-h
Quoted 19 lines · Greg Kroah-Hartman
Quoted 18 lines · Greg Kroah-Hartman
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.9 release. There are 159 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 8 lines
Responses should be made by Sun Dec 24 08:45:36 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.9-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.Ok, that blew up hard on arm64, there's now a -rc2 out with a fix for that. Hopefully :)
Quoted 8 lines
Quoted 1 line
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.9-rc2.gz
And because it's just been one of those weeks, there's now a -rc3 out due to a bunch of important BPF patches.
I'll stop now to give you all a chance to test...
I can't keep up with this. I'll let my builders try again tonight and report tomorrow.
This is what I have so far.
h8300 builds are broken.
include/linux/compiler.h:344:2: error:
implicit declaration of function ‘smp_read_barrier_depends’
Seen when building arch/h8300/kernel/asm-offsets.c.
sparc32 builds are broken with the same error, in this case when building init/do_mounts_initrd.c.
Guenter
Greg Kroah-Hartman
maintainerQuoted 36 lines · Guenter Roeck
Quoted 19 lines · Greg Kroah-Hartman
Quoted 18 lines · Greg Kroah-Hartman
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.9 release. There are 159 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 8 lines
Responses should be made by Sun Dec 24 08:45:36 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.9-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.Ok, that blew up hard on arm64, there's now a -rc2 out with a fix for that. Hopefully :)
Quoted 8 lines
Quoted 1 line
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.9-rc2.gz
And because it's just been one of those weeks, there's now a -rc3 out due to a bunch of important BPF patches.
I'll stop now to give you all a chance to test...
I can't keep up with this. I'll let my builders try again tonight and report tomorrow.
This is what I have so far.
h8300 builds are broken.
Quoted 7 lines
include/linux/compiler.h:344:2: error:
implicit declaration of function ‘smp_read_barrier_depends’Seen when building
arch/h8300/kernel/asm-offsets.c.sparc32 builds are broken with the same error, in this case when building
init/do_mounts_initrd.c.
Ok, I think I found the problem for this, and have added a fix to the tree. It builds here for x86 for me, I'll watch your builders and see how it goes...
thanks,
greg k-h
Quoted 40 lines · Greg Kroah-Hartman
Quoted 39 lines · Guenter Roeck
Quoted 19 lines · Greg Kroah-Hartman
Quoted 18 lines · Greg Kroah-Hartman
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.9 release. There are 159 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 8 lines
Responses should be made by Sun Dec 24 08:45:36 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.9-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.Ok, that blew up hard on arm64, there's now a -rc2 out with a fix for that. Hopefully :)
Quoted 8 lines
Quoted 1 line
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.9-rc2.gz
And because it's just been one of those weeks, there's now a -rc3 out due to a bunch of important BPF patches.
I'll stop now to give you all a chance to test...
I can't keep up with this. I'll let my builders try again tonight and report tomorrow.
This is what I have so far.
h8300 builds are broken.
include/linux/compiler.h:344:2: error:
implicit declaration of function ‘smp_read_barrier_depends’
Quoted 9 lines
Quoted 4 lines
Seen when building
arch/h8300/kernel/asm-offsets.c.sparc32 builds are broken with the same error, in this case when building
init/do_mounts_initrd.c.Ok, I think I found the problem for this, and have added a fix to the tree. It builds here for x86 for me, I'll watch your builders and see how it goes...
This is now fixed. I'll send a complete build report after all builds are complete.
Guenter
A message that is not in the archive (sent off-list or not yet received): [email protected]
Greg Kroah-Hartman
maintainerQuoted 34 lines · kernelci.org bot
stable-rc/linux-4.14.y boot: 136 boots: 12 failed, 111 passed with 12 offline, 1 untried/unknown (v4.14.8-159-gc2a94d1a6095)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.8-159-gc2a94d1a6095/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.8-159-gc2a94d1a6095/Tree: stable-rc
Branch: linux-4.14.y
Git Describe: v4.14.8-159-gc2a94d1a6095
Git Commit:c2a94d1a60958294af33649f908960c536a206d5
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 76 unique boards, 23 SoC families, 17 builds out of 185Boot Regressions Detected:
arm:
exynos_defconfig: exynos5250-arndale: lab-baylibre-seattle: failing since 6 days (last pass: v4.14.5-97-gcdda4aaafa84 - first fail: v4.14.6)arm64:
defconfig: hip07-d05_rootfs:nfs: lab-collabora: new failure (last pass: v4.14.8-63-gbbedfb07d3bf) meson-gxbb-p200: lab-baylibre-seattle: new failure (last pass: v4.14.8-63-gbbedfb07d3bf) meson-gxl-s905d-p230: lab-baylibre-seattle: new failure (last pass: v4.14.8-63-gbbedfb07d3bf) meson-gxl-s905x-khadas-vim: lab-baylibre-seattle: new failure (last pass: v4.14.8-63-gbbedfb07d3bf) meson-gxl-s905x-nexbox-a95x: lab-baylibre-seattle: new failure (last pass: v4.14.8-63-gbbedfb07d3bf) meson-gxl-s905x-p212:
Quoted 8 lines
lab-baylibre-seattle: new failure (last pass: v4.14.8-63-gbbedfb07d3bf)
qemu:
lab-mhart: new failure (last pass: v4.14.8-63-gbbedfb07d3bf)
lab-collabora: new failure (last pass: v4.14.8-64-g6b2f7746b2ea)
r8a7796-m3ulcb:
lab-collabora: new failure (last pass: v4.14.8-63-gbbedfb07d3bf)
rk3399-firefly:
lab-baylibre-seattle: new failure (last pass: v4.14.8-63-gbbedfb07d3bf)These should all now be fixed with the -rc2 release, sorry about that.
My arm64 box here is dead, so I couldn't test it locally :(
greg k-h
Greg Kroah-Hartman
maintainerQuoted 44 lines · Greg Kroah-Hartman
Quoted 34 lines · kernelci.org bot
stable-rc/linux-4.14.y boot: 136 boots: 12 failed, 111 passed with 12 offline, 1 untried/unknown (v4.14.8-159-gc2a94d1a6095)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.8-159-gc2a94d1a6095/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.8-159-gc2a94d1a6095/Tree: stable-rc
Branch: linux-4.14.y
Git Describe: v4.14.8-159-gc2a94d1a6095
Git Commit:c2a94d1a60958294af33649f908960c536a206d5
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 76 unique boards, 23 SoC families, 17 builds out of 185Boot Regressions Detected:
arm:
exynos_defconfig: exynos5250-arndale: lab-baylibre-seattle: failing since 6 days (last pass: v4.14.5-97-gcdda4aaafa84 - first fail: v4.14.6)arm64:
defconfig: hip07-d05_rootfs:nfs: lab-collabora: new failure (last pass: v4.14.8-63-gbbedfb07d3bf) meson-gxbb-p200: lab-baylibre-seattle: new failure (last pass: v4.14.8-63-gbbedfb07d3bf) meson-gxl-s905d-p230: lab-baylibre-seattle: new failure (last pass: v4.14.8-63-gbbedfb07d3bf) meson-gxl-s905x-khadas-vim: lab-baylibre-seattle: new failure (last pass: v4.14.8-63-gbbedfb07d3bf) meson-gxl-s905x-nexbox-a95x: lab-baylibre-seattle: new failure (last pass: v4.14.8-63-gbbedfb07d3bf) meson-gxl-s905x-p212:Quoted 8 lines
lab-baylibre-seattle: new failure (last pass: v4.14.8-63-gbbedfb07d3bf) qemu: lab-mhart: new failure (last pass: v4.14.8-63-gbbedfb07d3bf) lab-collabora: new failure (last pass: v4.14.8-64-g6b2f7746b2ea) r8a7796-m3ulcb: lab-collabora: new failure (last pass: v4.14.8-63-gbbedfb07d3bf) rk3399-firefly: lab-baylibre-seattle: new failure (last pass: v4.14.8-63-gbbedfb07d3bf)
Quoted 3 lines
These should all now be fixed with the -rc2 release, sorry about that.
My arm64 box here is dead, so I couldn't test it locally :(
Ok, the box now works just fine, it was my fault. I'm updating it right now and will get it up and working as part of my test systems next week.
thanks,
greg "oh the silver thing is a power button?" k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.9 release. There are 159 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun Dec 24 08:45:36 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.9-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions,
thanks,
-- Shuah
Greg Kroah-Hartman
maintainerQuoted 15 lines · Shuah Khan
Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.9 release. There are 159 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun Dec 24 08:45:36 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.9-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.
Quoted 6 lines
Quoted 4 lines
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions,
Great, thanks for testing all of these and letting me know.
greg k-h
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.9 release. There are 159 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 8 lines
Responses should be made by Sun Dec 24 08:45:36 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.9-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.
Results from Linaro - 4.14.9-rc3 looks good. No regressions on arm64, arm, or x86_64.
Summary
------------------------------------------------------------------------
kernel: 4.14.9-rc3
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: a8cfbfd47f96dfffa64be8567174a00e4dfc1458
git describe: v4.14.8-175-ga8cfbfd47f96
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.8-175-ga8cfbfd47f96
No regressions (compared to build v4.14.8-161-gc51876d1903b)
Boards, architectures and test suites:
-------------------------------------
hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 46, skip: 16
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 983, skip: 121
* ltp-timers-tests - pass: 12,
juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 45, skip: 17
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 987, skip: 121
* ltp-timers-tests - pass: 12,
x15 - arm
* boot - pass: 20,
* kselftest - pass: 41, skip: 20
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1037, skip: 66
* ltp-timers-tests - pass: 12,
x86_64
* boot - pass: 20,
* kselftest - pass: 58, skip: 17
* libhugetlbfs - pass: 89, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1005, skip: 116
* ltp-timers-tests - pass: 12,
Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Greg Kroah-Hartman
maintainerQuoted 9 lines · Dan Rue
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.9 release. There are 159 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun Dec 24 08:45:36 UTC 2017. Anything received after that time might be too late.
Quoted 8 lines
Quoted 5 lines
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.9-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.Results from Linaro - 4.14.9-rc3 looks good. No regressions on arm64, arm, or
x86_64.
That's amazing, it was a pain to get out :)
Thanks for testing and letting me know.
greg k-h
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.9 release. There are 159 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun Dec 24 08:45:36 UTC 2017. Anything received after that time might be too late.
For v4.14.8-176-g3b153f8:
Build results:
total: 145 pass: 145 fail: 0 Qemu test results: total: 126 pass: 126 fail: 0
Guenter
Greg Kroah-Hartman
maintainerQuoted 10 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.9 release. There are 159 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun Dec 24 08:45:36 UTC 2017. Anything received after that time might be too late.
Quoted 6 lines
For v4.14.8-176-g3b153f8:
Build results:
total: 145 pass: 145 fail: 0 Qemu test results: total: 126 pass: 126 fail: 0
Wonderful, thanks for letting me know!
greg k-h
Quoted 11 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.9 release. There are 159 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun Dec 24 08:45:36 UTC 2017. Anything received after that time might be too late.
Josh Poimboeuf <[email protected]>
x86/unwind: MakeCONFIG_UNWINDER_ORC=ythe default in kconfig for 64-bit
This is uncovering a very difficult-to-debug build failure with NVIDIA DKMS:
with CONFIG_UNWINDER_ORC=y, out-of-tree modules hit this rule in scripts/Makefile.build:
$(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep) FORCE
and fail (here, at least) to build tools/objtool/objtool (note: I do have libelf-dev installed)
After editing dkms.conf to do make --debug=a -j1, I see make output:
Considering target file
'/var/lib/dkms/nvidia-current/387.34/build/nvidia/nv-gpu-numa.o'.
File '/var/lib/dkms/nvidia-current/387.34/build/nvidia/nv-gpu-numa.o'
does not exist.
Looking for an implicit rule for
'/var/lib/dkms/nvidia-current/387.34/build/nvidia/nv-gpu-numa.o'.
[...]
Trying rule prerequisite 'tools/objtool/objtool'.
Looking for a rule with intermediate file 'tools/objtool/objtool'.
Avoiding implicit rule recursion.
then silently fail to build objtool, silently fail to build all the .o files, then continue until ld finally errors out trying to link nonexistent object files.
If things look alright to you, and objtool is known to work with out-of-tree modules, and the Debian packaging just needs to be adjusted, please ignore; I figured I'd send this anyway because it was such a pain to debug.
Thanks,
Ivan
Quoted 697 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.9 release. There are 159 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun Dec 24 08:45:36 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.9-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:Greg Kroah-Hartman <[email protected]>
Linux 4.14.9-rc1Peter Hutterer <[email protected]>
platform/x86: asus-wireless: send an EV_SYN/SYN_REPORT between state changesDaniel Lezcano <[email protected]>
thermal/drivers/hisi: Fix multiple alarm interrupts firingDaniel Lezcano <[email protected]>
thermal/drivers/hisi: Simplify the temperature/step computationDaniel Lezcano <[email protected]>
thermal/drivers/hisi: Fix kernel panic on alarm interruptDaniel Lezcano <[email protected]>
thermal/drivers/hisi: Fix missing interrupt enablementNiranjana Vishwanathapura <[email protected]>
IB/opa_vnic: Properly return the total MACs in UC MAC listScott Franco <[email protected]>
IB/opa_vnic: Properly clear Mac Table DigestEric Anholt <[email protected]>
drm/vc4: Avoid using vrefresh==0 mode in DSI htotal math.Nicholas Piggin <[email protected]>
cpuidle: fix broadcast control when broadcast can not be enteredAlexandre Belloni <[email protected]>
rtc: set the alarm to the next expiring timerHoang Tran <[email protected]>
tcp: fix under-evaluated ssthresh in TCP VegasChen-Yu Tsai <[email protected]>
clk: sunxi-ng: sun6i: Rename HDMI DDC clock to avoid name collisionArvind Yadav <[email protected]>
staging: greybus: light: Release memory obtained by kasprintfWei Hu(Xavier) <[email protected]>
RDMA/hns: Avoid NULL pointer exceptionMike Manning <[email protected]>
net: ipv6: send NS for DAD when link operationally upMick Tarsel <[email protected]>
ibmvnic: Set state UPJacob Keller <[email protected]>
fm10k: ensure we process SM mbx when processing VF mbxMarek Szyprowski <[email protected]>
ARM:exynos_defconfig: Enable UAS support for Odroid HC1 boardAlex Williamson <[email protected]>
vfio/pci: Virtualize Maximum Payload SizeAlan Brady <[email protected]>
i40e: fix client notify of VF resetDick Kennedy <[email protected]>
scsi: lpfc: Fix warning messages whenNVME_TARGET_FCnot definedDick Kennedy <[email protected]>
scsi: lpfc: PLOGI failures during NPIV testingDick Kennedy <[email protected]>
scsi: lpfc: Fix secure firmware updatesJacob Keller <[email protected]>
fm10k: fix mis-ordered parameters in declaration for .ndo_set_vf_bwNicolas Dechesne <[email protected]>
ASoC: codecs: msm8916-wcd-analog: fix module autoloadMarcelo Ricardo Leitner <[email protected]>
sctp: silence warns onsctp_stream_initallocationsNicholas Piggin <[email protected]>
powerpc/watchdog: Do not trigger SMP crash fromtouch_nmi_watchdogNicholas Piggin <[email protected]>
powerpc/xmon: Avoid tripping SMP hardlockup watchdogEd Blake <[email protected]>
ASoC: img-parallel-out: Add pm_runtime_get/put toset_fmtcallbackJean-François Têtu <[email protected]>
ASoC: codecs: msm8916-wcd-analog: fix micbias levelTom Zanussi <[email protected]>
tracing: Exclude 'generic fields' from histogramsGabriele Paoloni <[email protected]>
PCI/AER: Report non-fatal errors only to the affected endpointJacob Keller <[email protected]>
i40e/i40evf: spread CPU affinity hints across online CPUs onlyHans de Goede <[email protected]>
Bluetooth:hci_bcm: Fix setting of irq trigger typeHans de Goede <[email protected]>
Bluetooth:hci_uart_set_flow_control: Fix NULL deref when using serdevAndrew Jeffery <[email protected]>
leds: pca955x: Don't invert requested value inpca955x_gpio_set_value()Wei Wang <[email protected]>
ipv6: grab rt->rt6i_ref before allocating pcpu rtWilliam Tu <[email protected]>
ip_gre: check packet length and mtu correctly in erspan txGuoqing Jiang <[email protected]>
md: always setTHREAD_WAKEUPand wake up wqueue if thread existedLuca Miccio <[email protected]>
block,bfq: Disable writeback throttlingColin Ian King <[email protected]>
IB/rxe: check for allocation failure on elemEmil Tantilov <[email protected]>
ixgbe: fix use of uninitialized paddingLorenzo Bianconi <[email protected]>
iio:st_sensors: add register mask for status registerLihong Yang <[email protected]>
i40e: use the safe hash table iterator when deleting mac filtersChristophe JAILLET <[email protected]>
igb: check memory allocation failureFabio Estevam <[email protected]>
PM / OPP: Move error message to debug levelStuart Hayes <[email protected]>
PCI: Create SR-IOV virtfn/physfn links before attaching driverSreekanth Reddy <[email protected]>
scsi: mpt3sas: Fix IO error occurs on pulling out a drive from RAID1 volume created on two SATA driveVarun Prakash <[email protected]>
scsi: cxgb4i: fix Tx skb leakDavid Daney <[email protected]>
PCI: Avoid bus reset if bridge itself is brokenDan Murphy <[email protected]>
net: phy: at803x: Change error to EINVAL for invalid MACShakeel Butt <[email protected]>
kvm, mm: account kvm related kmem slabs to kmemcgRussell King <[email protected]>
rtc: pl031: make interrupt optionalChristophe Jaillet <[email protected]>
crypto: lrw - Fix an error handling path in 'create()'Christian Lamparter <[email protected]>
crypto: crypto4xx - increase context and scatter ring buffer elementsChen-Yu Tsai <[email protected]>
clk: sunxi-ng: sun5i: Fix bit offset of audio PLL post-dividerChen-Yu Tsai <[email protected]>
clk: sunxi-ng: nm: Check if requested rate is supported by fractional clockShashank Sharma <[email protected]>
drm: Add retries for lspcon mode detectionDerek Basehore <[email protected]>
backlight:pwm_bl: Fix overflow conditionJens Wiklander <[email protected]>
optee: fix invalidof_node_put()inoptee_driver_init()Thomas Gleixner <[email protected]>
x86/cpufeatures: Make CPU bugs stickyThomas Gleixner <[email protected]>
x86/paravirt: Provide a way to check for hypervisorsThomas Gleixner <[email protected]>
x86/paravirt: Dont patchflush_tlb_singleAndy Lutomirski <[email protected]>
x86/entry/64: Make cpu_entry_area.tss read-onlyAndy Lutomirski <[email protected]>
x86/entry: Clean up theSYSENTER_stackcodeAndy Lutomirski <[email protected]>
x86/entry/64: Remove the SYSENTER stack canaryAndy Lutomirski <[email protected]>
x86/entry/64: Move the IST stacks into structcpu_entry_areaAndy Lutomirski <[email protected]>
x86/entry/64: Create a per-CPU SYSCALL entry trampolineAndy Lutomirski <[email protected]>
x86/entry/64: Return to userspace from the trampoline stackAndy Lutomirski <[email protected]>
x86/entry/64: Use a per-CPU trampoline stack for IDT entriesAndy Lutomirski <[email protected]>
x86/espfix/64: Stop assuming thatpt_regsis on the entry stackAndy Lutomirski <[email protected]>
x86/entry/64: Separatecpu_current_top_of_stackfrom TSS.sp0Andy Lutomirski <[email protected]>
x86/entry: Remap the TSS into the CPU entry areaAndy Lutomirski <[email protected]>
x86/entry: MoveSYSENTER_stackto the beginning of structtss_structAndy Lutomirski <[email protected]>
x86/dumpstack: Handle stack overflow on all stacksAndy Lutomirski <[email protected]>
x86/entry: Fix assumptions that the HW TSS is at the beginning ofcpu_tssAndy Lutomirski <[email protected]>
x86/kasan/64: Teach KASAN about thecpu_entry_areaAndy Lutomirski <[email protected]>
x86/mm/fixmap: Generalize the GDT fixmap mechanism, introduce structcpu_entry_areaAndy Lutomirski <[email protected]>
x86/entry/gdt: Put per-CPU GDT remaps in ascending orderAndy Lutomirski <[email protected]>
x86/dumpstack: Addget_stack_info()support for the SYSENTER stackAndy Lutomirski <[email protected]>
x86/entry/64: Allocate and enable the SYSENTER stackAndy Lutomirski <[email protected]>
x86/irq/64: Print the offending IP in the stack overflow warningAndy Lutomirski <[email protected]>
x86/irq: Remove an old outdated comment about context tracking racesJosh Poimboeuf <[email protected]>
x86/unwinder: Handle stack overflows more gracefullyAndy Lutomirski <[email protected]>
x86/unwinder/orc: Dont bail on stack overflowBoris Ostrovsky <[email protected]>
x86/entry/64/paravirt: Use paravirt-safe macro to access eflagsAndrey Ryabinin <[email protected]>
x86/mm/kasan: Don't usevmemmap_populate()to initialize shadowWill Deacon <[email protected]>
locking/barriers: Convert users oflockless_dereference()toREAD_ONCE()Will Deacon <[email protected]>
locking/barriers: Add implicitsmp_read_barrier_depends()toREAD_ONCE()Daniel Borkmann <[email protected]>
bpf: fix build issues on um due to misingbpf_perf_event.hAndi Kleen <[email protected]>
perf/x86: Enable free running PEBS for REGS_USER/INTRRudolf Marek <[email protected]>
x86: MakeX86_BUG_FXSAVE_LEAKdetectable in CPUID on AMDRicardo Neri <[email protected]>
x86/cpufeature: Add User-Mode Instruction Prevention definitionsIngo Molnar <[email protected]>
drivers/misc/intel/pti: Rename the header file to free up the namespaceJuergen Gross <[email protected]>
x86/virt: Add enum for hypervisors to replacex86_hyperJuergen Gross <[email protected]>
x86/virt, x86/platform: Merge 'structx86_hyper' into 'structx86_platform' and 'structx86_init'James Morse <[email protected]>
ACPI / APEI: Replaceioremap_page_range()with fixmapAndy Lutomirski <[email protected]>
selftests/x86/ldt_gdt: Run most existing LDT test cases against the GDT as wellAndy Lutomirski <[email protected]>
selftests/x86/ldt_gdt: Add infrastructure to testset_thread_area()Ingo Molnar <[email protected]>
x86/cpufeatures: Fix various details in the feature definitionsIngo Molnar <[email protected]>
x86/cpufeatures: Re-tabulate theX86_FEATUREdefinitionsBorislav Petkov <[email protected]>
x86/mm: Define_PAGE_TABLEusing_KERNPG_TABLEThomas Gleixner <[email protected]>
bitops: Revert cbe96375025e ("bitops: Add clear/set_bit32() to linux/bitops.h")Thomas Gleixner <[email protected]>
x86/cpuid: Replace set/clear_bit32()Borislav Petkov <[email protected]>
x86/entry/64: Shorten TEST instructionsAndy Lutomirski <[email protected]>
x86/traps: Use a newon_thread_stack()helper to clean up an assertionAndy Lutomirski <[email protected]>
x86/entry/64: Remove thread_struct::sp0Andy Lutomirski <[email protected]>
x86/entry/32: Fixcpu_current_top_of_stackinitialization at bootAndy Lutomirski <[email protected]>
x86/entry/64: Remove all remaining directthread_struct::sp0readsAndy Lutomirski <[email protected]>
x86/entry/64: Stop initializing TSS.sp0 at bootAndy Lutomirski <[email protected]>
x86/xen/64, x86/entry/64: Clean up SP code in cpu_initialize_context()Andy Lutomirski <[email protected]>
x86/entry: Addtask_top_of_stack()to find the top of a task's stackAndy Lutomirski <[email protected]>
x86/entry/64: Pass SP0 directly to load_sp0()Andy Lutomirski <[email protected]>
x86/entry/32: Pull theMSR_IA32_SYSENTER_CSupdate code out ofnative_load_sp0()Andy Lutomirski <[email protected]>
x86/entry/64: De-Xen-ify our NMI codeJuergen Gross <[email protected]>
xen, x86/entry/64: Add xen NMI trap entryAndy Lutomirski <[email protected]>
x86/entry/64: Remove the RESTORE_..._REGS infrastructureAndy Lutomirski <[email protected]>
x86/entry/64: Use POP instead of MOV to restore regs on NMI returnAndy Lutomirski <[email protected]>
x86/entry/64: Merge the fast and slow SYSRET pathsAndy Lutomirski <[email protected]>
x86/entry/64: Use pop instead of movq insyscall_return_via_sysretAndy Lutomirski <[email protected]>
x86/entry/64: Shrinkparanoid_exit_restoreand make labels localAndy Lutomirski <[email protected]>
x86/entry/64: Simplify reg restore code in the standard IRET pathsAndy Lutomirski <[email protected]>
x86/entry/64: Move SWAPGS into the common IRET-to-usermode pathAndy Lutomirski <[email protected]>
x86/entry/64: Split the IRET-to-user and IRET-to-kernel pathsAndy Lutomirski <[email protected]>
x86/entry/64: Remove therestore_c_regs_and_iretlabelRicardo Neri <[email protected]>
ptrace,x86: Makeuser_64bit_mode()available to 32-bit buildsRicardo Neri <[email protected]>
x86/boot: Relocate definition of the initial state of CR0Ricardo Neri <[email protected]>
x86/mm: Relocate page fault error codes totraps.hGayatri Kammela <[email protected]>
x86/cpufeatures: Enable new SSE/AVX/AVX512 CPU featuresBaoquan He <[email protected]>
x86/mm/64: Rename theregister_page_bootmem_memmap()'size' parameter to 'nr_pages'Masahiro Yamada <[email protected]>
x86/build: Beautify build log of syscall headersJosh Poimboeuf <[email protected]>
x86/asm: Don't use the confusing '.ifeq' directiveDongjiu Geng <[email protected]>
ACPI / APEI: remove the unused dead-code for SEA/NMI notification typeKirill A. Shutemov <[email protected]>
x86/xen: Drop 5-level paging support code from theXEN_PVcodeKirill A. Shutemov <[email protected]>
x86/xen: Provide pre-built page tables only forCONFIG_XEN_PV=yandCONFIG_XEN_PVH=yAndrey Ryabinin <[email protected]>
x86/kasan: Use the same shadow offset for 4- and 5-level pagingKirill A. Shutemov <[email protected]>
mm/sparsemem: Allocatemem_sectionat runtime forCONFIG_SPARSEMEM_EXTREME=yThomas Gleixner <[email protected]>
x86/cpuid: Prevent out of bound access indo_clear_cpu_cap()Kamalesh Babulal <[email protected]>
objtool: Print top level commands on incorrect usageKees Cook <[email protected]>
x86/platform/UV: Convert timers to usetimer_setup()Andi Kleen <[email protected]>
x86/fpu: Remove the explicit clearing of XSAVE dependent featuresAndi Kleen <[email protected]>
x86/fpu: Make XSAVE check the base CPUID features before enablingAndi Kleen <[email protected]>
x86/fpu: Parse clearcpuid= as early XSAVE argumentAndi Kleen <[email protected]>
x86/cpuid: Add generic table for CPUID dependenciesAndi Kleen <[email protected]>
bitops: Add clear/set_bit32() tolinux/bitops.hJosh Poimboeuf <[email protected]>
x86/unwind: MakeCONFIG_UNWINDER_ORC=ythe default in kconfig for 64-bitJosh Poimboeuf <[email protected]>
x86/unwind: Rename unwinder config options to 'CONFIG_UNWINDER_*'Steven Rostedt (VMware) <[email protected]>
x86/fpu/debug: Remove unused 'x86_fpu_state' and 'x86_fpu_deactivate_state' tracepointsIngo Molnar <[email protected]>
x86/unwinder: MakeCONFIG_UNWINDER_ORC=ythe default in the 64-bit defconfigJan Beulich <[email protected]>
ACPI / APEI: adjust a local variable type inghes_ioremap_pfn_irq()Josh Poimboeuf <[email protected]>
x86/head: Add unwind hint annotationsJosh Poimboeuf <[email protected]>
x86/xen: Add unwind hint annotationsJosh Poimboeuf <[email protected]>
x86/xen: Fix xen head ELF annotationsJosh Poimboeuf <[email protected]>
x86/boot: Annotateverify_cpu()as a callable functionJosh Poimboeuf <[email protected]>
x86/head: Fix head ELF function annotationsJosh Poimboeuf <[email protected]>
x86/head: Remove unused 'bad_address' codeJosh Poimboeuf <[email protected]>
x86/head: Remove confusing commentJosh Poimboeuf <[email protected]>
objtool: Don't report end of section error after an empty unwind hintUros Bizjak <[email protected]>
x86/asm: Remove unnecessary \n\t in front ofCC_SET()from asm templates-------------
Diffstat:
Documentation/x86/orc-unwinder.txt | 2 +- Documentation/x86/x86_64/mm.txt | 2 +- Makefile | 8 +- arch/arm/configs/exynos_defconfig | 2 +- arch/arm64/include/asm/fixmap.h | 7 + arch/powerpc/kernel/watchdog.c | 7 +- arch/powerpc/xmon/xmon.c | 17 +- arch/um/include/asm/Kbuild | 1 + arch/x86/Kconfig | 5 +- arch/x86/Kconfig.debug | 39 +- arch/x86/configs/tiny.config | 4 +- arch/x86/configs/x86_64_defconfig | 1 + arch/x86/entry/calling.h | 69 +-- arch/x86/entry/entry_32.S | 6 +- arch/x86/entry/entry_64.S | 322 +++++++++--- arch/x86/entry/entry_64_compat.S | 10 +- arch/x86/entry/syscalls/Makefile | 4 +- arch/x86/events/core.c | 2 +- arch/x86/events/intel/core.c | 4 + arch/x86/events/perf_event.h | 24 +- arch/x86/hyperv/hv_init.c | 2 +- arch/x86/include/asm/archrandom.h | 8 +- arch/x86/include/asm/bitops.h | 10 +- arch/x86/include/asm/compat.h | 1 + arch/x86/include/asm/cpufeature.h | 11 +- arch/x86/include/asm/cpufeatures.h | 538 +++++++++++---------- arch/x86/include/asm/desc.h | 11 +- arch/x86/include/asm/fixmap.h | 74 ++- arch/x86/include/asm/hypervisor.h | 53 +- arch/x86/include/asm/irqflags.h | 3 + arch/x86/include/asm/kdebug.h | 1 + arch/x86/include/asm/mmu_context.h | 4 +- arch/x86/include/asm/module.h | 2 +- arch/x86/include/asm/paravirt.h | 14 +- arch/x86/include/asm/paravirt_types.h | 2 +- arch/x86/include/asm/percpu.h | 2 +- arch/x86/include/asm/pgtable_types.h | 3 +- arch/x86/include/asm/processor.h | 109 +++-- arch/x86/include/asm/ptrace.h | 6 +- arch/x86/include/asm/rmwcc.h | 2 +- arch/x86/include/asm/stacktrace.h | 3 + arch/x86/include/asm/switch_to.h | 26 + arch/x86/include/asm/thread_info.h | 2 +- arch/x86/include/asm/trace/fpu.h | 10 - arch/x86/include/asm/traps.h | 21 +- arch/x86/include/asm/unwind.h | 15 +- arch/x86/include/asm/x86_init.h | 24 + arch/x86/include/uapi/asm/processor-flags.h | 3 + arch/x86/kernel/Makefile | 10 +- arch/x86/kernel/apic/apic.c | 2 +- arch/x86/kernel/apic/x2apic_uv_x.c | 5 +- arch/x86/kernel/asm-offsets.c | 6 + arch/x86/kernel/asm-offsets_32.c | 9 +- arch/x86/kernel/asm-offsets_64.c | 4 + arch/x86/kernel/cpu/Makefile | 1 + arch/x86/kernel/cpu/amd.c | 7 +- arch/x86/kernel/cpu/common.c | 195 +++++--- arch/x86/kernel/cpu/cpuid-deps.c | 121 +++++ arch/x86/kernel/cpu/hypervisor.c | 64 +-- arch/x86/kernel/cpu/mshyperv.c | 6 +- arch/x86/kernel/cpu/vmware.c | 8 +- arch/x86/kernel/doublefault.c | 36 +- arch/x86/kernel/dumpstack.c | 74 ++- arch/x86/kernel/dumpstack_32.c | 6 + arch/x86/kernel/dumpstack_64.c | 6 + arch/x86/kernel/fpu/init.c | 11 + arch/x86/kernel/fpu/xstate.c | 43 +- arch/x86/kernel/head_32.S | 5 +- arch/x86/kernel/head_64.S | 45 +- arch/x86/kernel/ioport.c | 2 +- arch/x86/kernel/irq.c | 12 - arch/x86/kernel/irq_64.c | 4 +- arch/x86/kernel/kvm.c | 6 +- arch/x86/kernel/ldt.c | 2 +- arch/x86/kernel/paravirt_patch_64.c | 2 - arch/x86/kernel/process.c | 27 +- arch/x86/kernel/process_32.c | 8 +- arch/x86/kernel/process_64.c | 19 +- arch/x86/kernel/smpboot.c | 3 +- arch/x86/kernel/traps.c | 72 +-- arch/x86/kernel/unwind_orc.c | 88 ++-- arch/x86/kernel/verify_cpu.S | 3 +- arch/x86/kernel/vm86_32.c | 20 +- arch/x86/kernel/vmlinux.lds.S | 9 + arch/x86/kernel/x86_init.c | 9 + arch/x86/kvm/mmu.c | 4 +- arch/x86/kvm/vmx.c | 2 +- arch/x86/lib/delay.c | 4 +- arch/x86/mm/fault.c | 88 ++-- arch/x86/mm/init.c | 2 +- arch/x86/mm/init_64.c | 10 +- arch/x86/mm/kasan_init_64.c | 262 ++++++++-- arch/x86/power/cpu.c | 16 +- arch/x86/xen/enlighten_hvm.c | 12 +- arch/x86/xen/enlighten_pv.c | 15 +- arch/x86/xen/mmu_pv.c | 161 +++--- arch/x86/xen/smp_pv.c | 17 +- arch/x86/xen/xen-asm_64.S | 2 +- arch/x86/xen/xen-head.S | 11 +- block/bfq-iosched.c | 3 +- block/blk-wbt.c | 2 +- crypto/lrw.c | 6 +- drivers/acpi/apei/ghes.c | 78 +-- drivers/base/power/opp/core.c | 2 +- drivers/bluetooth/hci_bcm.c | 23 +- drivers/bluetooth/hci_ldisc.c | 7 + drivers/clk/sunxi-ng/ccu-sun5i.c | 4 +- drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 2 +- drivers/clk/sunxi-ng/ccu_nm.c | 3 + drivers/cpuidle/cpuidle.c | 1 + drivers/crypto/amcc/crypto4xx_core.h | 10 +- drivers/gpu/drm/drm_dp_dual_mode_helper.c | 16 +- drivers/gpu/drm/vc4/vc4_dsi.c | 3 +- drivers/hv/vmbus_drv.c | 2 +- drivers/iio/accel/st_accel_core.c | 35 +- drivers/iio/common/st_sensors/st_sensors_core.c | 2 +- drivers/iio/common/st_sensors/st_sensors_trigger.c | 16 +- drivers/iio/gyro/st_gyro_core.c | 15 +- drivers/iio/magnetometer/st_magn_core.c | 10 +- drivers/iio/pressure/st_pressure_core.c | 15 +- drivers/infiniband/hw/hns/hns_roce_hw_v1.c | 5 + drivers/infiniband/sw/rxe/rxe_pool.c | 2 + drivers/infiniband/ulp/opa_vnic/opa_vnic_encap.c | 1 + .../infiniband/ulp/opa_vnic/opa_vnic_vema_iface.c | 8 +- drivers/input/mouse/vmmouse.c | 10 +- drivers/leds/leds-pca955x.c | 17 +- drivers/md/dm-mpath.c | 20 +- drivers/md/md.c | 4 +- drivers/misc/pti.c | 2 +- drivers/misc/vmw_balloon.c | 2 +- drivers/net/ethernet/ibm/ibmvnic.c | 2 + drivers/net/ethernet/intel/fm10k/fm10k.h | 4 +- drivers/net/ethernet/intel/fm10k/fm10k_iov.c | 12 +- drivers/net/ethernet/intel/i40e/i40e_main.c | 16 +- drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 7 +- drivers/net/ethernet/intel/i40evf/i40evf_main.c | 9 +- drivers/net/ethernet/intel/igb/igb_main.c | 2 + drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 4 +- drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 2 + drivers/net/phy/at803x.c | 2 +- drivers/pci/iov.c | 3 +- drivers/pci/pci.c | 4 + drivers/pci/pcie/aer/aerdrv_core.c | 9 +- drivers/platform/x86/asus-wireless.c | 1 + drivers/rtc/interface.c | 2 +- drivers/rtc/rtc-pl031.c | 14 +- drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 1 + drivers/scsi/lpfc/lpfc_hbadisc.c | 3 +- drivers/scsi/lpfc/lpfc_hw4.h | 2 +- drivers/scsi/lpfc/lpfc_nvmet.c | 2 + drivers/scsi/mpt3sas/mpt3sas_scsih.c | 5 + drivers/staging/greybus/light.c | 2 + drivers/tee/optee/core.c | 1 - drivers/thermal/hisi_thermal.c | 74 ++- drivers/vfio/pci/vfio_pci_config.c | 6 +- drivers/video/backlight/pwm_bl.c | 7 +- fs/dcache.c | 4 +- fs/overlayfs/ovl_entry.h | 2 +- fs/overlayfs/readdir.c | 2 +- include/asm-generic/vmlinux.lds.h | 2 +- include/linux/compiler.h | 1 + include/linux/hypervisor.h | 8 +- include/linux/iio/common/st_sensors.h | 7 +- include/linux/{pti.h => intel-pti.h} | 6 +- include/linux/mm.h | 2 +- include/linux/mmzone.h | 6 +- include/linux/rculist.h | 4 +- include/linux/rcupdate.h | 4 +- kernel/events/core.c | 4 +- kernel/seccomp.c | 2 +- kernel/task_work.c | 2 +- kernel/trace/trace_events_hist.c | 4 +- lib/Kconfig.debug | 2 +- mm/page_alloc.c | 10 + mm/slab.h | 2 +- mm/sparse.c | 17 +- net/ipv4/ip_gre.c | 8 +- net/ipv4/tcp_vegas.c | 2 +- net/ipv6/addrconf.c | 12 +- net/ipv6/route.c | 58 +-- net/sctp/stream.c | 8 +- scripts/Makefile.build | 2 +- sound/soc/codecs/msm8916-wcd-analog.c | 9 +- sound/soc/img/img-parallel-out.c | 2 + tools/objtool/check.c | 7 +- tools/objtool/objtool.c | 6 +- tools/testing/selftests/x86/ldt_gdt.c | 61 ++- virt/kvm/kvm_main.c | 2 +- 188 files changed, 2414 insertions(+), 1428 deletions(-)
Quoted 36 lines · Ivan Kozik
Quoted 11 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.9 release. There are 159 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun Dec 24 08:45:36 UTC 2017. Anything received after that time might be too late.
Josh Poimboeuf <[email protected]>
x86/unwind: MakeCONFIG_UNWINDER_ORC=ythe default in kconfig for 64-bitThis is uncovering a very difficult-to-debug build failure with NVIDIA DKMS:
withCONFIG_UNWINDER_ORC=y, out-of-tree modules hit this rule inscripts/Makefile.build:$(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep) FORCE
and fail (here, at least) to build
tools/objtool/objtool(note: I do have libelf-dev installed)After editing dkms.conf to do
make --debug=a -j1, I see make output:Considering target file
'/var/lib/dkms/nvidia-current/387.34/build/nvidia/nv-gpu-numa.o'.
File '/var/lib/dkms/nvidia-current/387.34/build/nvidia/nv-gpu-numa.o'
does not exist.
Looking for an implicit rule for
'/var/lib/dkms/nvidia-current/387.34/build/nvidia/nv-gpu-numa.o'.
[...]
Trying rule prerequisite 'tools/objtool/objtool'.
Looking for a rule with intermediate file 'tools/objtool/objtool'.
Avoiding implicit rule recursion.
Quoted 7 lines
then silently fail to build objtool, silently fail to build all the .o files, then continue until ld finally errors out trying to link nonexistent object files.
If things look alright to you, and objtool is known to work with out-of-tree modules, and the Debian packaging just needs to be adjusted, please ignore; I figured I'd send this anyway because it was such a pain to debug.
The linux-header packages dkms builds against need to include objtool when the ORC unwinder is enabled.
Changing the default like that is a pretty big change for a stable release.
Greg Kroah-Hartman
maintainerQuoted 14 lines · Ivan Kozik
Quoted 11 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.9 release. There are 159 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun Dec 24 08:45:36 UTC 2017. Anything received after that time might be too late.
Josh Poimboeuf <[email protected]>
x86/unwind: MakeCONFIG_UNWINDER_ORC=ythe default in kconfig for 64-bit
Quoted 8 lines
This is uncovering a very difficult-to-debug build failure with NVIDIA DKMS:
withCONFIG_UNWINDER_ORC=y, out-of-tree modules hit this rule inscripts/Makefile.build:$(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep) FORCE
and fail (here, at least) to build
tools/objtool/objtool(note: I do have libelf-dev installed)
Is this problem also in Linus's tree?
Quoted 13 lines
After editing dkms.conf to do
make --debug=a -j1, I see make output:Considering target file
'/var/lib/dkms/nvidia-current/387.34/build/nvidia/nv-gpu-numa.o'.
File '/var/lib/dkms/nvidia-current/387.34/build/nvidia/nv-gpu-numa.o'
does not exist.
Looking for an implicit rule for
'/var/lib/dkms/nvidia-current/387.34/build/nvidia/nv-gpu-numa.o'.
[...]
Trying rule prerequisite 'tools/objtool/objtool'.
Looking for a rule with intermediate file 'tools/objtool/objtool'.
Avoiding implicit rule recursion.
Quoted 3 lines
then silently fail to build objtool, silently fail to build all the .o files, then continue until ld finally errors out trying to link nonexistent object files.
Is this just a bug in the nvidia Makefile somehow?
Quoted 3 lines
If things look alright to you, and objtool is known to work with out-of-tree modules, and the Debian packaging just needs to be adjusted, please ignore; I figured I'd send this anyway because it was such a pain to debug.
objtool should work with out-of-tree modules, again, try Linus's tree to verify this.
thanks,
greg k-h