5.9.10-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainercover 5.9.10-rc1 review
This is the start of the stable review cycle for the 5.9.10 release. There are 14 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, 22 Nov 2020 10:45:32 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.9.10-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.9.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 5.9.10-rc1
Nick Desaulniers <[email protected]>
ACPI: GED: fix -Wformat
David Edmondson <[email protected]>
KVM: x86: clflushopt should be treated as a no-op by emulation
Arnd Bergmann <[email protected]>
perf/x86/intel/uncore: Fix Add BW copypasta
Qian Cai <[email protected]>
powerpc/smp: Call rcu_cpu_starting() earlier
Tommi Rantala <[email protected]>
selftests/harness: prettify SKIP message whitespace again
Zhang Changzhong <[email protected]>
can: proc: can_remove_proc(): silence remove_proc_entry warning
Johannes Berg <[email protected]>
mac80211: always wind down STA state
Dmitry Torokhov <[email protected]>
Input: sunkbd - avoid use-after-free in teardown paths
Gabriel David <[email protected]>
leds: lm3697: Fix out-of-bound access
Daniel Axtens <[email protected]>
selftests/powerpc: entry flush test
Michael Ellerman <[email protected]>
powerpc: Only include kup-radix.h for 64-bit Book3S
Nicholas Piggin <[email protected]>
powerpc/64s: flush L1D after user accesses
Nicholas Piggin <[email protected]>
powerpc/64s: flush L1D on kernel entry
Russell Currey <[email protected]>
selftests/powerpc: rfi_flush: disable entry flush if present
-------------
Diffstat:
Documentation/admin-guide/kernel-parameters.txt | 7 + Makefile | 4 +- arch/powerpc/include/asm/book3s/64/kup-radix.h | 66 ++++--- arch/powerpc/include/asm/exception-64s.h | 12 +- arch/powerpc/include/asm/feature-fixups.h | 19 ++ arch/powerpc/include/asm/kup.h | 26 ++- arch/powerpc/include/asm/security_features.h | 7 + arch/powerpc/include/asm/setup.h | 4 + arch/powerpc/kernel/exceptions-64s.S | 80 +++++---- arch/powerpc/kernel/setup_64.c | 122 ++++++++++++- arch/powerpc/kernel/smp.c | 2 +- arch/powerpc/kernel/syscall_64.c | 2 +- arch/powerpc/kernel/vmlinux.lds.S | 14 ++ arch/powerpc/lib/feature-fixups.c | 104 +++++++++++ arch/powerpc/platforms/powernv/setup.c | 17 ++ arch/powerpc/platforms/pseries/setup.c | 8 + arch/x86/events/intel/uncore_snb.c | 2 +- arch/x86/kvm/emulate.c | 8 +- drivers/acpi/evged.c | 2 +- drivers/input/keyboard/sunkbd.c | 41 ++++- drivers/leds/leds-lm3697.c | 8 +- net/can/proc.c | 6 +- net/mac80211/sta_info.c | 18 ++ tools/testing/selftests/kselftest_harness.h | 2 +- .../testing/selftests/powerpc/security/.gitignore | 1 + tools/testing/selftests/powerpc/security/Makefile | 2 +- .../selftests/powerpc/security/entry_flush.c | 198 +++++++++++++++++++++ .../testing/selftests/powerpc/security/rfi_flush.c | 35 +++- 28 files changed, 719 insertions(+), 98 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/14 selftests/powerpc: rfi_flush: disable entry flush if present
From: Russell Currey <[email protected]>
commit fcb48454c23c5679d1a2e252f127642e91b05cbe upstream.
We are about to add an entry flush. The rfi (exit) flush test measures the number of L1D flushes over a syscall with the RFI flush enabled and disabled. But if the entry flush is also enabled, the effect of enabling and disabling the RFI flush is masked.
If there is a debugfs entry for the entry flush, disable it during the RFI flush and restore it later.
--- tools/testing/selftests/powerpc/security/rfi_flush.c | 35 +++++++++++++++---- 1 file changed, 29 insertions(+), 6 deletions(-)
tools/testing/selftests/powerpc/security/rfi_flush.c +29 -6
@@ -50,16 +50,30 @@ int rfi_flush_test(void)__u64 l1d_misses_total =0 ;unsigned long iterations =100000 , zero_size =24 *1024 ;unsigned long l1d_misses_expected; -int rfi_flush_org, rfi_flush; +int rfi_flush_orig, rfi_flush; +int have_entry_flush, entry_flush_orig;SKIP_IF (geteuid () !=0 ); -if (read_debugfs_file ("powerpc/rfi_flush" , &rfi_flush_org)) { +if (read_debugfs_file ("powerpc/rfi_flush" , &rfi_flush_orig) <0 ) {perror ("Unable to read powerpc/rfi_flush debugfs file" );SKIP_IF (1 ); } - rfi_flush = rfi_flush_org; +if (read_debugfs_file ("powerpc/entry_flush" , &entry_flush_orig) <0 ) { + have_entry_flush =0 ; + }else { + have_entry_flush =1 ; + +if (entry_flush_orig !=0 ) { +if (write_debugfs_file ("powerpc/entry_flush" ,0 ) <0 ) { +perror ("error writing to powerpc/entry_flush debugfs file" ); +return 1 ; + } + } + } + + rfi_flush = rfi_flush_orig; fd =perf_event_open_counter (PERF_TYPE_RAW ,/* L1d miss */ 0x400f0 ,-1 );FAIL_IF (fd <0 );
@@ -68,6 +82,7 @@ int rfi_flush_test(void)FAIL_IF (perf_event_enable (fd)); +// disable L1 prefetching set_dscr (1 ); iter = repetitions;
@@ -109,8 +124,8 @@ again: repetitions * l1d_misses_expected /2 , passes, repetitions); -if (rfi_flush == rfi_flush_org) { - rfi_flush = !rfi_flush_org; +if (rfi_flush == rfi_flush_orig) { + rfi_flush = !rfi_flush_orig;if (write_debugfs_file ("powerpc/rfi_flush" , rfi_flush) <0 ) {perror ("error writing to powerpc/rfi_flush debugfs file" );return 1 ;
@@ -126,11 +141,19 @@ again:set_dscr (0 ); -if (write_debugfs_file ("powerpc/rfi_flush" , rfi_flush_org) <0 ) { +if (write_debugfs_file ("powerpc/rfi_flush" , rfi_flush_orig) <0 ) {perror ("unable to restore original value of powerpc/rfi_flush debugfs file" );return 1 ; } +if (have_entry_flush) { +if (write_debugfs_file ("powerpc/entry_flush" , entry_flush_orig) <0 ) { +perror ("unable to restore original value of powerpc/entry_flush " +"debugfs file" ); +return 1 ; + } + } +return rc; }
Greg Kroah-Hartman
maintainerPATCH 2/14 powerpc/64s: flush L1D on kernel entry
In reply to Greg Kroah-HartmanFrom: Nicholas Piggin <[email protected]>
commit f79643787e0a0762d2409b7b8334e83f22d85695 upstream.
IBM Power9 processors can speculatively operate on data in the L1 cache before it has been completely validated, via a way-prediction mechanism. It is not possible for an attacker to determine the contents of impermissible memory using this method, since these systems implement a combination of hardware and software security measures to prevent scenarios where protected data could be leaked.
However these measures don't address the scenario where an attacker induces the operating system to speculatively execute instructions using data that the attacker controls. This can be used for example to speculatively bypass "kernel user access prevention" techniques, as discovered by Anthony Steinhauser of Google's Safeside Project. This is not an attack by itself, but there is a possibility it could be used in conjunction with side-channels or other weaknesses in the privileged code to construct an attack.
This issue can be mitigated by flushing the L1 cache between privilege boundaries of concern. This patch flushes the L1 cache on kernel entry.
This is part of the fix for CVE-2020-4788.
--- Documentation/admin-guide/kernel-parameters.txt | 3 + arch/powerpc/include/asm/exception-64s.h | 9 +++ arch/powerpc/include/asm/feature-fixups.h | 10 ++++ arch/powerpc/include/asm/security_features.h | 4 + arch/powerpc/include/asm/setup.h | 3 + arch/powerpc/kernel/exceptions-64s.S | 37 ++++++++++++++ arch/powerpc/kernel/setup_64.c | 60 +++++++++++++++++++++++- arch/powerpc/kernel/vmlinux.lds.S | 7 ++ arch/powerpc/lib/feature-fixups.c | 54 +++++++++++++++++++++ arch/powerpc/platforms/powernv/setup.c | 11 ++++ arch/powerpc/platforms/pseries/setup.c | 4 + 11 files changed, 200 insertions(+), 2 deletions(-)
Documentation/admin-guide/kernel-parameters.txt +3 -0
@@ -2833,6 +2833,7 @@ mds=off [X86] tsx_async_abort=off [X86] kvm.nx_huge_pages=off [X86] + no_entry_flush [PPC] Exceptions: This does not have any effect on
@@ -3157,6 +3158,8 @@ noefi Disable EFI runtime services support. + no_entry_flush [PPC] Don't flush the L1-D cache when entering the kernel. + noexec [IA-64] noexec [X86]
arch/powerpc/include/asm/exception-64s.h +8 -1
@@ -57,11 +57,18 @@nop ; \ nop +#define ENTRY_FLUSH_SLOT \ + ENTRY_FLUSH_FIXUP_SECTION; \ + nop; \ + nop; \ + nop; +/* * r10 must be free to use, r13 must be paca */ #define INTERRUPT_TO_KERNEL \ - STF_ENTRY_BARRIER_SLOT + STF_ENTRY_BARRIER_SLOT; \ + ENTRY_FLUSH_SLOT/* * Macros for annotating the expected destination of (h)rfid
arch/powerpc/include/asm/feature-fixups.h +10 -0
@@ -205,6 +205,14 @@ label##3: \ FTR_ENTRY_OFFSET 955b-956b; \ .popsection; +#define ENTRY_FLUSH_FIXUP_SECTION \ +957: \ + .pushsection __entry_flush_fixup,"a"; \ + .align 2; \ +958: \ + FTR_ENTRY_OFFSET 957b-958b; \ + .popsection; +#define RFI_FLUSH_FIXUP_SECTION \ 951: \ .pushsection __rfi_flush_fixup,"a"; \
@@ -237,8 +245,10 @@ label##3: \#include <linux/types.h> extern long stf_barrier_fallback; +extern long entry_flush_fallback;extern long __start___stf_entry_barrier_fixup, __stop___stf_entry_barrier_fixup;extern long __start___stf_exit_barrier_fixup, __stop___stf_exit_barrier_fixup; +extern long __start___entry_flush_fixup, __stop___entry_flush_fixup;extern long __start___rfi_flush_fixup, __stop___rfi_flush_fixup;extern long __start___barrier_nospec_fixup, __stop___barrier_nospec_fixup;extern long __start__btb_flush_fixup, __stop__btb_flush_fixup;
arch/powerpc/include/asm/security_features.h +4 -0
@@ -86,12 +86,16 @@ static inline bool security_ftr_enabled(// Software required to flush link stack on context switch #define SEC_FTR_FLUSH_LINK_STACK 0x0000000000001000ull +// The L1-D cache should be flushed when entering the kernel +#define SEC_FTR_L1D_FLUSH_ENTRY 0x0000000000004000ull +// Features enabled by default #define SEC_FTR_DEFAULT \ (SEC_FTR_L1D_FLUSH_HV | \ SEC_FTR_L1D_FLUSH_PR | \ SEC_FTR_BNDS_CHK_SPEC_BAR | \ + SEC_FTR_L1D_FLUSH_ENTRY | \ SEC_FTR_FAVOUR_SECURITY)#endif /* _ASM_POWERPC_SECURITY_FEATURES_H */
arch/powerpc/include/asm/setup.h +3 -0
@@ -52,12 +52,15 @@ enum l1d_flush_type { };void setup_rfi_flush (enum l1d_flush_type ,bool enable); +void setup_entry_flush (bool enable); +void setup_uaccess_flush (bool enable);void do_rfi_flush_fixups (enum l1d_flush_type types);#ifdef CONFIG_PPC_BARRIER_NOSPEC void setup_barrier_nospec (void );#else static inline void setup_barrier_nospec (void ) { };#endif +void do_entry_flush_fixups (enum l1d_flush_type types);void do_barrier_nospec_fixups (bool enable);extern bool barrier_nospec_enabled;
arch/powerpc/kernel/exceptions-64s.S +37 -0
@@ -2951,6 +2951,43 @@ TRAMP_REAL_BEGIN(stf_barrier_fallback) .endr blr +TRAMP_REAL_BEGIN(entry_flush_fallback) + std r9,PACA_EXRFI+EX_R9(r13) + std r10,PACA_EXRFI+EX_R10(r13) + std r11,PACA_EXRFI+EX_R11(r13) + mfctr r9 + ld r10,PACA_RFI_FLUSH_FALLBACK_AREA(r13) + ld r11,PACA_L1D_FLUSH_SIZE(r13) + srdi r11,r11,(7 + 3) /* 128 byte lines, unrolled 8x */ + mtctr r11 + DCBT_BOOK3S_STOP_ALL_STREAM_IDS(r11) /* Stop prefetch streams */ + + /* order ld/st prior to dcbt stop all streams with flushing */ + sync + + /* + * The load addresses are at staggered offsets within cachelines, + * which suits some pipelines better (on others it should not + * hurt). + */ +1: + ld r11,(0x80 + 8)*0(r10) + ld r11,(0x80 + 8)*1(r10) + ld r11,(0x80 + 8)*2(r10) + ld r11,(0x80 + 8)*3(r10) + ld r11,(0x80 + 8)*4(r10) + ld r11,(0x80 + 8)*5(r10) + ld r11,(0x80 + 8)*6(r10) + ld r11,(0x80 + 8)*7(r10) + addi r10,r10,0x80*8 + bdnz 1b + + mtctr r9 + ld r9,PACA_EXRFI+EX_R9(r13) + ld r10,PACA_EXRFI+EX_R10(r13) + ld r11,PACA_EXRFI+EX_R11(r13) + blr + TRAMP_REAL_BEGIN(rfi_flush_fallback) SET_SCRATCH0(r13); GET_PACA(r13);
arch/powerpc/kernel/setup_64.c +59 -1
97 lines not on this page · raw message
arch/powerpc/kernel/vmlinux.lds.S +7 -0
@@ -132,6 +132,13 @@ SECTIONS } . = ALIGN(8); + __entry_flush_fixup : AT(ADDR(__entry_flush_fixup) - LOAD_OFFSET) { + __start___entry_flush_fixup = .; + *(__entry_flush_fixup) + __stop___entry_flush_fixup = .; + } + + . = ALIGN(8); __stf_exit_barrier_fixup : AT(ADDR(__stf_exit_barrier_fixup) - LOAD_OFFSET) { __start___stf_exit_barrier_fixup = .; *(__stf_exit_barrier_fixup)
arch/powerpc/lib/feature-fixups.c +54 -0
60 lines not on this page · raw message
arch/powerpc/platforms/powernv/setup.c +11 -0
@@ -122,12 +122,23 @@ static void pnv_setup_rfi_flush(void) type =L1D_FLUSH_ORI ; } +/* +* If we are non-Power9 bare metal, we don't need to flush on kernel +* entry: it fixes a P9 specific vulnerability. +*/ +if (!pvr_version_is (PVR_POWER9 )) +security_ftr_clear (SEC_FTR_L1D_FLUSH_ENTRY ); + enable =security_ftr_enabled (SEC_FTR_FAVOUR_SECURITY ) && \ (security_ftr_enabled (SEC_FTR_L1D_FLUSH_PR ) || \security_ftr_enabled (SEC_FTR_L1D_FLUSH_HV ));setup_rfi_flush (type, enable);setup_count_cache_flush (); + + enable =security_ftr_enabled (SEC_FTR_FAVOUR_SECURITY ) && +security_ftr_enabled (SEC_FTR_L1D_FLUSH_ENTRY ); +setup_entry_flush (enable); }static void __init pnv_setup_arch (void )
arch/powerpc/platforms/pseries/setup.c +4 -0
@@ -573,6 +573,10 @@ void pseries_setup_rfi_flush(void)setup_rfi_flush (types, enable);setup_count_cache_flush (); + + enable =security_ftr_enabled (SEC_FTR_FAVOUR_SECURITY ) && +security_ftr_enabled (SEC_FTR_L1D_FLUSH_ENTRY ); +setup_entry_flush (enable); }#ifdef CONFIG_PCI_IOV
Greg Kroah-Hartman
maintainerPATCH 3/14 powerpc/64s: flush L1D after user accesses
In reply to Greg Kroah-HartmanFrom: Nicholas Piggin <[email protected]>
commit 9a32a7e78bd0cd9a9b6332cbdc345ee5ffd0c5de upstream.
IBM Power9 processors can speculatively operate on data in the L1 cache before it has been completely validated, via a way-prediction mechanism. It is not possible for an attacker to determine the contents of impermissible memory using this method, since these systems implement a combination of hardware and software security measures to prevent scenarios where protected data could be leaked.
However these measures don't address the scenario where an attacker induces the operating system to speculatively execute instructions using data that the attacker controls. This can be used for example to speculatively bypass "kernel user access prevention" techniques, as discovered by Anthony Steinhauser of Google's Safeside Project. This is not an attack by itself, but there is a possibility it could be used in conjunction with side-channels or other weaknesses in the privileged code to construct an attack.
This issue can be mitigated by flushing the L1 cache between privilege boundaries of concern. This patch flushes the L1 cache after user accesses.
This is part of the fix for CVE-2020-4788.
--- Documentation/admin-guide/kernel-parameters.txt | 4 + arch/powerpc/include/asm/book3s/64/kup-radix.h | 66 +++++++++++------- arch/powerpc/include/asm/exception-64s.h | 3 arch/powerpc/include/asm/feature-fixups.h | 9 ++ arch/powerpc/include/asm/kup.h | 19 +++-- arch/powerpc/include/asm/security_features.h | 3 arch/powerpc/include/asm/setup.h | 1 arch/powerpc/kernel/exceptions-64s.S | 85 +++++++----------------- arch/powerpc/kernel/setup_64.c | 62 +++++++++++++++++ arch/powerpc/kernel/vmlinux.lds.S | 7 + arch/powerpc/lib/feature-fixups.c | 50 ++++++++++++++ arch/powerpc/platforms/powernv/setup.c | 10 ++ arch/powerpc/platforms/pseries/setup.c | 4 + 13 files changed, 233 insertions(+), 90 deletions(-)
Documentation/admin-guide/kernel-parameters.txt +4 -0
@@ -2834,6 +2834,7 @@ tsx_async_abort=off [X86] kvm.nx_huge_pages=off [X86] no_entry_flush [PPC] + no_uaccess_flush [PPC] Exceptions: This does not have any effect on
@@ -3209,6 +3210,9 @@ nospec_store_bypass_disable [HW] Disable all mitigations for the Speculative Store Bypass vulnerability + no_uaccess_flush + [PPC] Don't flush the L1-D cache after accessing user data. + noxsave [BUGS=X86] Disables x86 extended register state save and restore using xsave. The kernel will fallback to enabling legacy floating-point and sse state.
arch/powerpc/include/asm/book3s/64/kup-radix.h +42 -24
104 lines not on this page · raw message
arch/powerpc/include/asm/exception-64s.h +3 -0
@@ -144,6 +144,9 @@RFSCV ; \ b rfscv_flush_fallback +#else /* __ASSEMBLY__ */ +/* Prototype for function defined in exceptions-64s.S */ +void do_uaccess_flush (void );#endif /* __ASSEMBLY__ */ #endif /* _ASM_POWERPC_EXCEPTION_H */
arch/powerpc/include/asm/feature-fixups.h +9 -0
@@ -205,6 +205,14 @@ label##3: \ FTR_ENTRY_OFFSET 955b-956b; \ .popsection; +#define UACCESS_FLUSH_FIXUP_SECTION \ +959: \ + .pushsection __uaccess_flush_fixup,"a"; \ + .align 2; \ +960: \ + FTR_ENTRY_OFFSET 959b-960b; \ + .popsection; +#define ENTRY_FLUSH_FIXUP_SECTION \ 957: \ .pushsection __entry_flush_fixup,"a"; \
@@ -248,6 +256,7 @@ extern long stf_barrier_fallback;extern long entry_flush_fallback;extern long __start___stf_entry_barrier_fixup, __stop___stf_entry_barrier_fixup;extern long __start___stf_exit_barrier_fixup, __stop___stf_exit_barrier_fixup; +extern long __start___uaccess_flush_fixup, __stop___uaccess_flush_fixup;extern long __start___entry_flush_fixup, __stop___entry_flush_fixup;extern long __start___rfi_flush_fixup, __stop___rfi_flush_fixup;extern long __start___barrier_nospec_fixup, __stop___barrier_nospec_fixup;
arch/powerpc/include/asm/kup.h +14 -5
@@ -53,17 +53,26 @@ static inline void setup_kuep(bool disabvoid setup_kuap (bool disabled);#else static inline void setup_kuap (bool disabled) { } + +static inline bool +bad_kuap_fault (struct pt_regs *regs,unsigned long address,bool is_write) +{ +return false; +} + +/* +* book3s/64/kup-radix.h defines these functions for the !KUAP case to flush +* the L1D cache after user accesses. Only include the empty stubs for other +* platforms. +*/ +#ifndef CONFIG_PPC64 static inline void allow_user_access (void __user *to,const void __user *from,unsigned long size,unsigned long dir) { }static inline void prevent_user_access (void __user *to,const void __user *from,unsigned long size,unsigned long dir) { }static inline unsigned long prevent_user_access_return (void ) {return 0UL ; }static inline void restore_user_access (unsigned long flags) { } -static inline bool -bad_kuap_fault (struct pt_regs *regs,unsigned long address,bool is_write) -{ -return false; -} +#endif /* CONFIG_PPC64 */ #endif /* CONFIG_PPC_KUAP */ static inline void allow_read_from_user (const void __user *from,unsigned long size)
arch/powerpc/include/asm/security_features.h +3 -0
@@ -89,6 +89,8 @@ static inline bool security_ftr_enabled(// The L1-D cache should be flushed when entering the kernel #define SEC_FTR_L1D_FLUSH_ENTRY 0x0000000000004000ull +// The L1-D cache should be flushed after user accesses from the kernel +#define SEC_FTR_L1D_FLUSH_UACCESS 0x0000000000008000ull// Features enabled by default #define SEC_FTR_DEFAULT \
@@ -96,6 +98,7 @@ static inline bool security_ftr_enabled( SEC_FTR_L1D_FLUSH_PR | \ SEC_FTR_BNDS_CHK_SPEC_BAR | \ SEC_FTR_L1D_FLUSH_ENTRY | \ + SEC_FTR_L1D_FLUSH_UACCESS | \ SEC_FTR_FAVOUR_SECURITY)#endif /* _ASM_POWERPC_SECURITY_FEATURES_H */
arch/powerpc/include/asm/setup.h +1 -0
@@ -60,6 +60,7 @@ void setup_barrier_nospec(void);#else static inline void setup_barrier_nospec (void ) { };#endif +void do_uaccess_flush_fixups (enum l1d_flush_type types);void do_entry_flush_fixups (enum l1d_flush_type types);void do_barrier_nospec_fixups (bool enable);extern bool barrier_nospec_enabled;
arch/powerpc/kernel/exceptions-64s.S +26 -59
116 lines not on this page · raw message
arch/powerpc/kernel/setup_64.c +62 -0
98 lines not on this page · raw message
arch/powerpc/kernel/vmlinux.lds.S +7 -0
@@ -132,6 +132,13 @@ SECTIONS } . = ALIGN(8); + __uaccess_flush_fixup : AT(ADDR(__uaccess_flush_fixup) - LOAD_OFFSET) { + __start___uaccess_flush_fixup = .; + *(__uaccess_flush_fixup) + __stop___uaccess_flush_fixup = .; + } + + . = ALIGN(8); __entry_flush_fixup : AT(ADDR(__entry_flush_fixup) - LOAD_OFFSET) { __start___entry_flush_fixup = .; *(__entry_flush_fixup)
arch/powerpc/lib/feature-fixups.c +50 -0
56 lines not on this page · raw message
arch/powerpc/platforms/powernv/setup.c +8 -2
@@ -124,10 +124,12 @@ static void pnv_setup_rfi_flush(void)/* * If we are non-Power9 bare metal, we don't need to flush on kernel -* entry: it fixes a P9 specific vulnerability. +* entry or after user access: they fix a P9 specific vulnerability. */ -if (!pvr_version_is (PVR_POWER9 )) +if (!pvr_version_is (PVR_POWER9 )) {security_ftr_clear (SEC_FTR_L1D_FLUSH_ENTRY ); +security_ftr_clear (SEC_FTR_L1D_FLUSH_UACCESS ); + } enable = security_ftr_enabled(SEC_FTR_FAVOUR_SECURITY) && \ (security_ftr_enabled(SEC_FTR_L1D_FLUSH_PR) || \
@@ -139,6 +141,10 @@ static void pnv_setup_rfi_flush(void) enable =security_ftr_enabled (SEC_FTR_FAVOUR_SECURITY ) &&security_ftr_enabled (SEC_FTR_L1D_FLUSH_ENTRY );setup_entry_flush (enable); + + enable =security_ftr_enabled (SEC_FTR_FAVOUR_SECURITY ) && +security_ftr_enabled (SEC_FTR_L1D_FLUSH_UACCESS ); +setup_uaccess_flush (enable); }static void __init pnv_setup_arch (void )
arch/powerpc/platforms/pseries/setup.c +4 -0
@@ -577,6 +577,10 @@ void pseries_setup_rfi_flush(void) enable =security_ftr_enabled (SEC_FTR_FAVOUR_SECURITY ) &&security_ftr_enabled (SEC_FTR_L1D_FLUSH_ENTRY );setup_entry_flush (enable); + + enable =security_ftr_enabled (SEC_FTR_FAVOUR_SECURITY ) && +security_ftr_enabled (SEC_FTR_L1D_FLUSH_UACCESS ); +setup_uaccess_flush (enable); }#ifdef CONFIG_PCI_IOV
Greg Kroah-Hartman
maintainerPATCH 4/14 powerpc: Only include kup-radix.h for 64-bit Book3S
In reply to Greg Kroah-HartmanFrom: Michael Ellerman <[email protected]>
commit 178d52c6e89c38d0553b0ac8b99927b11eb995b0 upstream.
In kup.h we currently include kup-radix.h for all 64-bit builds, which includes Book3S and Book3E. The latter doesn't make sense, Book3E never uses the Radix MMU.
This has worked up until now, but almost by accident, and the recent uaccess flush changes introduced a build breakage on Book3E because of the bad structure of the code.
So disentangle things so that we only use kup-radix.h for Book3S. This requires some more stubs in kup.h and fixing an include in syscall_64.c.
--- arch/powerpc/include/asm/book3s/64/kup-radix.h | 4 ++-- arch/powerpc/include/asm/kup.h | 11 ++++++++--- arch/powerpc/kernel/syscall_64.c | 2 +- 3 files changed, 11 insertions(+), 6 deletions(-)
arch/powerpc/include/asm/book3s/64/kup-radix.h +2 -2
@@ -27,6 +27,7 @@#endif .endm +#ifdef CONFIG_PPC_KUAP .macro kuap_check_amr gpr1, gpr2#ifdef CONFIG_PPC_KUAP_DEBUG BEGIN_MMU_FTR_SECTION_NESTED (67 )
@@ -38,6 +39,7 @@END_MMU_FTR_SECTION_NESTED_IFSET (MMU_FTR_RADIX_KUAP ,67 ) #endif .endm +#endif .macro kuap_save_amr_and_lock gpr1, gpr2, use_cr, msr_pr_cr #ifdef CONFIG_PPC_KUAP
@@ -148,8 +150,6 @@ static inline unsigned long kuap_get_andreturn 0UL ; } -static inline void kuap_check_amr (void ) { } -static inline unsigned long get_kuap (void ) {return AMR_KUAP_BLOCKED ;
arch/powerpc/include/asm/kup.h +8 -3
@@ -14,7 +14,7 @@#define KUAP_CURRENT_WRITE 8#define KUAP_CURRENT (KUAP_CURRENT_READ | KUAP_CURRENT_WRITE) -#ifdef CONFIG_PPC64 +#ifdef CONFIG_PPC_BOOK3S_64 #include <asm/book3s/64/kup-radix.h> #endif #ifdef CONFIG_PPC_8xx
@@ -35,6 +35,9 @@ .macro kuap_check current, gpr .endm +.macro kuap_check_amr gpr1, gpr2 +.endm +#endif #else /* !__ASSEMBLY__ */
@@ -60,19 +63,21 @@ bad_kuap_fault(struct pt_regs *regs, uns return false; } +static inline void kuap_check_amr (void ) { } +/* * book3s/64/kup-radix.h defines these functions for the !KUAP case to flush * the L1D cache after user accesses. Only include the empty stubs for other * platforms. */ -#ifndef CONFIG_PPC64 +#ifndef CONFIG_PPC_BOOK3S_64 static inline void allow_user_access (void __user *to,const void __user *from,unsigned long size,unsigned long dir) { }static inline void prevent_user_access (void __user *to,const void __user *from,unsigned long size,unsigned long dir) { }static inline unsigned long prevent_user_access_return (void ) {return 0UL ; }static inline void restore_user_access (unsigned long flags) { } -#endif /* CONFIG_PPC64 */ +#endif /* CONFIG_PPC_BOOK3S_64 */ #endif /* CONFIG_PPC_KUAP */ static inline void allow_read_from_user (const void __user *from,unsigned long size)
arch/powerpc/kernel/syscall_64.c +1 -1
@@ -2,7 +2,7 @@#include <linux/err.h> #include <asm/asm-prototypes.h> -#include <asm/book3s/64/kup-radix.h> +#include <asm/kup.h> #include <asm/cputime.h> #include <asm/hw_irq.h> #include <asm/kprobes.h>
Greg Kroah-Hartman
maintainerPATCH 5/14 selftests/powerpc: entry flush test
In reply to Greg Kroah-HartmanFrom: Daniel Axtens <[email protected]>
commit 89a83a0c69c81a25ce91002b90ca27ed86132a0a upstream.
Add a test modelled on the RFI flush test which counts the number of L1D misses doing a simple syscall with the entry flush on and off.
For simplicity of backporting, this test duplicates a lot of code from rfi_flush. We clean that up in the next patch.
--- tools/testing/selftests/powerpc/security/.gitignore | 1 tools/testing/selftests/powerpc/security/Makefile | 2 tools/testing/selftests/powerpc/security/entry_flush.c | 198 +++++++++++++++++ 3 files changed, 200 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/powerpc/security/entry_flush.c
tools/testing/selftests/powerpc/security/.gitignore +1 -0
@@ -1,2 +1,3 @@ # SPDX-License-Identifier: GPL-2.0-only rfi_flush +entry_flush
tools/testing/selftests/powerpc/security/Makefile +1 -1
@@ -1,6 +1,6 @@ # SPDX-License-Identifier: GPL-2.0+ -TEST_GEN_PROGS := rfi_flush spectre_v2 +TEST_GEN_PROGS := rfi_flush entry_flush spectre_v2 top_srcdir = ../../../../.. CFLAGS += -I../../../../../usr/include
tools/testing/selftests/powerpc/security/entry_flush.c new file +198 -0
198 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 6/14 leds: lm3697: Fix out-of-bound access
In reply to Greg Kroah-HartmanFrom: Gabriel David <[email protected]>
commit 98d278ca00bd8f62c8bc98bd9e65372d16eb6956 upstream
If both LED banks aren't used in device tree, an out-of-bounds condition in lm3697_init occurs because of the for loop assuming that all the banks are used. Fix it by adding a variable that contains the number of used banks.
--- drivers/leds/leds-lm3697.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/leds/leds-lm3697.c +5 -3
@@ -78,6 +78,7 @@ struct lm3697 {struct mutex lock;int bank_cfg; +int num_banks;struct lm3697_led leds[]; };
@@ -180,7 +181,7 @@ static int lm3697_init(struct lm3697 *prif (ret)dev_err (&priv->client->dev,"Cannot write OUTPUT config\n" ); -for (i =0 ; i <LM3697_MAX_CONTROL_BANKS ; i++) { +for (i =0 ; i < priv->num_banks; i++) { led = &priv->leds[i]; ret =ti_lmu_common_set_ramp (&led->lmu_data);if (ret)
@@ -307,8 +308,8 @@ static int lm3697_probe(struct i2c_clienint ret; count =device_get_child_node_count (&client->dev); -if (!count) { -dev_err (&client->dev,"LEDs are not defined in device tree!" ); +if (!count || count >LM3697_MAX_CONTROL_BANKS ) { +dev_err (&client->dev,"Strange device tree!" );return -ENODEV ; }
@@ -322,6 +323,7 @@ static int lm3697_probe(struct i2c_clien led->client = client; led->dev = &client->dev; + led->num_banks = count; led->regmap =devm_regmap_init_i2c (client, &lm3697_regmap_config);if (IS_ERR (led->regmap)) { ret =PTR_ERR (led->regmap);
Greg Kroah-Hartman
maintainerPATCH 7/14 Input: sunkbd - avoid use-after-free in teardown paths
In reply to Greg Kroah-HartmanFrom: Dmitry Torokhov <[email protected]>
commit 77e70d351db7de07a46ac49b87a6c3c7a60fca7e upstream.
We need to make sure we cancel the reinit work before we tear down the driver structures.
--- drivers/input/keyboard/sunkbd.c | 41 ++++++++++++++++++++++++++++++++-------- 1 file changed, 33 insertions(+), 8 deletions(-)
drivers/input/keyboard/sunkbd.c +33 -8
@@ -99,7 +99,8 @@ static irqreturn_t sunkbd_interrupt(struswitch (data) {case SUNKBD_RET_RESET : -schedule_work (&sunkbd->tq); +if (sunkbd->enabled) +schedule_work (&sunkbd->tq); sunkbd->reset =-1 ;break ;
@@ -200,16 +201,12 @@ static int sunkbd_initialize(struct sunk }/* -* sunkbd_reinit() sets leds and beeps to a state the computer remembers they -* were in. +* sunkbd_set_leds_beeps() sets leds and beeps to a state the computer remembers +* they were in. */ -static void sunkbd_reinit (struct work_struct *work) +static void sunkbd_set_leds_beeps (struct sunkbd *sunkbd) { - struct sunkbd *sunkbd = container_of(work, struct sunkbd, tq); - -wait_event_interruptible_timeout (sunkbd->wait, sunkbd->reset >=0 ,HZ ); -serio_write (sunkbd->serio,SUNKBD_CMD_SETLED ); serio_write(sunkbd->serio, (!!test_bit(LED_CAPSL, sunkbd->dev->led) << 3) |
@@ -222,11 +219,39 @@ static void sunkbd_reinit(struct work_st SUNKBD_CMD_BELLOFF - !!test_bit(SND_BELL, sunkbd->dev->snd)); } + +/* +* sunkbd_reinit() wait for the keyboard reset to complete and restores state +* of leds and beeps. +*/ + +static void sunkbd_reinit (struct work_struct *work) +{ + struct sunkbd *sunkbd = container_of(work, struct sunkbd, tq); + +/* +* It is OK that we check sunkbd->enabled without pausing serio, +* as we only want to catch true->false transition that will +* happen once and we will be woken up for it. +*/ +wait_event_interruptible_timeout (sunkbd->wait, + sunkbd->reset >=0 || !sunkbd->enabled, +HZ ); + +if (sunkbd->reset >=0 && sunkbd->enabled) +sunkbd_set_leds_beeps (sunkbd); +} +static void sunkbd_enable (struct sunkbd *sunkbd,bool enable) {serio_pause_rx (sunkbd->serio); sunkbd->enabled = enable;serio_continue_rx (sunkbd->serio); + +if (!enable) { +wake_up_interruptible (&sunkbd->wait); +cancel_work_sync (&sunkbd->tq); + } }/*
Greg Kroah-Hartman
maintainerPATCH 8/14 mac80211: always wind down STA state
In reply to Greg Kroah-HartmanFrom: Johannes Berg <[email protected]>
commit dcd479e10a0510522a5d88b29b8f79ea3467d501 upstream.
When (for example) an IBSS station is pre-moved to AUTHORIZED before it's inserted, and then the insertion fails, we don't clean up the fast RX/TX states that might already have been created, since we don't go through all the state transitions again on the way down.
Do that, if it hasn't been done already, when the station is freed. I considered only freeing the fast TX/RX state there, but we might add more state so it's more robust to wind down the state properly.
Note that we warn if the station was ever inserted, it should have been properly cleaned up in that case, and the driver will probably not like things happening out of order.
--- net/mac80211/sta_info.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
net/mac80211/sta_info.c +18 -0
@@ -258,6 +258,24 @@ struct sta_info *sta_info_get_by_idx(str*/ void sta_info_free (struct ieee80211_local *local,struct sta_info *sta) { +/* +* If we had used sta_info_pre_move_state() then we might not +* have gone through the state transitions down again, so do +* it here now (and warn if it's inserted). +* +* This will clear state such as fast TX/RX that may have been +* allocated during state transitions. +*/ +while (sta->sta_state >IEEE80211_STA_NONE ) { +int ret; + +WARN_ON_ONCE (test_sta_flag (sta,WLAN_STA_INSERTED )); + + ret =sta_info_move_state (sta, sta->sta_state -1 ); +if (WARN_ONCE (ret,"sta_info_move_state() returned %d\n" , ret)) +break ; + } +if (sta->rate_ctrl)rate_control_free_sta (sta);
Greg Kroah-Hartman
maintainerPATCH 9/14 can: proc: can_remove_proc(): silence remove_proc_entry warning
In reply to Greg Kroah-HartmanFrom: Zhang Changzhong <[email protected]>
commit 3accbfdc36130282f5ae9e6eecfdf820169fedce upstream.
If can_init_proc() fail to create /proc/net/can directory, can_remove_proc() will trigger a warning:
WARNING: CPU: 6 PID: 7133 at fs/proc/generic.c:672 remove_proc_entry+0x17b0 Kernel panic - not syncing: panic_on_warn set ...
Fix to return early from can_remove_proc() if can proc_dir does not exists.
--- net/can/proc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
net/can/proc.c +4 -2
@@ -471,6 +471,9 @@ void can_init_proc(struct net *net)*/ void can_remove_proc (struct net *net) { +if (!net->can.proc_dir) +return ; +if (net->can.pde_version)remove_proc_entry (CAN_PROC_VERSION , net->can.proc_dir);
@@ -498,6 +501,5 @@ void can_remove_proc(struct net *net)if (net->can.pde_rcvlist_sff)remove_proc_entry (CAN_PROC_RCVLIST_SFF , net->can.proc_dir); -if (net->can.proc_dir) -remove_proc_entry ("can" , net->proc_net); +remove_proc_entry ("can" , net->proc_net); }
Greg Kroah-Hartman
maintainerPATCH 10/14 selftests/harness: prettify SKIP message whitespace again
In reply to Greg Kroah-HartmanFrom: Tommi Rantala <[email protected]>
commit ef7086347c82c53a6c5238bd2cf31379f6acadde upstream.
Commit 9847d24af95c ("selftests/harness: Refactor XFAIL into SKIP") replaced XFAIL with SKIP in the output. Add one more space to make the output aligned and pretty again.
--- tools/testing/selftests/kselftest_harness.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/testing/selftests/kselftest_harness.h +1 -1
@@ -126,7 +126,7 @@snprintf (_metadata->results->reason, \ sizeof(_metadata->results->reason), fmt, ##__VA_ARGS__); \if (TH_LOG_ENABLED ) { \ -fprintf (TH_LOG_STREAM ,"# SKIP %s\n" , \ +fprintf (TH_LOG_STREAM ,"# SKIP %s\n" , \ _metadata->results->reason); \ } \ _metadata->passed =1 ; \
Greg Kroah-Hartman
maintainerPATCH 11/14 powerpc/smp: Call rcu_cpu_starting() earlier
In reply to Greg Kroah-HartmanFrom: Qian Cai <[email protected]>
commit 99f070b62322a4b8c1252952735806d09eb44b68 upstream.
The call to rcu_cpu_starting() in start_secondary() is not early enough in the CPU-hotplug onlining process, which results in lockdep splats as follows (with CONFIG_PROVE_RCU_LIST=y):
WARNING: suspicious RCU usage
-----------------------------
kernel/locking/lockdep.c:3497 RCU-list traversed in non-reader section!!
other info that might help us debug this:
RCU used illegally from offline CPU!
rcu_scheduler_active = 1, debug_locks = 1
no locks held by swapper/1/0.
Call Trace: dump_stack+0xec/0x144 (unreliable) lockdep_rcu_suspicious+0x128/0x14c __lock_acquire+0x1060/0x1c60 lock_acquire+0x140/0x5f0 _raw_spin_lock_irqsave+0x64/0xb0 clockevents_register_device+0x74/0x270 register_decrementer_clockevent+0x94/0x110 start_secondary+0x134/0x800 start_secondary_prolog+0x10/0x14
This is avoided by adding a call to rcu_cpu_starting() near the beginning of the start_secondary() function. Note that the raw_smp_processor_id() is required in order to avoid calling into lockdep before RCU has declared the CPU to be watched for readers.
It's safe to call rcu_cpu_starting() in the arch code as well as later in generic code, as explained by Paul:
It uses a per-CPU variable so that RCU pays attention only to the first call to rcu_cpu_starting() if there is more than one of them. This is even intentional, due to there being a generic arch-independent call to rcu_cpu_starting() in notify_cpu_starting().
So multiple calls to rcu_cpu_starting() are fine by design.
--- arch/powerpc/kernel/smp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/kernel/smp.c +1 -1
@@ -1251,7 +1251,7 @@ static bool shared_caches;/* Activate a secondary processor. */ void start_secondary (void *unused) { -unsigned int cpu =smp_processor_id (); +unsigned int cpu =raw_smp_processor_id ();struct cpumask *(*sibling_mask)(int ) = cpu_sibling_mask;mmgrab (&init_mm);
Greg Kroah-Hartman
maintainerPATCH 12/14 perf/x86/intel/uncore: Fix Add BW copypasta
In reply to Greg Kroah-HartmanFrom: Arnd Bergmann <[email protected]>
commit 1a8cfa24e21c2f154791f0cdd85fc28496918722 upstream.
gcc -Wextra points out a duplicate initialization of one array member:
arch/x86/events/intel/uncore_snb.c:478:37: warning: initialized field overwritten [-Woverride-init]
478 | [SNB_PCI_UNCORE_IMC_DATA_READS] = { SNB_UNCORE_PCI_IMC_DATA_WRITES_BASE,
The only sensible explanation is that a duplicate 'READS' was used instead of the correct 'WRITES', so change it back.
--- arch/x86/events/intel/uncore_snb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/events/intel/uncore_snb.c +1 -1
@@ -459,7 +459,7 @@ enum perf_snb_uncore_imc_freerunning_typstatic struct freerunning_counters snb_uncore_imc_freerunning[] = { [SNB_PCI_UNCORE_IMC_DATA_READS ] = {SNB_UNCORE_PCI_IMC_DATA_READS_BASE ,0x0 ,0x0 ,1 ,32 }, - [SNB_PCI_UNCORE_IMC_DATA_READS ] = {SNB_UNCORE_PCI_IMC_DATA_WRITES_BASE , + [SNB_PCI_UNCORE_IMC_DATA_WRITES ] = {SNB_UNCORE_PCI_IMC_DATA_WRITES_BASE ,0x0 ,0x0 ,1 ,32 }, [SNB_PCI_UNCORE_IMC_GT_REQUESTS ] = {SNB_UNCORE_PCI_IMC_GT_REQUESTS_BASE ,0x0 ,0x0 ,1 ,32 },
Greg Kroah-Hartman
maintainerPATCH 13/14 KVM: x86: clflushopt should be treated as a no-op by emulation
In reply to Greg Kroah-HartmanFrom: David Edmondson <[email protected]>
commit 51b958e5aeb1e18c00332e0b37c5d4e95a3eff84 upstream.
The instruction emulator ignores clflush instructions, yet fails to support clflushopt. Treat both similarly.
Message-Id: <[email protected]>
--- arch/x86/kvm/emulate.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
arch/x86/kvm/emulate.c +7 -1
@@ -4032,6 +4032,12 @@ static int em_clflush(struct x86_emulatereturn X86EMUL_CONTINUE ; } +static int em_clflushopt (struct x86_emulate_ctxt *ctxt) +{ +/* emulating clflushopt regardless of cpuid */ +return X86EMUL_CONTINUE ; +} +static int em_movsxd (struct x86_emulate_ctxt *ctxt) { ctxt->dst.val = (s32 ) ctxt->src.val;
@@ -4571,7 +4577,7 @@ static const struct opcode group11[] = { };static const struct gprefix pfx_0f_ae_7 = { -I (SrcMem | ByteOp, em_clflush),N ,N ,N , +I (SrcMem | ByteOp, em_clflush),I (SrcMem | ByteOp, em_clflushopt),N ,N , };static const struct group_dual group15 = { {
Greg Kroah-Hartman
maintainerPATCH 14/14 ACPI: GED: fix -Wformat
In reply to Greg Kroah-HartmanFrom: Nick Desaulniers <[email protected]>
commit 9debfb81e7654fe7388a49f45bc4d789b94c1103 upstream.
Clang is more aggressive about -Wformat warnings when the format flag specifies a type smaller than the parameter. It turns out that gsi is an int. Fixes:
drivers/acpi/evged.c:105:48: warning: format specifies type 'unsigned char' but the argument has type 'unsigned int' [-Wformat]
trigger == ACPI_EDGE_SENSITIVE ? 'E' : 'L', gsi);
^~~--- drivers/acpi/evged.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/acpi/evged.c +1 -1
@@ -101,7 +101,7 @@ static acpi_status acpi_ged_request_inteswitch (gsi) { case 0 ... 255: -sprintf (ev_name,"_%c%02hhX" , +sprintf (ev_name,"_%c%02X" , trigger ==ACPI_EDGE_SENSITIVE ?'E' :'L' , gsi);if (ACPI_SUCCESS (acpi_get_handle (handle, ev_name, &evt_handle)))
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.9.10 release. There are 14 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, 22 Nov 2020 10:45:32 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.9.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.9.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.9:
15 builds: 15 pass, 0 fail
26 boots: 26 pass, 0 fail
64 tests: 64 pass, 0 failLinux version: 5.9.10-rc1-g861b379f0883
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04Jon
Greg Kroah-Hartman
maintainerQuoted 26 lines · Jon Hunter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.9.10 release. There are 14 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, 22 Nov 2020 10:45:32 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.9.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.9.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.9:
15 builds: 15 pass, 0 fail 26 boots: 26 pass, 0 fail 64 tests: 64 pass, 0 fail
Quoted 7 lines
Linux version: 5.9.10-rc1-g861b379f0883
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,tegra194-p2972-0000, tegra20-ventana, tegra210-p2371-2180, tegra210-p3450-0000, tegra30-cardhu-a04Tested-by Jon Hunter <[email protected]>
Thanks for testing all of these and letting me know.
gre gk-
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.9.10 release. There are 14 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, 22 Nov 2020 10:45:32 +0000. Anything received after that time might be too late.
Quoted 8 lines
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.9.10-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-
stable-rc.git linux-5.9.y
and the diffstat can be found below.
hello,
Compiled and booted 5.9.10-rc1+. No issues with "dmesg -l err" But "dmesg -l warn" shows something.
file dmesg-warn-nov-20-2020-portion.txt is attached
--
software engineer
rajagiri school of engineering and technology - autonomous
[ 1135.758165] pcieport 0000:00:1c.5: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID) [ 1135.758174] pcieport 0000:00:1c.5: device [8086:9d15] error status/mask=00001000/00002000 [ 1135.758183] pcieport 0000:00:1c.5: [12] Timeout
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.9.10 release. There are 14 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, 22 Nov 2020 10:45:32 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.9.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.9.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 5.9.10 release. There are 14 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, 22 Nov 2020 10:45:32 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.9.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.9.y
and the diffstat can be found below.
Quoted 8 lines
Quoted 4 lines
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
Tested-by Shuah Khan <[email protected]>
Thanks for testing all of these and letting me know.
greg k-h
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.9.10 release. There are 14 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, 22 Nov 2020 10:45:32 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.9.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.9.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Summary
------------------------------------------------------------------------
kernel: 5.9.10-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.9.y
git commit: 861b379f08830cebd80999babf94973e831999c2
git describe: v5.9.9-15-g861b379f0883
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.9.y/build/v5.9.9-15-g861b379f0883
No regressions (compared to build v5.9.9)
No fixes (compared to build v5.9.9)
Ran 49372 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- nxp-ls2088
- qemu-arm-clang
- qemu-arm64-clang
- qemu-arm64-kasan
- qemu-i386-clang
- qemu-x86_64-clang
- qemu-x86_64-kasan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- x15
- x86
- x86-kasan
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* perf
* v4l2-compliance
* ltp-controllers-tests
* ltp-cve-tests
* network-basic-tests
* ltp-open-posix-tests
* kvm-unit-tests
* kunit
* kselftest
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Greg Kroah-Hartman
maintainerQuoted 17 lines · Naresh Kamboju
Quoted 15 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.9.10 release. There are 14 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, 22 Nov 2020 10:45:32 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.9.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.9.y
and the diffstat can be found below.
Quoted 8 lines
Quoted 3 lines
thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm,x86_64, and i386.
Thanks for testing them all and letting me know.
greg k-h
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.9.10 release. There are 14 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, 22 Nov 2020 10:45:32 +0000. Anything received after that time might be too late.
Build results:
total: 154 pass: 154 fail: 0 Qemu test results: total: 426 pass: 426 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 5.9.10 release. There are 14 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, 22 Nov 2020 10:45:32 +0000. Anything received after that time might be too late.
Quoted 6 lines
Build results:
total: 154 pass: 154 fail: 0 Qemu test results: total: 426 pass: 426 fail: 0Tested-by Guenter Roeck <[email protected]>
Thanks for the testing. I'll leave the powerpc build failures in as the issue being fixed is better to have at the moment. Hopefully the ppc developers can fix those up soon.
thanks,
greg k-h