- Linux-stable-mirror - lists.linaro.org

PASS: Test report for kernel 4.19.4-rc1.skt+ (linux-stable-rc)

by CKI

Hello, We ran automated tests on a recent commit from this kernel tree: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Commit: 2b8db8734888 Linux 4.19.4-rc1 The results of these automated tests are provided below. Overall result: PASSED Patch merge: OK Compile: OK Hardware test: OK Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( I ) Continuous `-',-.`-' Kernel ( K ) Integration `-' ______________________________________________________________________________ Compile testing --------------- We compiled the kernel for 4 architectures: arm64: make options: make INSTALL_MOD_STRIP=1 -j56 targz-pkg configuration: https://artifacts.cki-project.org/builds/aarch64/2b8db8734888b00156c6afb235… powerpc: make options: make INSTALL_MOD_STRIP=1 -j56 targz-pkg configuration: https://artifacts.cki-project.org/builds/ppc64le/2b8db8734888b00156c6afb235… powerpc: make options: make INSTALL_MOD_STRIP=1 -j56 targz-pkg configuration: https://artifacts.cki-project.org/builds/ppc64/2b8db8734888b00156c6afb235ed… x86_64: make options: make INSTALL_MOD_STRIP=1 -j56 targz-pkg configuration: https://artifacts.cki-project.org/builds/x86_64/2b8db8734888b00156c6afb235e…

6 years, 10 months

1
0
0 0

International credit settlement

by :COMPENSATION AGENTt

International credit settlement Office of the director of operations World Bank united state of America. Attention : This Is To Officially Inform You That We Have Verified Your Contact Inheritance File Presently On My Desk, And I Found Out That You Have Not Received Your Payment Due To Your Lack Of Co- Operation And Not Fulfilling The Obligations Giving To You In Respect To Your Contract /Inheritance Payment. Secondly, You Are Hereby Advice To Stop Dealing With Some Non- Officials In The Bank As This Is An Illegal Act And Will Have To Stop If You So Wish To Receive Your Payment Immediately. After The Board Meeting Held At Our Headquarters, We Have Resolved In Finding A Solution To Your Problem, And As You May Know, We Have Arranged Your Payment Through Our Swift Card Payment Center In Europe, America And Asia Pacific, Which Is Then Instruction Given By Our President. This Card Center Will Send You An ATM Card Which You Will Use To Withdraw Your Money In Any Part Of The World, But The Maximum Is ($15,000.00) Fifteen Thousand Us Dollars Per Transaction. So, If You Like To Receive Your Fund This Way, $15,000 Usd For You To Withdraw For A Day And Each Transaction Is $5,000usd Minimum Which You Have To Withdraw $15,000 Usd For One Working Day. Also Be Informed That The Total Amount In The Swift ATM Card Is $14.6 Million Usd. Contact:COMPENSATION AGENT Email:DavegibsonEsq@gmail.comcom (1) Your Full Name: (2) Your Address Where You Want the Payment Centre to Send Your ATM Card.: (3) Phone and Fax Number: (4) Age and Occupation: (5) Your Nearest International Air Port in Your City Of Residence: We Shall Be Expecting To Receive Your Information, You Have To Stop Any Further Communication With Anybody Or Office On This Regards, Do Not Hesitate To Contact Me For More Details And Direction, And Please Do Update Me With Any New Development. Thanks for Your Co-Operation.

6 years, 10 months

1
0
0 0

stable-rc/linux-3.18.y boot: 62 boots: 5 failed, 56 passed with 1 untried/unknown (v3.18.125-88-ge2a8617f7c3c)

by kernelci.org bot

stable-rc/linux-3.18.y boot: 62 boots: 5 failed, 56 passed with 1 untried/unknown (v3.18.125-88-ge2a8617f7c3c) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-3.18.y/kernel/v3.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-3.18.y/kernel/v3.18.125-8… Tree: stable-rc Branch: linux-3.18.y Git Describe: v3.18.125-88-ge2a8617f7c3c Git Commit: e2a8617f7c3c3a178aab5341fe2e6002dfa9efb9 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 25 unique boards, 12 SoC families, 14 builds out of 185 Boot Failures Detected: arm: exynos_defconfig exynos4412-odroidx2: 1 failed lab x86: x86_64_defconfig qemu: 3 failed labs x86-atom330: 1 failed lab --- For more info write to <info(a)kernelci.org>

6 years, 10 months

1
0
0 0

v3.16.61 build: 0 failures 1 warnings (v3.16.61)

by Build bot for Mark Brown

Tree/Branch: v3.16.61 Git describe: v3.16.61 Commit: b43515fece Linux 3.16.61 Build Time: 33 min 52 sec Passed: 10 / 10 (100.00 %) Failed: 0 / 10 ( 0.00 %) Errors: 0 Warnings: 1 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 2 warnings 0 mismatches : arm-multi_v7_defconfig 2 warnings 0 mismatches : arm-allmodconfig 1 warnings 0 mismatches : arm-allnoconfig 2 warnings 0 mismatches : arm-multi_v5_defconfig ------------------------------------------------------------------------------- Warnings Summary: 1 7 <stdin>:1238:2: warning: #warning syscall seccomp not implemented [-Wcpp] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- arm-multi_v7_defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches Warnings: <stdin>:1238:2: warning: #warning syscall seccomp not implemented [-Wcpp] <stdin>:1238:2: warning: #warning syscall seccomp not implemented [-Wcpp] ------------------------------------------------------------------------------- arm-allmodconfig : PASS, 0 errors, 2 warnings, 0 section mismatches Warnings: <stdin>:1238:2: warning: #warning syscall seccomp not implemented [-Wcpp] <stdin>:1238:2: warning: #warning syscall seccomp not implemented [-Wcpp] ------------------------------------------------------------------------------- arm-allnoconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: <stdin>:1238:2: warning: #warning syscall seccomp not implemented [-Wcpp] ------------------------------------------------------------------------------- arm-multi_v5_defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches Warnings: <stdin>:1238:2: warning: #warning syscall seccomp not implemented [-Wcpp] <stdin>:1238:2: warning: #warning syscall seccomp not implemented [-Wcpp] ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm64-allmodconfig x86_64-defconfig x86_64-allnoconfig x86_64-allmodconfig arm64-defconfig

6 years, 10 months

1
0
0 0

[Patch v6 00/16] Provide task property based options to enable Spectre v2 userspace-userspace protection

by Tim Chen

Fix in this version bugs causing build problems for UP configuration. Also merged in Jiri's change to extend STIBP for SECCOMP processes and renaming TIF_STIBP to TIF_SPEC_INDIR_BRANCH. I've updated the boot options spectre_v2_app2app to on, off, auto, prctl and seccomp. This aligns with the options for other speculation related mitigations. I tried to incorporate sched_smt_present to detect when we have all SMT going offline and we can disable the SMT path, which Peter suggested. This optimization that can be easily left out of the patch series and not backported. I've put these two patches at the end and they can be considered separately. I've dropped the TIF flags re-organization patches as they are not needed in this patch series. To do: Create a dedicated document on the mitigation options for Spectre V2. Since Jiri's patchset to always turn on STIBP has big performance impact, I think that it should be reverted from 4.20 and stable kernels for now, till this patchset to mitigate its performance impact can be merged with it into the mainline and backported to stable kernels. Thanks. Tim Patch 1 to 3 are clean up patches. Patch 4 and 5 disable STIBP for enhacned IBRS. Patch 6 to 9 reorganize and clean up the code without affecting functionality for easier modification later. Patch 10 introduces the STIBP flag on a task to dynamically enable STIBP for that task. Patch 11 introduces different modes to protect a task against Spectre v2 user space attack. Patch 12 adds prctl interface to turn on Spectre v2 user mode defenses on a task. Patch 13 Put IBPB usage under the mode chosen for app2app mitigation. Patch 14 Add STIBP protection for SECCOMP tasks. Patch 15-16 add Spectre v2 defenses for non-dumpable tasks. Patch 15-16 reorganizes the TIF flags, and can be dropped without affecting this series Patch 17-18 When there are no paired SMT left, disable SMT specific code Changes: v6: 1. Fix bugs for UP build configuration. 2. Add protection for SECCOMP tasks. 3. Rename TIF_STIBP to TIF_SPEC_INDIR_BRANCH. 4. Update boot options to align with other speculation mitigations. 5. Separate out IBPB change that makes it depend on TIF_SPEC_INDIR_BRANCH. 6. Move some checks for SPEC_CTRL updates to spec_ctrl_update_msr to avoid unnecesseary MSR writes. 7. Drop TIF reorg patches. 8. Incorporate optimization to disable SMT code paths when no paired SMT is present. v5: 1. Drop patch to extend TIF_STIBP changes to all related threads on a task's dumpabibility change. 2. Drop patch to replace sched_smt_present with cpu_smt_enabled. 3. Drop export of cpu_smt_control in kernel/cpu.c and replace external usages of cpu_smt_control with cpu_smt_enabled. 4. Rebase patch series on 4.20-rc2. v4: 1. Extend STIBP update to all threads of a process changing it dumpability. 2. Add logic to update SPEC_CTRL MSR on a remote CPU when TIF flags affecting speculation changes for task running on the remote CPU. 3. Regroup x86 TIF_* flags according to their functions. 4. Various code clean up. v3: 1. Add logic to skip STIBP when Enhanced IBRS is used. 2. Break up v2 patches into smaller logical patches. 3. Fix bug in arch_set_dumpable that did not update SPEC_CTRL MSR right away when according to task's STIBP flag clearing which caused SITBP to be left on. 4. Various code clean up. v2: 1. Extend per process STIBP to AMD cpus 2. Add prctl option to control per process indirect branch speculation 3. Bug fixes and cleanups Jiri's patchset to harden Spectre v2 user space mitigation makes IBPB and STIBP in use for Spectre v2 mitigation on all processes. IBPB will be issued for switching to an application that's not ptraceable by the previous application and STIBP will be always turned on. However, leaving STIBP on all the time is expensive for certain applications that have frequent indirect branches. One such application is perlbench in the SpecInt Rate 2006 test suite which shows a 21% reduction in throughput. There're also reports of drop in performance on Python and PHP benchmarks: https://www.phoronix.com/scan.php?page=article&item=linux-420-bisect&num=2 Other applications like bzip2 with minimal indirct branches have only a 0.7% reduction in throughput. IBPB will also impose overhead during context switches. Users may not wish to incur performance overhead from IBPB and STIBP for general non security sensitive processes and use these mitigations only for security sensitive processes. This patchset provides a process property based lite protection mode. In this mode, IBPB and STIBP mitigation are applied only to security sensitive non-dumpable processes and processes that users want to protect by having indirect branch speculation disabled via PRCTL. So the overhead from IBPB and STIBP are avoided for low security processes that don't require extra protection. Jiri Kosina (1): x86/speculation: Add 'seccomp' Spectre v2 app to app protection mode Peter Zijlstra (1): sched/smt: Make sched_smt_present track topology Tim Chen (14): x86/speculation: Reorganize cpu_show_common() x86/speculation: Add X86_FEATURE_USE_IBRS_ENHANCED x86/speculation: Disable STIBP when enhanced IBRS is in use x86/speculation: Rename SSBD update functions x86/speculation: Reorganize speculation control MSRs update smt: Create cpu_smt_enabled static key for SMT specific code x86/smt: Convert cpu_smt_control check to cpu_smt_enabled static key x86/speculation: Turn on or off STIBP according to a task's TIF_STIBP x86/speculation: Add Spectre v2 app to app protection modes x86/speculation: Create PRCTL interface to restrict indirect branch speculation x86/speculation: Enable IBPB for tasks with TIF_SPEC_BRANCH_SPECULATION security: Update speculation restriction of a process when modifying its dumpability x86/speculation: Use STIBP to restrict speculation on non-dumpable task x86/smt: Allow disabling of SMT when last SMT is offlined Documentation/admin-guide/kernel-parameters.txt | 34 +++ Documentation/userspace-api/spec_ctrl.rst | 9 + arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/msr-index.h | 6 +- arch/x86/include/asm/nospec-branch.h | 10 + arch/x86/include/asm/spec-ctrl.h | 18 +- arch/x86/include/asm/thread_info.h | 5 +- arch/x86/kernel/cpu/bugs.c | 304 ++++++++++++++++++++++-- arch/x86/kernel/process.c | 58 ++++- arch/x86/kvm/vmx.c | 2 +- arch/x86/mm/tlb.c | 23 +- fs/exec.c | 3 + include/linux/cpu.h | 31 ++- include/linux/sched.h | 9 + include/uapi/linux/prctl.h | 1 + kernel/cpu.c | 28 ++- kernel/cred.c | 5 +- kernel/sched/core.c | 19 +- kernel/sched/sched.h | 2 - kernel/sys.c | 7 + tools/include/uapi/linux/prctl.h | 1 + 21 files changed, 512 insertions(+), 64 deletions(-) -- 2.9.4

6 years, 10 months

4
25
0 0

[PATCH] arc: [devboards] Add support of NFSv3 ACL

by Alexey Brodkin

By default NFSv3 doesn't support ACL (Access Control Lists) which might be quite convenient to have so that mounted NFS behaves exactly as any other local file-system. In particular missing support of ACL makes umask useless. This among other thigs fixes Glibc's "nptl/tst-umask1". Signed-off-by: Alexey Brodkin <abrodkin(a)synopsys.com> Cc: Cupertino Miranda <cmiranda(a)synopsys.com> Cc: stable(a)vger.kernel.org --- arch/arc/configs/axs101_defconfig | 1 + arch/arc/configs/axs103_defconfig | 1 + arch/arc/configs/axs103_smp_defconfig | 1 + arch/arc/configs/hsdk_defconfig | 1 + arch/arc/configs/nps_defconfig | 1 + arch/arc/configs/nsimosci_defconfig | 1 + arch/arc/configs/nsimosci_hs_defconfig | 1 + arch/arc/configs/nsimosci_hs_smp_defconfig | 1 + arch/arc/configs/vdk_hs38_defconfig | 1 + arch/arc/configs/vdk_hs38_smp_defconfig | 1 + 10 files changed, 10 insertions(+) diff --git a/arch/arc/configs/axs101_defconfig b/arch/arc/configs/axs101_defconfig index 41bc08be6a3b..8c23bd086cd0 100644 --- a/arch/arc/configs/axs101_defconfig +++ b/arch/arc/configs/axs101_defconfig @@ -95,6 +95,7 @@ CONFIG_VFAT_FS=y CONFIG_NTFS_FS=y CONFIG_TMPFS=y CONFIG_NFS_FS=y +CONFIG_NFS_V3_ACL=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y # CONFIG_ENABLE_WARN_DEPRECATED is not set diff --git a/arch/arc/configs/axs103_defconfig b/arch/arc/configs/axs103_defconfig index 1e1c4a8011b5..666314fffc60 100644 --- a/arch/arc/configs/axs103_defconfig +++ b/arch/arc/configs/axs103_defconfig @@ -94,6 +94,7 @@ CONFIG_VFAT_FS=y CONFIG_NTFS_FS=y CONFIG_TMPFS=y CONFIG_NFS_FS=y +CONFIG_NFS_V3_ACL=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y # CONFIG_ENABLE_WARN_DEPRECATED is not set diff --git a/arch/arc/configs/axs103_smp_defconfig b/arch/arc/configs/axs103_smp_defconfig index 6b0c0cfd5c30..429832b8560b 100644 --- a/arch/arc/configs/axs103_smp_defconfig +++ b/arch/arc/configs/axs103_smp_defconfig @@ -97,6 +97,7 @@ CONFIG_VFAT_FS=y CONFIG_NTFS_FS=y CONFIG_TMPFS=y CONFIG_NFS_FS=y +CONFIG_NFS_V3_ACL=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y # CONFIG_ENABLE_WARN_DEPRECATED is not set diff --git a/arch/arc/configs/hsdk_defconfig b/arch/arc/configs/hsdk_defconfig index 1dec2b4bc5e6..2a1d2cbfee1a 100644 --- a/arch/arc/configs/hsdk_defconfig +++ b/arch/arc/configs/hsdk_defconfig @@ -65,6 +65,7 @@ CONFIG_EXT3_FS=y CONFIG_VFAT_FS=y CONFIG_TMPFS=y CONFIG_NFS_FS=y +CONFIG_NFS_V3_ACL=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y # CONFIG_ENABLE_WARN_DEPRECATED is not set diff --git a/arch/arc/configs/nps_defconfig b/arch/arc/configs/nps_defconfig index 31ba224bbfb4..ae7a0d8be98d 100644 --- a/arch/arc/configs/nps_defconfig +++ b/arch/arc/configs/nps_defconfig @@ -73,6 +73,7 @@ CONFIG_PROC_KCORE=y CONFIG_TMPFS=y # CONFIG_MISC_FILESYSTEMS is not set CONFIG_NFS_FS=y +CONFIG_NFS_V3_ACL=y CONFIG_ROOT_NFS=y CONFIG_DEBUG_INFO=y # CONFIG_ENABLE_WARN_DEPRECATED is not set diff --git a/arch/arc/configs/nsimosci_defconfig b/arch/arc/configs/nsimosci_defconfig index f14eeff7d308..ad77f20e5aa6 100644 --- a/arch/arc/configs/nsimosci_defconfig +++ b/arch/arc/configs/nsimosci_defconfig @@ -66,5 +66,6 @@ CONFIG_EXT2_FS_XATTR=y CONFIG_TMPFS=y # CONFIG_MISC_FILESYSTEMS is not set CONFIG_NFS_FS=y +CONFIG_NFS_V3_ACL=y # CONFIG_ENABLE_WARN_DEPRECATED is not set # CONFIG_ENABLE_MUST_CHECK is not set diff --git a/arch/arc/configs/nsimosci_hs_defconfig b/arch/arc/configs/nsimosci_hs_defconfig index 025298a48305..1638e5bc9672 100644 --- a/arch/arc/configs/nsimosci_hs_defconfig +++ b/arch/arc/configs/nsimosci_hs_defconfig @@ -65,5 +65,6 @@ CONFIG_EXT2_FS_XATTR=y CONFIG_TMPFS=y # CONFIG_MISC_FILESYSTEMS is not set CONFIG_NFS_FS=y +CONFIG_NFS_V3_ACL=y # CONFIG_ENABLE_WARN_DEPRECATED is not set # CONFIG_ENABLE_MUST_CHECK is not set diff --git a/arch/arc/configs/nsimosci_hs_smp_defconfig b/arch/arc/configs/nsimosci_hs_smp_defconfig index df7b77b13b82..11cfbdb0f441 100644 --- a/arch/arc/configs/nsimosci_hs_smp_defconfig +++ b/arch/arc/configs/nsimosci_hs_smp_defconfig @@ -76,6 +76,7 @@ CONFIG_EXT2_FS_XATTR=y CONFIG_TMPFS=y # CONFIG_MISC_FILESYSTEMS is not set CONFIG_NFS_FS=y +CONFIG_NFS_V3_ACL=y # CONFIG_ENABLE_WARN_DEPRECATED is not set # CONFIG_ENABLE_MUST_CHECK is not set CONFIG_FTRACE=y diff --git a/arch/arc/configs/vdk_hs38_defconfig b/arch/arc/configs/vdk_hs38_defconfig index db47c3541f15..1e59a2e9c602 100644 --- a/arch/arc/configs/vdk_hs38_defconfig +++ b/arch/arc/configs/vdk_hs38_defconfig @@ -85,6 +85,7 @@ CONFIG_NTFS_FS=y CONFIG_TMPFS=y CONFIG_JFFS2_FS=y CONFIG_NFS_FS=y +CONFIG_NFS_V3_ACL=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y # CONFIG_ENABLE_WARN_DEPRECATED is not set diff --git a/arch/arc/configs/vdk_hs38_smp_defconfig b/arch/arc/configs/vdk_hs38_smp_defconfig index a8ac5e917d9a..b5c3f6c54b03 100644 --- a/arch/arc/configs/vdk_hs38_smp_defconfig +++ b/arch/arc/configs/vdk_hs38_smp_defconfig @@ -90,6 +90,7 @@ CONFIG_NTFS_FS=y CONFIG_TMPFS=y CONFIG_JFFS2_FS=y CONFIG_NFS_FS=y +CONFIG_NFS_V3_ACL=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y # CONFIG_ENABLE_WARN_DEPRECATED is not set -- 2.19.1

6 years, 10 months

2
3
0 0

[PATCH 4.9 V2 00/24] V4.9 backport of 32-bit arm spectre patches

by David Long

From: "David A. Long" <dave.long(a)linaro.org> V4.9 backport of spectre patches from Russell M. King's spectre branch. Patches not yet in upstream are excluded. Changes in V2: 1) Fixed bad merge in #11/24 in hyp-entry.S. 2) Incorporated upstream patch to earlier patch where wrong ENDPROC call was done in hypervisor code in proc-v7.S. Marc Zyngier (2): ARM: KVM: invalidate BTB on guest exit for Cortex-A12/A17 ARM: KVM: invalidate icache on guest exit for Cortex-A15 Russell King (22): ARM: add more CPU part numbers for Cortex and Brahma B15 CPUs ARM: bugs: prepare processor bug infrastructure ARM: bugs: hook processor bug checking into SMP and suspend paths ARM: bugs: add support for per-processor bug checking ARM: spectre: add Kconfig symbol for CPUs vulnerable to Spectre ARM: spectre-v2: harden branch predictor on context switches ARM: spectre-v2: add Cortex A8 and A15 validation of the IBE bit ARM: spectre-v2: harden user aborts in kernel space ARM: spectre-v2: add firmware based hardening ARM: spectre-v2: warn about incorrect context switching functions ARM: spectre-v2: KVM: invalidate icache on guest exit for Brahma B15 ARM: KVM: Add SMCCC_ARCH_WORKAROUND_1 fast handling ARM: KVM: report support for SMCCC_ARCH_WORKAROUND_1 ARM: spectre-v1: add speculation barrier (csdb) macros ARM: spectre-v1: add array_index_mask_nospec() implementation ARM: spectre-v1: fix syscall entry ARM: signal: copy registers using __copy_from_user() ARM: vfp: use __copy_from_user() when restoring VFP state ARM: oabi-compat: copy semops using __copy_from_user() ARM: use __inttype() in get_user() ARM: spectre-v1: use get_user() for __get_user() ARM: spectre-v1: mitigate user accesses arch/arm/include/asm/assembler.h | 12 ++ arch/arm/include/asm/barrier.h | 32 ++++++ arch/arm/include/asm/bugs.h | 6 +- arch/arm/include/asm/cp15.h | 3 + arch/arm/include/asm/cputype.h | 8 ++ arch/arm/include/asm/kvm_asm.h | 2 - arch/arm/include/asm/kvm_host.h | 14 ++- arch/arm/include/asm/kvm_mmu.h | 23 +++- arch/arm/include/asm/proc-fns.h | 4 + arch/arm/include/asm/system_misc.h | 15 +++ arch/arm/include/asm/thread_info.h | 4 +- arch/arm/include/asm/uaccess.h | 26 +++-- arch/arm/kernel/Makefile | 1 + arch/arm/kernel/bugs.c | 18 +++ arch/arm/kernel/entry-common.S | 18 ++- arch/arm/kernel/entry-header.S | 25 +++++ arch/arm/kernel/signal.c | 55 ++++----- arch/arm/kernel/smp.c | 4 + arch/arm/kernel/suspend.c | 2 + arch/arm/kernel/sys_oabi-compat.c | 8 +- arch/arm/kvm/hyp/hyp-entry.S | 112 ++++++++++++++++++- arch/arm/lib/copy_from_user.S | 9 ++ arch/arm/mm/Kconfig | 23 ++++ arch/arm/mm/Makefile | 2 +- arch/arm/mm/fault.c | 3 + arch/arm/mm/proc-macros.S | 3 +- arch/arm/mm/proc-v7-2level.S | 6 - arch/arm/mm/proc-v7-bugs.c | 174 +++++++++++++++++++++++++++++ arch/arm/mm/proc-v7.S | 154 +++++++++++++++++++------ arch/arm/vfp/vfpmodule.c | 17 ++- 30 files changed, 674 insertions(+), 109 deletions(-) create mode 100644 arch/arm/kernel/bugs.c create mode 100644 arch/arm/mm/proc-v7-bugs.c -- 2.17.1

6 years, 10 months

6
39
0 0

Clang backports for 4.9 and 4.4

by Nick Desaulniers

Greg, I'm in the process of preparing backports for building 4.9 and 4.4 kernels with Clang. Going off of mka's very helpful: https://lkml.org/lkml/2017/11/22/943, I've prepared the list of SHA's that were marked UPSTREAM (internal convention used to denote patch applies cleanly): https://gist.github.com/nickdesaulniers/fe995f4b7c52af8de1a283c0a53562d9. But it seems that some of these shas no longer apply cleanly. I was thus curious: 1. May I send you a pull request with the patches properly backported? I'm happy to do the work, just want a green light before backporting all of these patches. 2. Should I denote in any way if I had to modify any patch to get it to apply cleanly? This helps in code review, IMO. If so, what convention should I use? -- Thanks, ~Nick Desaulniers

6 years, 10 months

3
12
0 0

[PATCH] powerpc/tm: Set MSR[TS] just prior to recheckpoint

by Breno Leitao

On a signal handler return, the user could set a context with MSR[TS] bits set, and these bits would be copied to task regs->msr. At restore_tm_sigcontexts(), after current task regs->msr[TS] bits are set, several __get_user() are called and then a recheckpoint is executed. This is a problem since a page fault (in kernel space) could happen when calling __get_user(). If it happens, the process MSR[TS] bits were already set, but recheckpoint was not executed, and SPRs are still invalid. The page fault can cause the current process to be de-scheduled, with MSR[TS] active and without tm_recheckpoint() being called. More importantly, without TEXAR[FS] bit set also. Since TEXASR might not have the FS bit set, and when the process is scheduled back, it will try to reclaim, which will be aborted because of the CPU is not in the suspended state, and, then, recheckpoint. This recheckpoint will restore thread->texasr into TEXASR SPR, which might be zero, hitting a BUG_ON(). [ 2181.457997] kernel BUG at arch/powerpc/kernel/tm.S:446! This patch simply delays the MSR[TS] set, so, if there is any page fault in the __get_user() section, it does not have regs->msr[TS] set, since the TM structures are still invalid, thus avoiding doing TM operations for in-kernel exceptions and possible process reschedule. With this patch, the MSR[TS] will only be set just before recheckpointing and setting TEXASR[FS] = 1, thus avoiding an interrupt with TM registers in invalid state. It is not possible to move tm_recheckpoint to happen earlier, because it is required to get the checkpointed registers from userspace, with __get_user(), thus, the only way to avoid this undesired behavior is delaying the MSR[TS] set, as done in this patch. Fixes: 87b4e5393af7 ("powerpc/tm: Fix return of active 64bit signals") Cc: stable(a)vger.kernel.org (v3.9+) Signed-off-by: Breno Leitao <leitao(a)debian.org> --- arch/powerpc/kernel/signal_64.c | 29 +++++++++++++++-------------- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c index 83d51bf586c7..15b153bdd826 100644 --- a/arch/powerpc/kernel/signal_64.c +++ b/arch/powerpc/kernel/signal_64.c @@ -467,20 +467,6 @@ static long restore_tm_sigcontexts(struct task_struct *tsk, if (MSR_TM_RESV(msr)) return -EINVAL; - /* pull in MSR TS bits from user context */ - regs->msr = (regs->msr & ~MSR_TS_MASK) | (msr & MSR_TS_MASK); - - /* - * Ensure that TM is enabled in regs->msr before we leave the signal - * handler. It could be the case that (a) user disabled the TM bit - * through the manipulation of the MSR bits in uc_mcontext or (b) the - * TM bit was disabled because a sufficient number of context switches - * happened whilst in the signal handler and load_tm overflowed, - * disabling the TM bit. In either case we can end up with an illegal - * TM state leading to a TM Bad Thing when we return to userspace. - */ - regs->msr |= MSR_TM; - /* pull in MSR LE from user context */ regs->msr = (regs->msr & ~MSR_LE) | (msr & MSR_LE); @@ -572,6 +558,21 @@ static long restore_tm_sigcontexts(struct task_struct *tsk, tm_enable(); /* Make sure the transaction is marked as failed */ tsk->thread.tm_texasr |= TEXASR_FS; + + /* pull in MSR TS bits from user context */ + regs->msr = (regs->msr & ~MSR_TS_MASK) | (msr & MSR_TS_MASK); + + /* + * Ensure that TM is enabled in regs->msr before we leave the signal + * handler. It could be the case that (a) user disabled the TM bit + * through the manipulation of the MSR bits in uc_mcontext or (b) the + * TM bit was disabled because a sufficient number of context switches + * happened whilst in the signal handler and load_tm overflowed, + * disabling the TM bit. In either case we can end up with an illegal + * TM state leading to a TM Bad Thing when we return to userspace. + */ + regs->msr |= MSR_TM; + /* This loads the checkpointed FP/VEC state, if used */ tm_recheckpoint(&tsk->thread); -- 2.19.0

6 years, 10 months

2
2
0 0

request for 4.14-stable: fcab5651fae4 ("ARM: dts: r8a7790: Correct critical CPU temperature")

by Sudip Mukherjee

Hi Greg, This was not marked for stable but seems it should be in stable. Please apply to your queue of 4.14-stable. -- Regards Sudip

6 years, 10 months

4
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror