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

v3.6.11 build: 5 failures 3 warnings (v3.6.11)

by Build bot for Mark Brown

Tree/Branch: v3.6.11 Git describe: v3.6.11 Commit: b2824f4e09 Linux 3.6.11 Build Time: 0 min 5 sec Passed: 0 / 5 ( 0.00 %) Failed: 5 / 5 (100.00 %) Errors: 3 Warnings: 3 Section Mismatches: 0 Failed defconfigs: x86_64-allnoconfig arm-allmodconfig arm-allnoconfig x86_64-allmodconfig x86_64-defconfig Errors: x86_64-allnoconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode arm-allnoconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory x86_64-allmodconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode x86_64-defconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 3 warnings 0 mismatches : x86_64-allnoconfig 2 warnings 0 mismatches : arm-allmodconfig ------------------------------------------------------------------------------- Errors summary: 3 3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode 3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode 1 /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings Summary: 3 2 /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] 2 .config:20:warning: symbol value '' invalid for PHYS_OFFSET 1 /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- x86_64-allnoconfig : FAIL, 2 errors, 3 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Warnings: /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function] /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- arm-allmodconfig : FAIL, 0 errors, 2 warnings, 0 section mismatches Warnings: .config:20:warning: symbol value '' invalid for PHYS_OFFSET .config:20:warning: symbol value '' invalid for PHYS_OFFSET ------------------------------------------------------------------------------- arm-allnoconfig : FAIL, 1 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory ------------------------------------------------------------------------------- x86_64-allmodconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- x86_64-defconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches:

7 years, 6 months

1
0
0 0

v3.5.7 build: 5 failures 3 warnings (v3.5.7)

by Build bot for Mark Brown

Tree/Branch: v3.5.7 Git describe: v3.5.7 Commit: f2b152564a Linux 3.5.7 Build Time: 0 min 3 sec Passed: 0 / 5 ( 0.00 %) Failed: 5 / 5 (100.00 %) Errors: 3 Warnings: 3 Section Mismatches: 0 Failed defconfigs: x86_64-allnoconfig arm-allmodconfig arm-allnoconfig x86_64-allmodconfig x86_64-defconfig Errors: x86_64-allnoconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode arm-allnoconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory x86_64-allmodconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode x86_64-defconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 3 warnings 0 mismatches : x86_64-allnoconfig 2 warnings 0 mismatches : arm-allmodconfig ------------------------------------------------------------------------------- Errors summary: 3 3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode 3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode 1 /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings Summary: 3 2 /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] 2 .config:20:warning: symbol value '' invalid for PHYS_OFFSET 1 /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- x86_64-allnoconfig : FAIL, 2 errors, 3 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Warnings: /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function] /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- arm-allmodconfig : FAIL, 0 errors, 2 warnings, 0 section mismatches Warnings: .config:20:warning: symbol value '' invalid for PHYS_OFFSET .config:20:warning: symbol value '' invalid for PHYS_OFFSET ------------------------------------------------------------------------------- arm-allnoconfig : FAIL, 1 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory ------------------------------------------------------------------------------- x86_64-allmodconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- x86_64-defconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches:

7 years, 6 months

1
0
0 0

v3.4.113 build: 5 failures 20 warnings (v3.4.113)

by Build bot for Mark Brown

Tree/Branch: v3.4.113 Git describe: v3.4.113 Commit: 8d1988f838 Linux 3.4.113 Build Time: 0 min 4 sec Passed: 0 / 5 ( 0.00 %) Failed: 5 / 5 (100.00 %) Errors: 6 Warnings: 20 Section Mismatches: 0 Failed defconfigs: x86_64-allnoconfig arm-allmodconfig arm-allnoconfig x86_64-allmodconfig x86_64-defconfig Errors: x86_64-allnoconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode arm-allnoconfig /home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function) /home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model /home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type /home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type x86_64-allmodconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode x86_64-defconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 2 warnings 0 mismatches : arm-allmodconfig 19 warnings 0 mismatches : arm-allnoconfig ------------------------------------------------------------------------------- Errors summary: 6 3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode 3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode 1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type 1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type 1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model 1 /home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function) Warnings Summary: 20 2 .config:26:warning: symbol value '' invalid for PHYS_OFFSET 1 /home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:46:29: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:26:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:81:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:103:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/irqflags.h:11:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/fpstate.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cmpxchg.h:40:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cmpxchg.h:33:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cmpxchg.h:108:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:33:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:28:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:196:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:194:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/bitops.h:217:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:9:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:20:35: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:16:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:10:3: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/atomic.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- x86_64-allnoconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- arm-allmodconfig : FAIL, 0 errors, 2 warnings, 0 section mismatches Warnings: .config:26:warning: symbol value '' invalid for PHYS_OFFSET .config:26:warning: symbol value '' invalid for PHYS_OFFSET ------------------------------------------------------------------------------- arm-allnoconfig : FAIL, 4 errors, 19 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function) /home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model /home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type /home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type Warnings: /home/broonie/build/linux-stable/arch/arm/include/asm/irqflags.h:11:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/bitops.h:217:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:26:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:46:29: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/fpstate.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:9:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:10:3: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:16:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:20:35: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:81:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:103:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cmpxchg.h:33:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cmpxchg.h:40:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cmpxchg.h:108:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/atomic.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:28:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:33:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:194:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:196:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] ------------------------------------------------------------------------------- x86_64-allmodconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- x86_64-defconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches:

7 years, 6 months

1
0
0 0

v3.3.8 build: 5 failures 2 warnings (v3.3.8)

by Build bot for Mark Brown

Tree/Branch: v3.3.8 Git describe: v3.3.8 Commit: 845720650c Linux 3.3.8 Build Time: 0 min 3 sec Passed: 0 / 5 ( 0.00 %) Failed: 5 / 5 (100.00 %) Errors: 3 Warnings: 2 Section Mismatches: 0 Failed defconfigs: x86_64-allnoconfig arm-allmodconfig arm-allnoconfig x86_64-allmodconfig x86_64-defconfig Errors: x86_64-allnoconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode arm-allnoconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:99:30: fatal error: linux/compiler-gcc5.h: No such file or directory x86_64-allmodconfig /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode x86_64-defconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 5 warnings 0 mismatches : arm-allmodconfig ------------------------------------------------------------------------------- Errors summary: 3 3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode 3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode 1 /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:99:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings Summary: 2 3 warning: (IMA) selects TCG_TIS which has unmet direct dependencies (TCG_TPM && X86) 2 .config:26:warning: symbol value '' invalid for PHYS_OFFSET =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- x86_64-allnoconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- arm-allmodconfig : FAIL, 0 errors, 5 warnings, 0 section mismatches Warnings: warning: (IMA) selects TCG_TIS which has unmet direct dependencies (TCG_TPM && X86) .config:26:warning: symbol value '' invalid for PHYS_OFFSET warning: (IMA) selects TCG_TIS which has unmet direct dependencies (TCG_TPM && X86) .config:26:warning: symbol value '' invalid for PHYS_OFFSET warning: (IMA) selects TCG_TIS which has unmet direct dependencies (TCG_TPM && X86) ------------------------------------------------------------------------------- arm-allnoconfig : FAIL, 1 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:99:30: fatal error: linux/compiler-gcc5.h: No such file or directory ------------------------------------------------------------------------------- x86_64-allmodconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- x86_64-defconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches:

7 years, 6 months

1
0
0 0

v3.2.100 build: 5 failures 20 warnings (v3.2.100)

by Build bot for Mark Brown

Tree/Branch: v3.2.100 Git describe: v3.2.100 Commit: 1c7cb8cda9 Linux 3.2.100 Build Time: 0 min 4 sec Passed: 0 / 5 ( 0.00 %) Failed: 5 / 5 (100.00 %) Errors: 6 Warnings: 20 Section Mismatches: 0 Failed defconfigs: x86_64-allnoconfig arm-allmodconfig arm-allnoconfig x86_64-allmodconfig x86_64-defconfig Errors: x86_64-allnoconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode arm-allnoconfig /home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function) /home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model /home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type /home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type x86_64-allmodconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode x86_64-defconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 2 warnings 0 mismatches : arm-allmodconfig 19 warnings 0 mismatches : arm-allnoconfig ------------------------------------------------------------------------------- Errors summary: 6 3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode 3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode 1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type 1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type 1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model 1 /home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function) Warnings Summary: 20 2 .config:27:warning: symbol value '' invalid for PHYS_OFFSET 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:342:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:272:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:265:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:131:35: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:127:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:121:3: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:120:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:114:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:25:28: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:82:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:102:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/irqflags.h:11:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/fpstate.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:33:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:28:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:196:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:194:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/bitops.h:217:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/atomic.h:30:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- x86_64-allnoconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- arm-allmodconfig : FAIL, 0 errors, 2 warnings, 0 section mismatches Warnings: .config:27:warning: symbol value '' invalid for PHYS_OFFSET .config:27:warning: symbol value '' invalid for PHYS_OFFSET ------------------------------------------------------------------------------- arm-allnoconfig : FAIL, 4 errors, 19 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function) /home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model /home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type /home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type Warnings: /home/broonie/build/linux-stable/arch/arm/include/asm/irqflags.h:11:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:114:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:120:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:121:3: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:127:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:131:35: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:265:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:272:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:342:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/bitops.h:217:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:25:28: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/fpstate.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:82:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:102:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/atomic.h:30:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:28:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:33:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:194:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:196:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] ------------------------------------------------------------------------------- x86_64-allmodconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- x86_64-defconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches:

7 years, 6 months

1
0
0 0

Applied "spi: Fix unregistration of controller with fixed SPI bus number" to the regulator tree

by Mark Brown

The patch spi: Fix unregistration of controller with fixed SPI bus number has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 9fca7d15487654dab119d0868501db30f80ac46a Mon Sep 17 00:00:00 2001 From: Jarkko Nikula <jarkko.nikula(a)linux.intel.com> Date: Tue, 6 Mar 2018 17:47:22 +0200 Subject: [PATCH] spi: Fix unregistration of controller with fixed SPI bus number Commit 9b61e302210e (spi: Pick spi bus number from Linux idr or spi alias) ceased to unregister SPI buses with fixed bus numbers. Moreover this is visible only if CONFIG_SPI_DEBUG=y is set or when trying to re-register the same SPI controller. rmmod spi_pxa2xx_platform (with CONFIG_SPI_DEBUG=y): [ 26.788362] spi_master spi1: attempting to delete unregistered controller [spi1] modprobe spi_pxa2xx_platform: [ 37.883137] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:19.0/pxa2xx-spi.12/spi_master/spi1' [ 37.894984] CPU: 1 PID: 1467 Comm: modprobe Not tainted 4.16.0-rc4+ #21 [ 37.902384] Call Trace: ... [ 38.122680] kobject_add_internal failed for spi1 with -EEXIST, don't try to register things with the same name in the same directory. [ 38.136154] WARNING: CPU: 1 PID: 1467 at lib/kobject.c:238 kobject_add_internal+0x2a5/0x2f0 ... [ 38.513817] pxa2xx-spi pxa2xx-spi.12: problem registering spi master [ 38.521036] pxa2xx-spi: probe of pxa2xx-spi.12 failed with error -17 Fix this by not returning immediately from spi_unregister_controller() if idr_find() doesn't find controller with given ID/bus number. It finds only those controllers that were registered with dynamic SPI bus numbers. Only conditional cleanup between dynamic and fixed bus numbers is to remove allocated IDR. Fixes: 9b61e302210e (spi: Pick spi bus number from Linux idr or spi alias) Signed-off-by: Jarkko Nikula <jarkko.nikula(a)linux.intel.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Cc: stable(a)vger.kernel.org --- drivers/spi/spi.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index b33a727a0158..e90fd442b3f0 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -2254,12 +2254,6 @@ void spi_unregister_controller(struct spi_controller *ctlr) mutex_lock(&board_lock); found = idr_find(&spi_master_idr, id); mutex_unlock(&board_lock); - if (found != ctlr) { - dev_dbg(&ctlr->dev, - "attempting to delete unregistered controller [%s]\n", - dev_name(&ctlr->dev)); - return; - } if (ctlr->queued) { if (spi_destroy_queue(ctlr)) dev_err(&ctlr->dev, "queue remove failed\n"); @@ -2272,7 +2266,8 @@ void spi_unregister_controller(struct spi_controller *ctlr) device_unregister(&ctlr->dev); /* free bus id */ mutex_lock(&board_lock); - idr_remove(&spi_master_idr, id); + if (found == ctlr) + idr_remove(&spi_master_idr, id); mutex_unlock(&board_lock); } EXPORT_SYMBOL_GPL(spi_unregister_controller); -- 2.16.2

7 years, 6 months

2
1
0 0

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

by Build bot for Mark Brown

Tree/Branch: v3.18.100 Git describe: v3.18.100 Commit: 5fcd937491 Linux 3.18.100 Build Time: 45 min 12 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): 7 warnings 0 mismatches : x86_64-allmodconfig 2 warnings 0 mismatches : x86_64-defconfig ------------------------------------------------------------------------------- Warnings Summary: 1 9 ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- x86_64-allmodconfig : PASS, 0 errors, 7 warnings, 0 section mismatches Warnings: ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ------------------------------------------------------------------------------- x86_64-defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches Warnings: ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm64-allmodconfig arm-multi_v5_defconfig arm-multi_v7_defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm64-defconfig

7 years, 6 months

1
0
0 0

[PATCH] mtd: rawnand: fsl_ifc: Fix nand waitfunc return value

by Jagdish Gediya

As per the IFC hardware manual, Most significant 2 bytes in nand_fsr register are the outcome of NAND READ STATUS command. So status value need to be shifted and aligned as per the nand framework requirement. Cc: stable(a)vger.kernel.org Signed-off-by: Jagdish Gediya <jagdish.gediya(a)nxp.com> Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha(a)nxp.com> --- drivers/mtd/nand/fsl_ifc_nand.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c index d9ce398..951dd89 100644 --- a/drivers/mtd/nand/fsl_ifc_nand.c +++ b/drivers/mtd/nand/fsl_ifc_nand.c @@ -643,12 +643,13 @@ static int fsl_ifc_wait(struct mtd_info *mtd, struct nand_chip *chip) fsl_ifc_run_command(mtd); nand_fsr = ifc_in32(&ifc->ifc_nand.nand_fsr); - + nand_fsr >>= 16; + nand_fsr = (nand_fsr >> 8) | (nand_fsr << 8); /* * The chip always seems to report that it is * write-protected, even when it is not. */ - return nand_fsr | NAND_STATUS_WP; + return (nand_fsr & 0xff) | NAND_STATUS_WP; } /* -- 1.9.1

7 years, 6 months

2
1
0 0

[PATCH][v2] mtd: rawnand: fsl_ifc: Fix eccstat array overflow for IFC ver >= 2.0.0

by Jagdish Gediya

Number of ECC status registers i.e. (ECCSTATx) has been increased in IFC version 2.0.0 due to increase in SRAM size. This is causing eccstat array to over flow. So, replace eccstat array with u32 variable to make it fail-safe and independent of number of ECC status registers or SRAM size. Cc: stable(a)vger.kernel.org Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha(a)nxp.com> Signed-off-by: Jagdish Gediya <jagdish.gediya(a)nxp.com> --- Changes for v2: Incorporated comments from Miquel Raynal and Boris Brezillon - Updated patch subject - Remove usage of eccstat array - Added Cc: stable(a)vger.kernel.org drivers/mtd/nand/fsl_ifc_nand.c | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c index 4872a7b..d9ce398 100644 --- a/drivers/mtd/nand/fsl_ifc_nand.c +++ b/drivers/mtd/nand/fsl_ifc_nand.c @@ -173,14 +173,9 @@ static void set_addr(struct mtd_info *mtd, int column, int page_addr, int oob) /* returns nonzero if entire page is blank */ static int check_read_ecc(struct mtd_info *mtd, struct fsl_ifc_ctrl *ctrl, - u32 *eccstat, unsigned int bufnum) + u32 eccstat, unsigned int bufnum) { - u32 reg = eccstat[bufnum / 4]; - int errors; - - errors = (reg >> ((3 - bufnum % 4) * 8)) & 15; - - return errors; + return (eccstat >> ((3 - bufnum % 4) * 8)) & 15; } /* @@ -193,7 +188,7 @@ static void fsl_ifc_run_command(struct mtd_info *mtd) struct fsl_ifc_ctrl *ctrl = priv->ctrl; struct fsl_ifc_nand_ctrl *nctrl = ifc_nand_ctrl; struct fsl_ifc_runtime __iomem *ifc = ctrl->rregs; - u32 eccstat[4]; + u32 eccstat; int i; /* set the chip select for NAND Transaction */ @@ -237,10 +232,18 @@ static void fsl_ifc_run_command(struct mtd_info *mtd) else eccstat_regs = ifc->ifc_nand.v1_nand_eccstat; - for (i = sector / 4; i <= sector_end / 4; i++) - eccstat[i] = ifc_in32(&eccstat_regs[i]); + eccstat = 0; for (i = sector; i <= sector_end; i++) { + + /* + * if page size and sector size both are 512B then + * sector may not be multiple of 4 but sector and + * sector_end will be same. + */ + if ((i % 4 == 0) || (sector == sector_end)) + eccstat = ifc_in32(&eccstat_regs[i / 4]); + errors = check_read_ecc(mtd, ctrl, eccstat, i); if (errors == 15) { -- 1.9.1

7 years, 6 months

2
1
0 0

[PATCH] PCI / PM: Always check PME wakeup capability for runtime wakeup support

by Kai-Heng Feng

USB controller ASM1042 stops working after commit de3ef1eb1cd0 ("PM / core: Drop run_wake flag from struct dev_pm_info"). The device in question is not power managed by platform firmware, furthermore, it only supports PME# from D3cold: Capabilities: [78] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2-,D3hot-,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Before the commit, the device never gets runtime suspended. After the commit, the device gets runtime suspended, so it does not respond to any PME#. usb_hcd_pci_probe() mandatorily calls device_wakeup_enable(), hence device_can_wakeup() in pci_dev_run_wake() always returns true. So pci_dev_run_wake() needs to check PME wakeup capability as its first condition. Fixes: de3ef1eb1cd0 ("PM / core: Drop run_wake flag from struct dev_pm_info") Cc: stable(a)vger.kernel.org # 4.13+ Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> --- drivers/pci/pci.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index f6a4dd10d9b0..e026d8f313ec 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -2125,16 +2125,13 @@ bool pci_dev_run_wake(struct pci_dev *dev) { struct pci_bus *bus = dev->bus; - if (device_can_wakeup(&dev->dev)) - return true; - - if (!dev->pme_support) - return false; - /* PME-capable in principle, but not from the target power state */ - if (!pci_pme_capable(dev, pci_target_state(dev, false))) + if (!pci_pme_capable(dev, pci_target_state(dev, true))) return false; + if (device_can_wakeup(&dev->dev)) + return true; + while (bus->parent) { struct pci_dev *bridge = bus->self; -- 2.15.1

7 years, 6 months

3
2
0 0

[PATCH] can: cc770: Fix use after free in cc770_tx_interrupt()

by Marc Kleine-Budde

From: Andri Yngvason <andri.yngvason(a)marel.com> This fixes use after free introduced by the last cc770 patch. Signed-off-by: Andri Yngvason <andri.yngvason(a)marel.com> Fixes: 746201235b3f ("can: cc770: Fix queue stall & dropped RTR reply") Cc: linux-stable <stable(a)vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> --- drivers/net/can/cc770/cc770.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/net/can/cc770/cc770.c b/drivers/net/can/cc770/cc770.c index 2743d82d4424..6da69af103e6 100644 --- a/drivers/net/can/cc770/cc770.c +++ b/drivers/net/can/cc770/cc770.c @@ -706,13 +706,12 @@ static void cc770_tx_interrupt(struct net_device *dev, unsigned int o) return; } - can_put_echo_skb(priv->tx_skb, dev, 0); - can_get_echo_skb(dev, 0); - cf = (struct can_frame *)priv->tx_skb->data; stats->tx_bytes += cf->can_dlc; stats->tx_packets++; + can_put_echo_skb(priv->tx_skb, dev, 0); + can_get_echo_skb(dev, 0); priv->tx_skb = NULL; netif_wake_queue(dev); -- 2.16.2

7 years, 6 months

1
0
0 0

Patch "x86/vm86/32: Fix POPF emulation" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/vm86/32: Fix POPF emulation to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-vm86-32-fix-popf-emulation.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b5069782453459f6ec1fdeb495d9901a4545fcb5 Mon Sep 17 00:00:00 2001 From: Andy Lutomirski <luto(a)kernel.org> Date: Tue, 13 Mar 2018 22:03:12 -0700 Subject: x86/vm86/32: Fix POPF emulation From: Andy Lutomirski <luto(a)kernel.org> commit b5069782453459f6ec1fdeb495d9901a4545fcb5 upstream. POPF would trap if VIP was set regardless of whether IF was set. Fix it. Suggested-by: Stas Sergeev <stsp(a)list.ru> Reported-by: Bart Oldeman <bartoldeman(a)gmail.com> Signed-off-by: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Fixes: 5ed92a8ab71f ("x86/vm86: Use the normal pt_regs area for vm86") Link: http://lkml.kernel.org/r/ce95f40556e7b2178b6bc06ee9557827ff94bd28.152100360… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/vm86_32.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/arch/x86/kernel/vm86_32.c +++ b/arch/x86/kernel/vm86_32.c @@ -719,7 +719,8 @@ void handle_vm86_fault(struct kernel_vm8 return; check_vip: - if (VEFLAGS & X86_EFLAGS_VIP) { + if ((VEFLAGS & (X86_EFLAGS_VIP | X86_EFLAGS_VIF)) == + (X86_EFLAGS_VIP | X86_EFLAGS_VIF)) { save_v86_state(regs, VM86_STI); return; } Patches currently in stable-queue which might be from luto(a)kernel.org are queue-4.9/selftests-x86-add-tests-for-the-str-and-sldt-instructions.patch queue-4.9/x86-speculation-objtool-annotate-indirect-calls-jumps-for-objtool-on-32-bit-kernels.patch queue-4.9/x86-vm86-32-fix-popf-emulation.patch queue-4.9/selftests-x86-add-tests-for-user-mode-instruction-prevention.patch queue-4.9/perf-tools-make-perf_event__synthesize_mmap_events-scale.patch queue-4.9/x86-mm-fix-vmalloc_fault-to-use-pxd_large.patch queue-4.9/x86-mm-make-mmap-map_32bit-work-correctly.patch queue-4.9/selftests-x86-entry_from_vm86-add-test-cases-for-popf.patch queue-4.9/x86-boot-32-defer-resyncing-initial_page_table-until-per-cpu-is-set-up.patch queue-4.9/x86-boot-32-fix-up-boot-on-quark-and-possibly-other-platforms.patch queue-4.9/selftests-x86-entry_from_vm86-exit-with-1-if-we-fail.patch

7 years, 6 months

1
0
0 0

Patch "x86/speculation, objtool: Annotate indirect calls/jumps for objtool on 32-bit kernels" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/speculation, objtool: Annotate indirect calls/jumps for objtool on 32-bit kernels to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-speculation-objtool-annotate-indirect-calls-jumps-for-objtool-on-32-bit-kernels.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a14bff131108faf50cc0cf864589fd71ee216c96 Mon Sep 17 00:00:00 2001 From: Andy Whitcroft <apw(a)canonical.com> Date: Wed, 14 Mar 2018 11:24:27 +0000 Subject: x86/speculation, objtool: Annotate indirect calls/jumps for objtool on 32-bit kernels From: Andy Whitcroft <apw(a)canonical.com> commit a14bff131108faf50cc0cf864589fd71ee216c96 upstream. In the following commit: 9e0e3c5130e9 ("x86/speculation, objtool: Annotate indirect calls/jumps for objtool") ... we added annotations for CALL_NOSPEC/JMP_NOSPEC on 64-bit x86 kernels, but we did not annotate the 32-bit path. Annotate it similarly. Signed-off-by: Andy Whitcroft <apw(a)canonical.com> Acked-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Arjan van de Ven <arjan(a)linux.intel.com> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: David Woodhouse <dwmw2(a)infradead.org> Cc: David Woodhouse <dwmw(a)amazon.co.uk> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Link: http://lkml.kernel.org/r/20180314112427.22351-1-apw@canonical.com Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/include/asm/nospec-branch.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -183,7 +183,10 @@ * otherwise we'll run out of registers. We don't care about CET * here, anyway. */ -# define CALL_NOSPEC ALTERNATIVE("call *%[thunk_target]\n", \ +# define CALL_NOSPEC \ + ALTERNATIVE( \ + ANNOTATE_RETPOLINE_SAFE \ + "call *%[thunk_target]\n", \ " jmp 904f;\n" \ " .align 16\n" \ "901: call 903f;\n" \ Patches currently in stable-queue which might be from apw(a)canonical.com are queue-4.9/x86-speculation-objtool-annotate-indirect-calls-jumps-for-objtool-on-32-bit-kernels.patch

7 years, 6 months

1
0
0 0

Patch "x86/speculation: Remove Skylake C2 from Speculation Control microcode blacklist" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/speculation: Remove Skylake C2 from Speculation Control microcode blacklist to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-speculation-remove-skylake-c2-from-speculation-control-microcode-blacklist.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From e3b3121fa8da94cb20f9e0c64ab7981ae47fd085 Mon Sep 17 00:00:00 2001 From: Alexander Sergeyev <sergeev917(a)gmail.com> Date: Tue, 13 Mar 2018 22:38:56 +0300 Subject: x86/speculation: Remove Skylake C2 from Speculation Control microcode blacklist From: Alexander Sergeyev <sergeev917(a)gmail.com> commit e3b3121fa8da94cb20f9e0c64ab7981ae47fd085 upstream. In accordance with Intel's microcode revision guidance from March 6 MCU rev 0xc2 is cleared on both Skylake H/S and Skylake Xeon E3 processors that share CPUID 506E3. Signed-off-by: Alexander Sergeyev <sergeev917(a)gmail.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Jia Zhang <qianyue.zj(a)alibaba-inc.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Kyle Huey <me(a)kylehuey.com> Cc: David Woodhouse <dwmw(a)amazon.co.uk> Link: https://lkml.kernel.org/r/20180313193856.GA8580@localhost.localdomain Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/cpu/intel.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/arch/x86/kernel/cpu/intel.c +++ b/arch/x86/kernel/cpu/intel.c @@ -64,7 +64,7 @@ void check_mpx_erratum(struct cpuinfo_x8 /* * Early microcode releases for the Spectre v2 mitigation were broken. * Information taken from; - * - https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/microcode-up… + * - https://newsroom.intel.com/wp-content/uploads/sites/11/2018/03/microcode-up… * - https://kb.vmware.com/s/article/52345 * - Microcode revisions observed in the wild * - Release note from 20180108 microcode release @@ -82,7 +82,6 @@ static const struct sku_microcode spectr { INTEL_FAM6_KABYLAKE_MOBILE, 0x09, 0x80 }, { INTEL_FAM6_SKYLAKE_X, 0x03, 0x0100013e }, { INTEL_FAM6_SKYLAKE_X, 0x04, 0x0200003c }, - { INTEL_FAM6_SKYLAKE_DESKTOP, 0x03, 0xc2 }, { INTEL_FAM6_BROADWELL_CORE, 0x04, 0x28 }, { INTEL_FAM6_BROADWELL_GT3E, 0x01, 0x1b }, { INTEL_FAM6_BROADWELL_XEON_D, 0x02, 0x14 }, Patches currently in stable-queue which might be from sergeev917(a)gmail.com are queue-4.9/x86-speculation-remove-skylake-c2-from-speculation-control-microcode-blacklist.patch

7 years, 6 months

1
0
0 0

Patch "x86/cpufeatures: Add Intel PCONFIG cpufeature" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/cpufeatures: Add Intel PCONFIG cpufeature to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-cpufeatures-add-intel-pconfig-cpufeature.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 7958b2246fadf54b7ff820a2a5a2c5ca1554716f Mon Sep 17 00:00:00 2001 From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Date: Mon, 5 Mar 2018 19:25:51 +0300 Subject: x86/cpufeatures: Add Intel PCONFIG cpufeature From: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> commit 7958b2246fadf54b7ff820a2a5a2c5ca1554716f upstream. CPUID.0x7.0x0:EDX[18] indicates whether Intel CPU support PCONFIG instruction. Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Dave Hansen <dave.hansen(a)intel.com> Cc: Kai Huang <kai.huang(a)linux.intel.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Tom Lendacky <thomas.lendacky(a)amd.com> Cc: linux-mm(a)kvack.org Link: http://lkml.kernel.org/r/20180305162610.37510-4-kirill.shutemov@linux.intel… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/include/asm/cpufeatures.h | 1 + 1 file changed, 1 insertion(+) --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -302,6 +302,7 @@ /* Intel-defined CPU features, CPUID level 0x00000007:0 (EDX), word 18 */ #define X86_FEATURE_AVX512_4VNNIW (18*32+ 2) /* AVX-512 Neural Network Instructions */ #define X86_FEATURE_AVX512_4FMAPS (18*32+ 3) /* AVX-512 Multiply Accumulation Single precision */ +#define X86_FEATURE_PCONFIG (18*32+18) /* Intel PCONFIG */ #define X86_FEATURE_SPEC_CTRL (18*32+26) /* "" Speculation Control (IBRS + IBPB) */ #define X86_FEATURE_INTEL_STIBP (18*32+27) /* "" Single Thread Indirect Branch Predictors */ #define X86_FEATURE_ARCH_CAPABILITIES (18*32+29) /* IA32_ARCH_CAPABILITIES MSR (Intel) */ Patches currently in stable-queue which might be from kirill.shutemov(a)linux.intel.com are queue-4.9/x86-cpufeatures-add-intel-pconfig-cpufeature.patch queue-4.9/mm-fix-false-positive-vm_bug_on-in-page_cache_-get-add-_speculative.patch queue-4.9/x86-mm-make-mmap-map_32bit-work-correctly.patch

7 years, 6 months

1
0
0 0

Patch "x86/mm: Fix vmalloc_fault to use pXd_large" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/mm: Fix vmalloc_fault to use pXd_large to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-mm-fix-vmalloc_fault-to-use-pxd_large.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 18a955219bf7d9008ce480d4451b6b8bf4483a22 Mon Sep 17 00:00:00 2001 From: Toshi Kani <toshi.kani(a)hpe.com> Date: Tue, 13 Mar 2018 11:03:46 -0600 Subject: x86/mm: Fix vmalloc_fault to use pXd_large From: Toshi Kani <toshi.kani(a)hpe.com> commit 18a955219bf7d9008ce480d4451b6b8bf4483a22 upstream. Gratian Crisan reported that vmalloc_fault() crashes when CONFIG_HUGETLBFS is not set since the function inadvertently uses pXn_huge(), which always return 0 in this case. ioremap() does not depend on CONFIG_HUGETLBFS. Fix vmalloc_fault() to call pXd_large() instead. Fixes: f4eafd8bcd52 ("x86/mm: Fix vmalloc_fault() to handle large pages properly") Reported-by: Gratian Crisan <gratian.crisan(a)ni.com> Signed-off-by: Toshi Kani <toshi.kani(a)hpe.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Cc: linux-mm(a)kvack.org Cc: Borislav Petkov <bp(a)alien8.de> Cc: Andy Lutomirski <luto(a)kernel.org> Link: https://lkml.kernel.org/r/20180313170347.3829-2-toshi.kani@hpe.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/mm/fault.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -343,7 +343,7 @@ static noinline int vmalloc_fault(unsign if (!pmd_k) return -1; - if (pmd_huge(*pmd_k)) + if (pmd_large(*pmd_k)) return 0; pte_k = pte_offset_kernel(pmd_k, address); @@ -463,7 +463,7 @@ static noinline int vmalloc_fault(unsign if (pud_none(*pud) || pud_pfn(*pud) != pud_pfn(*pud_ref)) BUG(); - if (pud_huge(*pud)) + if (pud_large(*pud)) return 0; pmd = pmd_offset(pud, address); @@ -474,7 +474,7 @@ static noinline int vmalloc_fault(unsign if (pmd_none(*pmd) || pmd_pfn(*pmd) != pmd_pfn(*pmd_ref)) BUG(); - if (pmd_huge(*pmd)) + if (pmd_large(*pmd)) return 0; pte_ref = pte_offset_kernel(pmd_ref, address); Patches currently in stable-queue which might be from toshi.kani(a)hpe.com are queue-4.9/x86-mm-fix-vmalloc_fault-to-use-pxd_large.patch

7 years, 6 months

1
0
0 0

Patch "selftests/x86/entry_from_vm86: Add test cases for POPF" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selftests/x86/entry_from_vm86: Add test cases for POPF to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: selftests-x86-entry_from_vm86-add-test-cases-for-popf.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 78393fdde2a456cafa414b171c90f26a3df98b20 Mon Sep 17 00:00:00 2001 From: Andy Lutomirski <luto(a)kernel.org> Date: Tue, 13 Mar 2018 22:03:11 -0700 Subject: selftests/x86/entry_from_vm86: Add test cases for POPF From: Andy Lutomirski <luto(a)kernel.org> commit 78393fdde2a456cafa414b171c90f26a3df98b20 upstream. POPF is currently broken -- add tests to catch the error. This results in: [RUN] POPF with VIP set and IF clear from vm86 mode [INFO] Exited vm86 mode due to STI [FAIL] Incorrect return reason (started at eip = 0xd, ended at eip = 0xf) because POPF currently fails to check IF before reporting a pending interrupt. This patch also makes the FAIL message a bit more informative. Reported-by: Bart Oldeman <bartoldeman(a)gmail.com> Signed-off-by: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Stas Sergeev <stsp(a)list.ru> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: http://lkml.kernel.org/r/a16270b5cfe7832d6d00c479d0f871066cbdb52b.152100360… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/x86/entry_from_vm86.c | 30 +++++++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-) --- a/tools/testing/selftests/x86/entry_from_vm86.c +++ b/tools/testing/selftests/x86/entry_from_vm86.c @@ -95,6 +95,10 @@ asm ( "int3\n\t" "vmcode_int80:\n\t" "int $0x80\n\t" + "vmcode_popf_hlt:\n\t" + "push %ax\n\t" + "popf\n\t" + "hlt\n\t" "vmcode_umip:\n\t" /* addressing via displacements */ "smsw (2052)\n\t" @@ -124,8 +128,8 @@ asm ( extern unsigned char vmcode[], end_vmcode[]; extern unsigned char vmcode_bound[], vmcode_sysenter[], vmcode_syscall[], - vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_umip[], - vmcode_umip_str[], vmcode_umip_sldt[]; + vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_popf_hlt[], + vmcode_umip[], vmcode_umip_str[], vmcode_umip_sldt[]; /* Returns false if the test was skipped. */ static bool do_test(struct vm86plus_struct *v86, unsigned long eip, @@ -175,7 +179,7 @@ static bool do_test(struct vm86plus_stru (VM86_TYPE(ret) == rettype && VM86_ARG(ret) == retarg)) { printf("[OK]\tReturned correctly\n"); } else { - printf("[FAIL]\tIncorrect return reason\n"); + printf("[FAIL]\tIncorrect return reason (started at eip = 0x%lx, ended at eip = 0x%lx)\n", eip, v86->regs.eip); nerrs++; } @@ -264,6 +268,9 @@ int main(void) v86.regs.ds = load_addr / 16; v86.regs.es = load_addr / 16; + /* Use the end of the page as our stack. */ + v86.regs.esp = 4096; + assert((v86.regs.cs & 3) == 0); /* Looks like RPL = 0 */ /* #BR -- should deliver SIG??? */ @@ -295,6 +302,23 @@ int main(void) v86.regs.eflags &= ~X86_EFLAGS_IF; do_test(&v86, vmcode_sti - vmcode, VM86_STI, 0, "STI with VIP set"); + /* POPF with VIP set but IF clear: should not trap */ + v86.regs.eflags = X86_EFLAGS_VIP; + v86.regs.eax = 0; + do_test(&v86, vmcode_popf_hlt - vmcode, VM86_UNKNOWN, 0, "POPF with VIP set and IF clear"); + + /* POPF with VIP set and IF set: should trap */ + v86.regs.eflags = X86_EFLAGS_VIP; + v86.regs.eax = X86_EFLAGS_IF; + do_test(&v86, vmcode_popf_hlt - vmcode, VM86_STI, 0, "POPF with VIP and IF set"); + + /* POPF with VIP clear and IF set: should not trap */ + v86.regs.eflags = 0; + v86.regs.eax = X86_EFLAGS_IF; + do_test(&v86, vmcode_popf_hlt - vmcode, VM86_UNKNOWN, 0, "POPF with VIP clear and IF set"); + + v86.regs.eflags = 0; + /* INT3 -- should cause #BP */ do_test(&v86, vmcode_int3 - vmcode, VM86_TRAP, 3, "INT3"); Patches currently in stable-queue which might be from luto(a)kernel.org are queue-4.9/selftests-x86-add-tests-for-the-str-and-sldt-instructions.patch queue-4.9/x86-speculation-objtool-annotate-indirect-calls-jumps-for-objtool-on-32-bit-kernels.patch queue-4.9/x86-vm86-32-fix-popf-emulation.patch queue-4.9/selftests-x86-add-tests-for-user-mode-instruction-prevention.patch queue-4.9/perf-tools-make-perf_event__synthesize_mmap_events-scale.patch queue-4.9/x86-mm-fix-vmalloc_fault-to-use-pxd_large.patch queue-4.9/x86-mm-make-mmap-map_32bit-work-correctly.patch queue-4.9/selftests-x86-entry_from_vm86-add-test-cases-for-popf.patch queue-4.9/x86-boot-32-defer-resyncing-initial_page_table-until-per-cpu-is-set-up.patch queue-4.9/x86-boot-32-fix-up-boot-on-quark-and-possibly-other-platforms.patch queue-4.9/selftests-x86-entry_from_vm86-exit-with-1-if-we-fail.patch

7 years, 6 months

1
0
0 0

Patch "selftests/x86/entry_from_vm86: Exit with 1 if we fail" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selftests/x86/entry_from_vm86: Exit with 1 if we fail to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: selftests-x86-entry_from_vm86-exit-with-1-if-we-fail.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 327d53d005ca47b10eae940616ed11c569f75a9b Mon Sep 17 00:00:00 2001 From: Andy Lutomirski <luto(a)kernel.org> Date: Tue, 13 Mar 2018 22:03:10 -0700 Subject: selftests/x86/entry_from_vm86: Exit with 1 if we fail From: Andy Lutomirski <luto(a)kernel.org> commit 327d53d005ca47b10eae940616ed11c569f75a9b upstream. Fix a logic error that caused the test to exit with 0 even if test cases failed. Signed-off-by: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Stas Sergeev <stsp(a)list.ru> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: bartoldeman(a)gmail.com Cc: stable(a)vger.kernel.org Link: http://lkml.kernel.org/r/b1cc37144038958a469c8f70a5f47a6a5638636a.152100360… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/x86/entry_from_vm86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/testing/selftests/x86/entry_from_vm86.c +++ b/tools/testing/selftests/x86/entry_from_vm86.c @@ -231,7 +231,7 @@ int main(void) clearhandler(SIGSEGV); /* Make sure nothing explodes if we fork. */ - if (fork() > 0) + if (fork() == 0) return 0; return (nerrs == 0 ? 0 : 1); Patches currently in stable-queue which might be from luto(a)kernel.org are queue-4.9/selftests-x86-add-tests-for-the-str-and-sldt-instructions.patch queue-4.9/x86-speculation-objtool-annotate-indirect-calls-jumps-for-objtool-on-32-bit-kernels.patch queue-4.9/x86-vm86-32-fix-popf-emulation.patch queue-4.9/selftests-x86-add-tests-for-user-mode-instruction-prevention.patch queue-4.9/perf-tools-make-perf_event__synthesize_mmap_events-scale.patch queue-4.9/x86-mm-fix-vmalloc_fault-to-use-pxd_large.patch queue-4.9/x86-mm-make-mmap-map_32bit-work-correctly.patch queue-4.9/selftests-x86-entry_from_vm86-add-test-cases-for-popf.patch queue-4.9/x86-boot-32-defer-resyncing-initial_page_table-until-per-cpu-is-set-up.patch queue-4.9/x86-boot-32-fix-up-boot-on-quark-and-possibly-other-platforms.patch queue-4.9/selftests-x86-entry_from_vm86-exit-with-1-if-we-fail.patch

7 years, 6 months

1
0
0 0

Patch "selftests/x86: Add tests for User-Mode Instruction Prevention" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selftests/x86: Add tests for User-Mode Instruction Prevention to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: selftests-x86-add-tests-for-user-mode-instruction-prevention.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 9390afebe1d3f5a0be18b1afdd0ce09d67cebf9e Mon Sep 17 00:00:00 2001 From: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> Date: Sun, 5 Nov 2017 18:27:56 -0800 Subject: selftests/x86: Add tests for User-Mode Instruction Prevention From: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> commit 9390afebe1d3f5a0be18b1afdd0ce09d67cebf9e upstream. Certain user space programs that run on virtual-8086 mode may utilize instructions protected by the User-Mode Instruction Prevention (UMIP) security feature present in new Intel processors: SGDT, SIDT and SMSW. In such a case, a general protection fault is issued if UMIP is enabled. When such a fault happens, the kernel traps it and emulates the results of these instructions with dummy values. The purpose of this new test is to verify whether the impacted instructions can be executed without causing such #GP. If no #GP exceptions occur, we expect to exit virtual-8086 mode from INT3. The instructions protected by UMIP are executed in representative use cases: a) displacement-only memory addressing b) register-indirect memory addressing c) results stored directly in operands Unfortunately, it is not possible to check the results against a set of expected values because no emulation will occur in systems that do not have the UMIP feature. Instead, results are printed for verification. A simple verification is done to ensure that results of all tests are identical. Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> Reviewed-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Borislav Petkov <bp(a)suse.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Chen Yucong <slaoub(a)gmail.com> Cc: Chris Metcalf <cmetcalf(a)mellanox.com> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Huang Rui <ray.huang(a)amd.com> Cc: Jiri Slaby <jslaby(a)suse.cz> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Michael S. Tsirkin <mst(a)redhat.com> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Paul Gortmaker <paul.gortmaker(a)windriver.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Ravi V. Shankar <ravi.v.shankar(a)intel.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Tony Luck <tony.luck(a)intel.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: ricardo.neri(a)intel.com Link: http://lkml.kernel.org/r/1509935277-22138-12-git-send-email-ricardo.neri-ca… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/x86/entry_from_vm86.c | 73 +++++++++++++++++++++++++- 1 file changed, 72 insertions(+), 1 deletion(-) --- a/tools/testing/selftests/x86/entry_from_vm86.c +++ b/tools/testing/selftests/x86/entry_from_vm86.c @@ -95,6 +95,22 @@ asm ( "int3\n\t" "vmcode_int80:\n\t" "int $0x80\n\t" + "vmcode_umip:\n\t" + /* addressing via displacements */ + "smsw (2052)\n\t" + "sidt (2054)\n\t" + "sgdt (2060)\n\t" + /* addressing via registers */ + "mov $2066, %bx\n\t" + "smsw (%bx)\n\t" + "mov $2068, %bx\n\t" + "sidt (%bx)\n\t" + "mov $2074, %bx\n\t" + "sgdt (%bx)\n\t" + /* register operands, only for smsw */ + "smsw %ax\n\t" + "mov %ax, (2080)\n\t" + "int3\n\t" ".size vmcode, . - vmcode\n\t" "end_vmcode:\n\t" ".code32\n\t" @@ -103,7 +119,7 @@ asm ( extern unsigned char vmcode[], end_vmcode[]; extern unsigned char vmcode_bound[], vmcode_sysenter[], vmcode_syscall[], - vmcode_sti[], vmcode_int3[], vmcode_int80[]; + vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_umip[]; /* Returns false if the test was skipped. */ static bool do_test(struct vm86plus_struct *v86, unsigned long eip, @@ -160,6 +176,58 @@ static bool do_test(struct vm86plus_stru return true; } +void do_umip_tests(struct vm86plus_struct *vm86, unsigned char *test_mem) +{ + struct table_desc { + unsigned short limit; + unsigned long base; + } __attribute__((packed)); + + /* Initialize variables with arbitrary values */ + struct table_desc gdt1 = { .base = 0x3c3c3c3c, .limit = 0x9999 }; + struct table_desc gdt2 = { .base = 0x1a1a1a1a, .limit = 0xaeae }; + struct table_desc idt1 = { .base = 0x7b7b7b7b, .limit = 0xf1f1 }; + struct table_desc idt2 = { .base = 0x89898989, .limit = 0x1313 }; + unsigned short msw1 = 0x1414, msw2 = 0x2525, msw3 = 3737; + + /* UMIP -- exit with INT3 unless kernel emulation did not trap #GP */ + do_test(vm86, vmcode_umip - vmcode, VM86_TRAP, 3, "UMIP tests"); + + /* Results from displacement-only addressing */ + msw1 = *(unsigned short *)(test_mem + 2052); + memcpy(&idt1, test_mem + 2054, sizeof(idt1)); + memcpy(&gdt1, test_mem + 2060, sizeof(gdt1)); + + /* Results from register-indirect addressing */ + msw2 = *(unsigned short *)(test_mem + 2066); + memcpy(&idt2, test_mem + 2068, sizeof(idt2)); + memcpy(&gdt2, test_mem + 2074, sizeof(gdt2)); + + /* Results when using register operands */ + msw3 = *(unsigned short *)(test_mem + 2080); + + printf("[INFO]\tResult from SMSW:[0x%04x]\n", msw1); + printf("[INFO]\tResult from SIDT: limit[0x%04x]base[0x%08lx]\n", + idt1.limit, idt1.base); + printf("[INFO]\tResult from SGDT: limit[0x%04x]base[0x%08lx]\n", + gdt1.limit, gdt1.base); + + if (msw1 != msw2 || msw1 != msw3) + printf("[FAIL]\tAll the results of SMSW should be the same.\n"); + else + printf("[PASS]\tAll the results from SMSW are identical.\n"); + + if (memcmp(&gdt1, &gdt2, sizeof(gdt1))) + printf("[FAIL]\tAll the results of SGDT should be the same.\n"); + else + printf("[PASS]\tAll the results from SGDT are identical.\n"); + + if (memcmp(&idt1, &idt2, sizeof(idt1))) + printf("[FAIL]\tAll the results of SIDT should be the same.\n"); + else + printf("[PASS]\tAll the results from SIDT are identical.\n"); +} + int main(void) { struct vm86plus_struct v86; @@ -218,6 +286,9 @@ int main(void) v86.regs.eax = (unsigned int)-1; do_test(&v86, vmcode_int80 - vmcode, VM86_INTx, 0x80, "int80"); + /* UMIP -- should exit with INTx 0x80 unless UMIP was not disabled */ + do_umip_tests(&v86, addr); + /* Execute a null pointer */ v86.regs.cs = 0; v86.regs.ss = 0; Patches currently in stable-queue which might be from ricardo.neri-calderon(a)linux.intel.com are queue-4.9/selftests-x86-add-tests-for-the-str-and-sldt-instructions.patch queue-4.9/selftests-x86-add-tests-for-user-mode-instruction-prevention.patch

7 years, 6 months

1
0
0 0

Patch "selftests/x86: Add tests for the STR and SLDT instructions" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selftests/x86: Add tests for the STR and SLDT instructions to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: selftests-x86-add-tests-for-the-str-and-sldt-instructions.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a9e017d5619eb371460c8e516f4684def62bef3a Mon Sep 17 00:00:00 2001 From: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> Date: Sun, 5 Nov 2017 18:27:57 -0800 Subject: selftests/x86: Add tests for the STR and SLDT instructions From: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> commit a9e017d5619eb371460c8e516f4684def62bef3a upstream. The STR and SLDT instructions are not valid when running on virtual-8086 mode and generate an invalid operand exception. These two instructions are protected by the Intel User-Mode Instruction Prevention (UMIP) security feature. In protected mode, if UMIP is enabled, these instructions generate a general protection fault if called from CPL > 0. Linux traps the general protection fault and emulates the instructions sgdt, sidt and smsw; but not str and sldt. These tests are added to verify that the emulation code does not emulate these two instructions but the expected invalid operand exception is seen. Tests fallback to exit with INT3 in case emulation does happen. Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> Reviewed-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Borislav Petkov <bp(a)suse.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Chen Yucong <slaoub(a)gmail.com> Cc: Chris Metcalf <cmetcalf(a)mellanox.com> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Huang Rui <ray.huang(a)amd.com> Cc: Jiri Slaby <jslaby(a)suse.cz> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Michael S. Tsirkin <mst(a)redhat.com> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Paul Gortmaker <paul.gortmaker(a)windriver.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Ravi V. Shankar <ravi.v.shankar(a)intel.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Tony Luck <tony.luck(a)intel.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: ricardo.neri(a)intel.com Link: http://lkml.kernel.org/r/1509935277-22138-13-git-send-email-ricardo.neri-ca… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/x86/entry_from_vm86.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) --- a/tools/testing/selftests/x86/entry_from_vm86.c +++ b/tools/testing/selftests/x86/entry_from_vm86.c @@ -111,6 +111,11 @@ asm ( "smsw %ax\n\t" "mov %ax, (2080)\n\t" "int3\n\t" + "vmcode_umip_str:\n\t" + "str %eax\n\t" + "vmcode_umip_sldt:\n\t" + "sldt %eax\n\t" + "int3\n\t" ".size vmcode, . - vmcode\n\t" "end_vmcode:\n\t" ".code32\n\t" @@ -119,7 +124,8 @@ asm ( extern unsigned char vmcode[], end_vmcode[]; extern unsigned char vmcode_bound[], vmcode_sysenter[], vmcode_syscall[], - vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_umip[]; + vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_umip[], + vmcode_umip_str[], vmcode_umip_sldt[]; /* Returns false if the test was skipped. */ static bool do_test(struct vm86plus_struct *v86, unsigned long eip, @@ -226,6 +232,16 @@ void do_umip_tests(struct vm86plus_struc printf("[FAIL]\tAll the results of SIDT should be the same.\n"); else printf("[PASS]\tAll the results from SIDT are identical.\n"); + + sethandler(SIGILL, sighandler, 0); + do_test(vm86, vmcode_umip_str - vmcode, VM86_SIGNAL, 0, + "STR instruction"); + clearhandler(SIGILL); + + sethandler(SIGILL, sighandler, 0); + do_test(vm86, vmcode_umip_sldt - vmcode, VM86_SIGNAL, 0, + "SLDT instruction"); + clearhandler(SIGILL); } int main(void) Patches currently in stable-queue which might be from ricardo.neri-calderon(a)linux.intel.com are queue-4.9/selftests-x86-add-tests-for-the-str-and-sldt-instructions.patch queue-4.9/selftests-x86-add-tests-for-user-mode-instruction-prevention.patch

7 years, 6 months

1
0
0 0

Patch "parisc: Handle case where flush_cache_range is called with no context" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled parisc: Handle case where flush_cache_range is called with no context to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: parisc-handle-case-where-flush_cache_range-is-called-with-no-context.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 9ef0f88fe5466c2ca1d2975549ba6be502c464c1 Mon Sep 17 00:00:00 2001 From: John David Anglin <dave.anglin(a)bell.net> Date: Wed, 7 Mar 2018 08:18:05 -0500 Subject: parisc: Handle case where flush_cache_range is called with no context MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: John David Anglin <dave.anglin(a)bell.net> commit 9ef0f88fe5466c2ca1d2975549ba6be502c464c1 upstream. Just when I had decided that flush_cache_range() was always called with a valid context, Helge reported two cases where the "BUG_ON(!vma->vm_mm->context);" was hit on the phantom buildd: kernel BUG at /mnt/sdb6/linux/linux-4.15.4/arch/parisc/kernel/cache.c:587! CPU: 1 PID: 3254 Comm: kworker/1:2 Tainted: G D 4.15.0-1-parisc64-smp #1 Debian 4.15.4-1+b1 Workqueue: events free_ioctx IAOQ[0]: flush_cache_range+0x164/0x168 IAOQ[1]: flush_cache_page+0x0/0x1c8 RP(r2): unmap_page_range+0xae8/0xb88 Backtrace: [<00000000404a6980>] unmap_page_range+0xae8/0xb88 [<00000000404a6ae0>] unmap_single_vma+0xc0/0x188 [<00000000404a6cdc>] zap_page_range_single+0x134/0x1f8 [<00000000404a702c>] unmap_mapping_range+0x1cc/0x208 [<0000000040461518>] truncate_pagecache+0x98/0x108 [<0000000040461624>] truncate_setsize+0x9c/0xb8 [<00000000405d7f30>] put_aio_ring_file+0x80/0x100 [<00000000405d803c>] aio_free_ring+0x8c/0x290 [<00000000405d82c0>] free_ioctx+0x80/0x180 [<0000000040284e6c>] process_one_work+0x21c/0x668 [<00000000402854c4>] worker_thread+0x20c/0x778 [<0000000040291d44>] kthread+0x2d4/0x2e0 [<0000000040204020>] end_fault_vector+0x20/0xc0 This indicates that we need to handle the no context case in flush_cache_range() as we do in flush_cache_mm(). In thinking about this, I realized that we don't need to flush the TLB when there is no context. So, I added context checks to the large flush cases in flush_cache_mm() and flush_cache_range(). The large flush case occurs frequently in flush_cache_mm() and the change should improve fork performance. The v2 version of this change removes the BUG_ON from flush_cache_page() by skipping the TLB flush when there is no context. I also added code to flush the TLB in flush_cache_mm() and flush_cache_range() when we have a context that's not current. Now all three routines handle TLB flushes in a similar manner. Signed-off-by: John David Anglin <dave.anglin(a)bell.net> Cc: stable(a)vger.kernel.org # 4.9+ Signed-off-by: Helge Deller <deller(a)gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/parisc/kernel/cache.c | 41 ++++++++++++++++++++++++++++++++--------- 1 file changed, 32 insertions(+), 9 deletions(-) --- a/arch/parisc/kernel/cache.c +++ b/arch/parisc/kernel/cache.c @@ -542,7 +542,8 @@ void flush_cache_mm(struct mm_struct *mm rp3440, etc. So, avoid it if the mm isn't too big. */ if ((!IS_ENABLED(CONFIG_SMP) || !arch_irqs_disabled()) && mm_total_size(mm) >= parisc_cache_flush_threshold) { - flush_tlb_all(); + if (mm->context) + flush_tlb_all(); flush_cache_all(); return; } @@ -570,6 +571,8 @@ void flush_cache_mm(struct mm_struct *mm pfn = pte_pfn(*ptep); if (!pfn_valid(pfn)) continue; + if (unlikely(mm->context)) + flush_tlb_page(vma, addr); __flush_cache_page(vma, addr, PFN_PHYS(pfn)); } } @@ -596,26 +599,46 @@ flush_user_icache_range(unsigned long st void flush_cache_range(struct vm_area_struct *vma, unsigned long start, unsigned long end) { + pgd_t *pgd; + unsigned long addr; + if ((!IS_ENABLED(CONFIG_SMP) || !arch_irqs_disabled()) && end - start >= parisc_cache_flush_threshold) { - flush_tlb_range(vma, start, end); + if (vma->vm_mm->context) + flush_tlb_range(vma, start, end); flush_cache_all(); return; } - flush_user_dcache_range_asm(start, end); - if (vma->vm_flags & VM_EXEC) - flush_user_icache_range_asm(start, end); - flush_tlb_range(vma, start, end); + if (vma->vm_mm->context == mfsp(3)) { + flush_user_dcache_range_asm(start, end); + if (vma->vm_flags & VM_EXEC) + flush_user_icache_range_asm(start, end); + flush_tlb_range(vma, start, end); + return; + } + + pgd = vma->vm_mm->pgd; + for (addr = vma->vm_start; addr < vma->vm_end; addr += PAGE_SIZE) { + unsigned long pfn; + pte_t *ptep = get_ptep(pgd, addr); + if (!ptep) + continue; + pfn = pte_pfn(*ptep); + if (pfn_valid(pfn)) { + if (unlikely(vma->vm_mm->context)) + flush_tlb_page(vma, addr); + __flush_cache_page(vma, addr, PFN_PHYS(pfn)); + } + } } void flush_cache_page(struct vm_area_struct *vma, unsigned long vmaddr, unsigned long pfn) { - BUG_ON(!vma->vm_mm->context); - if (pfn_valid(pfn)) { - flush_tlb_page(vma, vmaddr); + if (likely(vma->vm_mm->context)) + flush_tlb_page(vma, vmaddr); __flush_cache_page(vma, vmaddr, PFN_PHYS(pfn)); } } Patches currently in stable-queue which might be from dave.anglin(a)bell.net are queue-4.9/parisc-handle-case-where-flush_cache_range-is-called-with-no-context.patch

7 years, 6 months

1
0
0 0

Patch "lock_parent() needs to recheck if dentry got __dentry_kill'ed under it" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled lock_parent() needs to recheck if dentry got __dentry_kill'ed under it to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: lock_parent-needs-to-recheck-if-dentry-got-__dentry_kill-ed-under-it.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 3b821409632ab778d46e807516b457dfa72736ed Mon Sep 17 00:00:00 2001 From: Al Viro <viro(a)zeniv.linux.org.uk> Date: Fri, 23 Feb 2018 20:47:17 -0500 Subject: lock_parent() needs to recheck if dentry got __dentry_kill'ed under it From: Al Viro <viro(a)zeniv.linux.org.uk> commit 3b821409632ab778d46e807516b457dfa72736ed upstream. In case when dentry passed to lock_parent() is protected from freeing only by the fact that it's on a shrink list and trylock of parent fails, we could get hit by __dentry_kill() (and subsequent dentry_kill(parent)) between unlocking dentry and locking presumed parent. We need to recheck that dentry is alive once we lock both it and parent *and* postpone rcu_read_unlock() until after that point. Otherwise we could return a pointer to struct dentry that already is rcu-scheduled for freeing, with ->d_lock held on it; caller's subsequent attempt to unlock it can end up with memory corruption. Cc: stable(a)vger.kernel.org # 3.12+, counting backports Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/dcache.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) --- a/fs/dcache.c +++ b/fs/dcache.c @@ -637,11 +637,16 @@ again: spin_unlock(&parent->d_lock); goto again; } - rcu_read_unlock(); - if (parent != dentry) + if (parent != dentry) { spin_lock_nested(&dentry->d_lock, DENTRY_D_LOCK_NESTED); - else + if (unlikely(dentry->d_lockref.count < 0)) { + spin_unlock(&parent->d_lock); + parent = NULL; + } + } else { parent = NULL; + } + rcu_read_unlock(); return parent; } Patches currently in stable-queue which might be from viro(a)zeniv.linux.org.uk are queue-4.9/fs-teach-path_connected-to-handle-nfs-filesystems-with-multiple-roots.patch queue-4.9/lock_parent-needs-to-recheck-if-dentry-got-__dentry_kill-ed-under-it.patch

7 years, 6 months

1
0
0 0

Patch "fs: Teach path_connected to handle nfs filesystems with multiple roots." has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fs: Teach path_connected to handle nfs filesystems with multiple roots. to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: fs-teach-path_connected-to-handle-nfs-filesystems-with-multiple-roots.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 95dd77580ccd66a0da96e6d4696945b8cea39431 Mon Sep 17 00:00:00 2001 From: "Eric W. Biederman" <ebiederm(a)xmission.com> Date: Wed, 14 Mar 2018 18:20:29 -0500 Subject: fs: Teach path_connected to handle nfs filesystems with multiple roots. From: Eric W. Biederman <ebiederm(a)xmission.com> commit 95dd77580ccd66a0da96e6d4696945b8cea39431 upstream. On nfsv2 and nfsv3 the nfs server can export subsets of the same filesystem and report the same filesystem identifier, so that the nfs client can know they are the same filesystem. The subsets can be from disjoint directory trees. The nfsv2 and nfsv3 filesystems provides no way to find the common root of all directory trees exported form the server with the same filesystem identifier. The practical result is that in struct super s_root for nfs s_root is not necessarily the root of the filesystem. The nfs mount code sets s_root to the root of the first subset of the nfs filesystem that the kernel mounts. This effects the dcache invalidation code in generic_shutdown_super currently called shrunk_dcache_for_umount and that code for years has gone through an additional list of dentries that might be dentry trees that need to be freed to accomodate nfs. When I wrote path_connected I did not realize nfs was so special, and it's hueristic for avoiding calling is_subdir can fail. The practical case where this fails is when there is a move of a directory from the subtree exposed by one nfs mount to the subtree exposed by another nfs mount. This move can happen either locally or remotely. With the remote case requiring that the move directory be cached before the move and that after the move someone walks the path to where the move directory now exists and in so doing causes the already cached directory to be moved in the dcache through the magic of d_splice_alias. If someone whose working directory is in the move directory or a subdirectory and now starts calling .. from the initial mount of nfs (where s_root == mnt_root), then path_connected as a heuristic will not bother with the is_subdir check. As s_root really is not the root of the nfs filesystem this heuristic is wrong, and the path may actually not be connected and path_connected can fail. The is_subdir function might be cheap enough that we can call it unconditionally. Verifying that will take some benchmarking and the result may not be the same on all kernels this fix needs to be backported to. So I am avoiding that for now. Filesystems with snapshots such as nilfs and btrfs do something similar. But as the directory tree of the snapshots are disjoint from one another and from the main directory tree rename won't move things between them and this problem will not occur. Cc: stable(a)vger.kernel.org Reported-by: Al Viro <viro(a)ZenIV.linux.org.uk> Fixes: 397d425dc26d ("vfs: Test for and handle paths that are unreachable from their mnt_root") Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/namei.c | 5 +++-- fs/nfs/super.c | 2 ++ include/linux/fs.h | 1 + 3 files changed, 6 insertions(+), 2 deletions(-) --- a/fs/namei.c +++ b/fs/namei.c @@ -578,9 +578,10 @@ static int __nd_alloc_stack(struct namei static bool path_connected(const struct path *path) { struct vfsmount *mnt = path->mnt; + struct super_block *sb = mnt->mnt_sb; - /* Only bind mounts can have disconnected paths */ - if (mnt->mnt_root == mnt->mnt_sb->s_root) + /* Bind mounts and multi-root filesystems can have disconnected paths */ + if (!(sb->s_iflags & SB_I_MULTIROOT) && (mnt->mnt_root == sb->s_root)) return true; return is_subdir(path->dentry, mnt->mnt_root); --- a/fs/nfs/super.c +++ b/fs/nfs/super.c @@ -2613,6 +2613,8 @@ struct dentry *nfs_fs_mount_common(struc /* initial superblock/root creation */ mount_info->fill_super(s, mount_info); nfs_get_cache_cookie(s, mount_info->parsed, mount_info->cloned); + if (!(server->flags & NFS_MOUNT_UNSHARED)) + s->s_iflags |= SB_I_MULTIROOT; } mntroot = nfs_get_root(s, mount_info->mntfh, dev_name); --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -1319,6 +1319,7 @@ struct mm_struct; #define SB_I_CGROUPWB 0x00000001 /* cgroup-aware writeback enabled */ #define SB_I_NOEXEC 0x00000002 /* Ignore executables on this fs */ #define SB_I_NODEV 0x00000004 /* Ignore devices on this fs */ +#define SB_I_MULTIROOT 0x00000008 /* Multiple roots to the dentry tree */ /* sb->s_iflags to limit user namespace mounts */ #define SB_I_USERNS_VISIBLE 0x00000010 /* fstype already mounted */ Patches currently in stable-queue which might be from ebiederm(a)xmission.com are queue-4.9/fs-teach-path_connected-to-handle-nfs-filesystems-with-multiple-roots.patch queue-4.9/userns-don-t-fail-follow_automount-based-on-s_user_ns.patch

7 years, 6 months

1
0
0 0

Patch "fs/aio: Use RCU accessors for kioctx_table->table[]" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fs/aio: Use RCU accessors for kioctx_table->table[] to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: fs-aio-use-rcu-accessors-for-kioctx_table-table.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d0264c01e7587001a8c4608a5d1818dba9a4c11a Mon Sep 17 00:00:00 2001 From: Tejun Heo <tj(a)kernel.org> Date: Wed, 14 Mar 2018 12:10:17 -0700 Subject: fs/aio: Use RCU accessors for kioctx_table->table[] From: Tejun Heo <tj(a)kernel.org> commit d0264c01e7587001a8c4608a5d1818dba9a4c11a upstream. While converting ioctx index from a list to a table, db446a08c23d ("aio: convert the ioctx list to table lookup v3") missed tagging kioctx_table->table[] as an array of RCU pointers and using the appropriate RCU accessors. This introduces a small window in the lookup path where init and access may race. Mark kioctx_table->table[] with __rcu and use the approriate RCU accessors when using the field. Signed-off-by: Tejun Heo <tj(a)kernel.org> Reported-by: Jann Horn <jannh(a)google.com> Fixes: db446a08c23d ("aio: convert the ioctx list to table lookup v3") Cc: Benjamin LaHaise <bcrl(a)kvack.org> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: stable(a)vger.kernel.org # v3.12+ Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/aio.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) --- a/fs/aio.c +++ b/fs/aio.c @@ -68,9 +68,9 @@ struct aio_ring { #define AIO_RING_PAGES 8 struct kioctx_table { - struct rcu_head rcu; - unsigned nr; - struct kioctx *table[]; + struct rcu_head rcu; + unsigned nr; + struct kioctx __rcu *table[]; }; struct kioctx_cpu { @@ -330,7 +330,7 @@ static int aio_ring_mremap(struct vm_are for (i = 0; i < table->nr; i++) { struct kioctx *ctx; - ctx = table->table[i]; + ctx = rcu_dereference(table->table[i]); if (ctx && ctx->aio_ring_file == file) { if (!atomic_read(&ctx->dead)) { ctx->user_id = ctx->mmap_base = vma->vm_start; @@ -659,9 +659,9 @@ static int ioctx_add_table(struct kioctx while (1) { if (table) for (i = 0; i < table->nr; i++) - if (!table->table[i]) { + if (!rcu_access_pointer(table->table[i])) { ctx->id = i; - table->table[i] = ctx; + rcu_assign_pointer(table->table[i], ctx); spin_unlock(&mm->ioctx_lock); /* While kioctx setup is in progress, @@ -836,8 +836,8 @@ static int kill_ioctx(struct mm_struct * } table = rcu_dereference_raw(mm->ioctx_table); - WARN_ON(ctx != table->table[ctx->id]); - table->table[ctx->id] = NULL; + WARN_ON(ctx != rcu_access_pointer(table->table[ctx->id])); + RCU_INIT_POINTER(table->table[ctx->id], NULL); spin_unlock(&mm->ioctx_lock); /* free_ioctx_reqs() will do the necessary RCU synchronization */ @@ -882,7 +882,8 @@ void exit_aio(struct mm_struct *mm) skipped = 0; for (i = 0; i < table->nr; ++i) { - struct kioctx *ctx = table->table[i]; + struct kioctx *ctx = + rcu_dereference_protected(table->table[i], true); if (!ctx) { skipped++; @@ -1071,7 +1072,7 @@ static struct kioctx *lookup_ioctx(unsig if (!table || id >= table->nr) goto out; - ctx = table->table[id]; + ctx = rcu_dereference(table->table[id]); if (ctx && ctx->user_id == ctx_id) { percpu_ref_get(&ctx->users); ret = ctx; Patches currently in stable-queue which might be from tj(a)kernel.org are queue-4.9/fs-aio-add-explicit-rcu-grace-period-when-freeing-kioctx.patch queue-4.9/fs-aio-use-rcu-accessors-for-kioctx_table-table.patch

7 years, 6 months

1
0
0 0

Patch "fs/aio: Add explicit RCU grace period when freeing kioctx" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fs/aio: Add explicit RCU grace period when freeing kioctx to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: fs-aio-add-explicit-rcu-grace-period-when-freeing-kioctx.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a6d7cff472eea87d96899a20fa718d2bab7109f3 Mon Sep 17 00:00:00 2001 From: Tejun Heo <tj(a)kernel.org> Date: Wed, 14 Mar 2018 12:10:17 -0700 Subject: fs/aio: Add explicit RCU grace period when freeing kioctx From: Tejun Heo <tj(a)kernel.org> commit a6d7cff472eea87d96899a20fa718d2bab7109f3 upstream. While fixing refcounting, e34ecee2ae79 ("aio: Fix a trinity splat") incorrectly removed explicit RCU grace period before freeing kioctx. The intention seems to be depending on the internal RCU grace periods of percpu_ref; however, percpu_ref uses a different flavor of RCU, sched-RCU. This can lead to kioctx being freed while RCU read protected dereferences are still in progress. Fix it by updating free_ioctx() to go through call_rcu() explicitly. v2: Comment added to explain double bouncing. Signed-off-by: Tejun Heo <tj(a)kernel.org> Reported-by: Jann Horn <jannh(a)google.com> Fixes: e34ecee2ae79 ("aio: Fix a trinity splat") Cc: Kent Overstreet <kent.overstreet(a)gmail.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: stable(a)vger.kernel.org # v3.13+ Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/aio.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) --- a/fs/aio.c +++ b/fs/aio.c @@ -115,7 +115,8 @@ struct kioctx { struct page **ring_pages; long nr_pages; - struct work_struct free_work; + struct rcu_head free_rcu; + struct work_struct free_work; /* see free_ioctx() */ /* * signals when all in-flight requests are done @@ -581,6 +582,12 @@ static int kiocb_cancel(struct aio_kiocb return cancel(&kiocb->common); } +/* + * free_ioctx() should be RCU delayed to synchronize against the RCU + * protected lookup_ioctx() and also needs process context to call + * aio_free_ring(), so the double bouncing through kioctx->free_rcu and + * ->free_work. + */ static void free_ioctx(struct work_struct *work) { struct kioctx *ctx = container_of(work, struct kioctx, free_work); @@ -594,6 +601,14 @@ static void free_ioctx(struct work_struc kmem_cache_free(kioctx_cachep, ctx); } +static void free_ioctx_rcufn(struct rcu_head *head) +{ + struct kioctx *ctx = container_of(head, struct kioctx, free_rcu); + + INIT_WORK(&ctx->free_work, free_ioctx); + schedule_work(&ctx->free_work); +} + static void free_ioctx_reqs(struct percpu_ref *ref) { struct kioctx *ctx = container_of(ref, struct kioctx, reqs); @@ -602,8 +617,8 @@ static void free_ioctx_reqs(struct percp if (ctx->rq_wait && atomic_dec_and_test(&ctx->rq_wait->count)) complete(&ctx->rq_wait->comp); - INIT_WORK(&ctx->free_work, free_ioctx); - schedule_work(&ctx->free_work); + /* Synchronize against RCU protected table->table[] dereferences */ + call_rcu(&ctx->free_rcu, free_ioctx_rcufn); } /* @@ -825,7 +840,7 @@ static int kill_ioctx(struct mm_struct * table->table[ctx->id] = NULL; spin_unlock(&mm->ioctx_lock); - /* percpu_ref_kill() will do the necessary call_rcu() */ + /* free_ioctx_reqs() will do the necessary RCU synchronization */ wake_up_all(&ctx->wait); /* Patches currently in stable-queue which might be from tj(a)kernel.org are queue-4.9/fs-aio-add-explicit-rcu-grace-period-when-freeing-kioctx.patch queue-4.9/fs-aio-use-rcu-accessors-for-kioctx_table-table.patch

7 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror