* x86: PIE support and option to extend KASLR randomization
From: Thomas Garnier via Virtualization @ 2017-10-04 21:19 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Thomas Gleixner, Ingo Molnar,
H . Peter Anvin, Peter Zijlstra, Josh Poimboeuf, Thomas Garnier,
Arnd Bergmann, Kees Cook, Matthias Kaehlcke, Tom Lendacky,
Andy Lutomirski, Kirill A . Shutemov, Borislav Petkov,
Rafael J . Wysocki, Len Brown, Pavel Machek, Juergen Gross,
Chris Wright, Alok Kataria, Rusty Russell, Tejun Heo,
Christoph Lameter
Cc: linux-arch, kvm, linux-pm, x86, linux-doc, linux-kernel,
virtualization, linux-sparse, linux-crypto, kernel-hardening,
xen-devel
These patches make the changes necessary to build the kernel as Position
Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below
the top 2G of the virtual address space. It allows to optionally extend the
KASLR randomization range from 1G to 3G.
Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler
changes, PIE support and KASLR in general. Thanks to Roland McGrath on his
feedback for using -pie versus --emit-relocs and details on compiler code
generation.
The patches:
- 1-3, 5-1#, 17-18: Change in assembly code to be PIE compliant.
- 4: Add a new _ASM_GET_PTR macro to fetch a symbol address generically.
- 14: Adapt percpu design to work correctly when PIE is enabled.
- 15: Provide an option to default visibility to hidden except for key symbols.
It removes errors between compilation units.
- 16: Adapt relocation tool to handle PIE binary correctly.
- 19: Add support for global cookie.
- 20: Support ftrace with PIE (used on Ubuntu config).
- 21: Fix incorrect address marker on dump_pagetables.
- 22: Add option to move the module section just after the kernel.
- 23: Adapt module loading to support PIE with dynamic GOT.
- 24: Make the GOT read-only.
- 25: Add the CONFIG_X86_PIE option (off by default).
- 26: Adapt relocation tool to generate a 64-bit relocation table.
- 27: Add the CONFIG_RANDOMIZE_BASE_LARGE option to increase relocation range
from 1G to 3G (off by default).
Performance/Size impact:
Size of vmlinux (Default configuration):
File size:
- PIE disabled: +0.000031%
- PIE enabled: -3.210% (less relocations)
.text section:
- PIE disabled: +0.000644%
- PIE enabled: +0.837%
Size of vmlinux (Ubuntu configuration):
File size:
- PIE disabled: -0.201%
- PIE enabled: -0.082%
.text section:
- PIE disabled: same
- PIE enabled: +1.319%
Size of vmlinux (Default configuration + ORC):
File size:
- PIE enabled: -3.167%
.text section:
- PIE enabled: +0.814%
Size of vmlinux (Ubuntu configuration + ORC):
File size:
- PIE enabled: -3.167%
.text section:
- PIE enabled: +1.26%
The size increase is mainly due to not having access to the 32-bit signed
relocation that can be used with mcmodel=kernel. A small part is due to reduced
optimization for PIE code. This bug [1] was opened with gcc to provide a better
code generation for kernel PIE.
Hackbench (50% and 1600% on thread/process for pipe/sockets):
- PIE disabled: no significant change (avg +0.1% on latest test).
- PIE enabled: between -0.50% to +0.86% in average (default and Ubuntu config).
slab_test (average of 10 runs):
- PIE disabled: no significant change (-2% on latest run, likely noise).
- PIE enabled: between -1% and +0.8% on latest runs.
Kernbench (average of 10 Half and Optimal runs):
Elapsed Time:
- PIE disabled: no significant change (avg -0.239%)
- PIE enabled: average +0.07%
System Time:
- PIE disabled: no significant change (avg -0.277%)
- PIE enabled: average +0.7%
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303
diffstat:
Documentation/x86/x86_64/mm.txt | 3
arch/x86/Kconfig | 37 ++++
arch/x86/Makefile | 14 +
arch/x86/boot/boot.h | 2
arch/x86/boot/compressed/Makefile | 5
arch/x86/boot/compressed/misc.c | 10 +
arch/x86/crypto/aes-x86_64-asm_64.S | 45 +++--
arch/x86/crypto/aesni-intel_asm.S | 14 +
arch/x86/crypto/aesni-intel_avx-x86_64.S | 6
arch/x86/crypto/camellia-aesni-avx-asm_64.S | 42 ++---
arch/x86/crypto/camellia-aesni-avx2-asm_64.S | 44 ++---
arch/x86/crypto/camellia-x86_64-asm_64.S | 8 -
arch/x86/crypto/cast5-avx-x86_64-asm_64.S | 50 +++---
arch/x86/crypto/cast6-avx-x86_64-asm_64.S | 44 +++--
arch/x86/crypto/des3_ede-asm_64.S | 96 ++++++++----
arch/x86/crypto/ghash-clmulni-intel_asm.S | 4
arch/x86/crypto/glue_helper-asm-avx.S | 4
arch/x86/crypto/glue_helper-asm-avx2.S | 6
arch/x86/entry/entry_32.S | 3
arch/x86/entry/entry_64.S | 29 ++-
arch/x86/include/asm/asm.h | 13 +
arch/x86/include/asm/bug.h | 2
arch/x86/include/asm/ftrace.h | 23 ++-
arch/x86/include/asm/jump_label.h | 8 -
arch/x86/include/asm/kvm_host.h | 6
arch/x86/include/asm/module.h | 14 +
arch/x86/include/asm/page_64_types.h | 9 +
arch/x86/include/asm/paravirt_types.h | 12 +
arch/x86/include/asm/percpu.h | 25 ++-
arch/x86/include/asm/pgtable_64_types.h | 6
arch/x86/include/asm/pm-trace.h | 2
arch/x86/include/asm/processor.h | 12 +
arch/x86/include/asm/sections.h | 4
arch/x86/include/asm/setup.h | 2
arch/x86/include/asm/stackprotector.h | 19 +-
arch/x86/kernel/acpi/wakeup_64.S | 31 ++--
arch/x86/kernel/asm-offsets.c | 3
arch/x86/kernel/asm-offsets_32.c | 3
arch/x86/kernel/asm-offsets_64.c | 3
arch/x86/kernel/cpu/common.c | 7
arch/x86/kernel/cpu/microcode/core.c | 4
arch/x86/kernel/ftrace.c | 168 ++++++++++++++--------
arch/x86/kernel/head64.c | 32 +++-
arch/x86/kernel/head_32.S | 3
arch/x86/kernel/head_64.S | 41 ++++-
arch/x86/kernel/kvm.c | 6
arch/x86/kernel/module.c | 204 ++++++++++++++++++++++++++-
arch/x86/kernel/module.lds | 3
arch/x86/kernel/process.c | 5
arch/x86/kernel/relocate_kernel_64.S | 8 -
arch/x86/kernel/setup_percpu.c | 2
arch/x86/kernel/vmlinux.lds.S | 13 +
arch/x86/kvm/svm.c | 4
arch/x86/lib/cmpxchg16b_emu.S | 8 -
arch/x86/mm/dump_pagetables.c | 11 -
arch/x86/power/hibernate_asm_64.S | 4
arch/x86/tools/relocs.c | 170 ++++++++++++++++++++--
arch/x86/tools/relocs.h | 4
arch/x86/tools/relocs_common.c | 15 +
arch/x86/xen/xen-asm.S | 12 -
arch/x86/xen/xen-head.S | 9 -
arch/x86/xen/xen-pvh.S | 13 +
drivers/base/firmware_class.c | 4
include/asm-generic/sections.h | 6
include/asm-generic/vmlinux.lds.h | 12 +
include/linux/compiler.h | 8 +
init/Kconfig | 9 +
kernel/kallsyms.c | 16 +-
kernel/trace/trace.h | 4
lib/dynamic_debug.c | 4
70 files changed, 1109 insertions(+), 363 deletions(-)
^ permalink raw reply
* x86: PIE support and option to extend KASLR randomization
From: Thomas Garnier @ 2017-10-04 21:19 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Thomas Gleixner, Ingo Molnar,
H . Peter Anvin, Peter Zijlstra, Josh Poimboeuf, Thomas Garnier,
Arnd Bergmann, Kees Cook, Matthias Kaehlcke, Tom Lendacky,
Andy Lutomirski, Kirill A . Shutemov, Borislav Petkov,
Rafael J . Wysocki, Len Brown, Pavel Machek, Juergen Gross,
Chris Wright, Alok Kataria, Rusty Russell, Tejun Heo,
Christoph Lameter
Cc: x86, linux-crypto, linux-kernel, linux-pm, virtualization,
xen-devel, linux-arch, linux-sparse, kvm, linux-doc,
kernel-hardening
These patches make the changes necessary to build the kernel as Position
Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below
the top 2G of the virtual address space. It allows to optionally extend the
KASLR randomization range from 1G to 3G.
Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler
changes, PIE support and KASLR in general. Thanks to Roland McGrath on his
feedback for using -pie versus --emit-relocs and details on compiler code
generation.
The patches:
- 1-3, 5-1#, 17-18: Change in assembly code to be PIE compliant.
- 4: Add a new _ASM_GET_PTR macro to fetch a symbol address generically.
- 14: Adapt percpu design to work correctly when PIE is enabled.
- 15: Provide an option to default visibility to hidden except for key symbols.
It removes errors between compilation units.
- 16: Adapt relocation tool to handle PIE binary correctly.
- 19: Add support for global cookie.
- 20: Support ftrace with PIE (used on Ubuntu config).
- 21: Fix incorrect address marker on dump_pagetables.
- 22: Add option to move the module section just after the kernel.
- 23: Adapt module loading to support PIE with dynamic GOT.
- 24: Make the GOT read-only.
- 25: Add the CONFIG_X86_PIE option (off by default).
- 26: Adapt relocation tool to generate a 64-bit relocation table.
- 27: Add the CONFIG_RANDOMIZE_BASE_LARGE option to increase relocation range
from 1G to 3G (off by default).
Performance/Size impact:
Size of vmlinux (Default configuration):
File size:
- PIE disabled: +0.000031%
- PIE enabled: -3.210% (less relocations)
.text section:
- PIE disabled: +0.000644%
- PIE enabled: +0.837%
Size of vmlinux (Ubuntu configuration):
File size:
- PIE disabled: -0.201%
- PIE enabled: -0.082%
.text section:
- PIE disabled: same
- PIE enabled: +1.319%
Size of vmlinux (Default configuration + ORC):
File size:
- PIE enabled: -3.167%
.text section:
- PIE enabled: +0.814%
Size of vmlinux (Ubuntu configuration + ORC):
File size:
- PIE enabled: -3.167%
.text section:
- PIE enabled: +1.26%
The size increase is mainly due to not having access to the 32-bit signed
relocation that can be used with mcmodel=kernel. A small part is due to reduced
optimization for PIE code. This bug [1] was opened with gcc to provide a better
code generation for kernel PIE.
Hackbench (50% and 1600% on thread/process for pipe/sockets):
- PIE disabled: no significant change (avg +0.1% on latest test).
- PIE enabled: between -0.50% to +0.86% in average (default and Ubuntu config).
slab_test (average of 10 runs):
- PIE disabled: no significant change (-2% on latest run, likely noise).
- PIE enabled: between -1% and +0.8% on latest runs.
Kernbench (average of 10 Half and Optimal runs):
Elapsed Time:
- PIE disabled: no significant change (avg -0.239%)
- PIE enabled: average +0.07%
System Time:
- PIE disabled: no significant change (avg -0.277%)
- PIE enabled: average +0.7%
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303
diffstat:
Documentation/x86/x86_64/mm.txt | 3
arch/x86/Kconfig | 37 ++++
arch/x86/Makefile | 14 +
arch/x86/boot/boot.h | 2
arch/x86/boot/compressed/Makefile | 5
arch/x86/boot/compressed/misc.c | 10 +
arch/x86/crypto/aes-x86_64-asm_64.S | 45 +++--
arch/x86/crypto/aesni-intel_asm.S | 14 +
arch/x86/crypto/aesni-intel_avx-x86_64.S | 6
arch/x86/crypto/camellia-aesni-avx-asm_64.S | 42 ++---
arch/x86/crypto/camellia-aesni-avx2-asm_64.S | 44 ++---
arch/x86/crypto/camellia-x86_64-asm_64.S | 8 -
arch/x86/crypto/cast5-avx-x86_64-asm_64.S | 50 +++---
arch/x86/crypto/cast6-avx-x86_64-asm_64.S | 44 +++--
arch/x86/crypto/des3_ede-asm_64.S | 96 ++++++++----
arch/x86/crypto/ghash-clmulni-intel_asm.S | 4
arch/x86/crypto/glue_helper-asm-avx.S | 4
arch/x86/crypto/glue_helper-asm-avx2.S | 6
arch/x86/entry/entry_32.S | 3
arch/x86/entry/entry_64.S | 29 ++-
arch/x86/include/asm/asm.h | 13 +
arch/x86/include/asm/bug.h | 2
arch/x86/include/asm/ftrace.h | 23 ++-
arch/x86/include/asm/jump_label.h | 8 -
arch/x86/include/asm/kvm_host.h | 6
arch/x86/include/asm/module.h | 14 +
arch/x86/include/asm/page_64_types.h | 9 +
arch/x86/include/asm/paravirt_types.h | 12 +
arch/x86/include/asm/percpu.h | 25 ++-
arch/x86/include/asm/pgtable_64_types.h | 6
arch/x86/include/asm/pm-trace.h | 2
arch/x86/include/asm/processor.h | 12 +
arch/x86/include/asm/sections.h | 4
arch/x86/include/asm/setup.h | 2
arch/x86/include/asm/stackprotector.h | 19 +-
arch/x86/kernel/acpi/wakeup_64.S | 31 ++--
arch/x86/kernel/asm-offsets.c | 3
arch/x86/kernel/asm-offsets_32.c | 3
arch/x86/kernel/asm-offsets_64.c | 3
arch/x86/kernel/cpu/common.c | 7
arch/x86/kernel/cpu/microcode/core.c | 4
arch/x86/kernel/ftrace.c | 168 ++++++++++++++--------
arch/x86/kernel/head64.c | 32 +++-
arch/x86/kernel/head_32.S | 3
arch/x86/kernel/head_64.S | 41 ++++-
arch/x86/kernel/kvm.c | 6
arch/x86/kernel/module.c | 204 ++++++++++++++++++++++++++-
arch/x86/kernel/module.lds | 3
arch/x86/kernel/process.c | 5
arch/x86/kernel/relocate_kernel_64.S | 8 -
arch/x86/kernel/setup_percpu.c | 2
arch/x86/kernel/vmlinux.lds.S | 13 +
arch/x86/kvm/svm.c | 4
arch/x86/lib/cmpxchg16b_emu.S | 8 -
arch/x86/mm/dump_pagetables.c | 11 -
arch/x86/power/hibernate_asm_64.S | 4
arch/x86/tools/relocs.c | 170 ++++++++++++++++++++--
arch/x86/tools/relocs.h | 4
arch/x86/tools/relocs_common.c | 15 +
arch/x86/xen/xen-asm.S | 12 -
arch/x86/xen/xen-head.S | 9 -
arch/x86/xen/xen-pvh.S | 13 +
drivers/base/firmware_class.c | 4
include/asm-generic/sections.h | 6
include/asm-generic/vmlinux.lds.h | 12 +
include/linux/compiler.h | 8 +
init/Kconfig | 9 +
kernel/kallsyms.c | 16 +-
kernel/trace/trace.h | 4
lib/dynamic_debug.c | 4
70 files changed, 1109 insertions(+), 363 deletions(-)
^ permalink raw reply
* x86: PIE support and option to extend KASLR randomization
From: Thomas Garnier @ 2017-10-04 21:19 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Thomas Gleixner, Ingo Molnar,
H . Peter Anvin, Peter Zijlstra, Josh Poimboeuf, Thomas Garnier,
Arnd Bergmann, Kees Cook, Matthias Kaehlcke, Tom Lendacky,
Andy Lutomirski, Kirill A . Shutemov, Borislav Petkov,
Rafael J . Wysocki, Len Brown, Pavel Machek, Juergen Gross,
Chris Wright, Alok Kataria, Rusty Russell, Tejun Heo,
Christoph Lameter
Cc: x86, linux-crypto, linux-kernel, linux-pm, virtualization,
xen-devel, linux-arch, linux-sparse, kvm, linux-doc,
kernel-hardening
These patches make the changes necessary to build the kernel as Position
Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below
the top 2G of the virtual address space. It allows to optionally extend the
KASLR randomization range from 1G to 3G.
Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler
changes, PIE support and KASLR in general. Thanks to Roland McGrath on his
feedback for using -pie versus --emit-relocs and details on compiler code
generation.
The patches:
- 1-3, 5-1#, 17-18: Change in assembly code to be PIE compliant.
- 4: Add a new _ASM_GET_PTR macro to fetch a symbol address generically.
- 14: Adapt percpu design to work correctly when PIE is enabled.
- 15: Provide an option to default visibility to hidden except for key symbols.
It removes errors between compilation units.
- 16: Adapt relocation tool to handle PIE binary correctly.
- 19: Add support for global cookie.
- 20: Support ftrace with PIE (used on Ubuntu config).
- 21: Fix incorrect address marker on dump_pagetables.
- 22: Add option to move the module section just after the kernel.
- 23: Adapt module loading to support PIE with dynamic GOT.
- 24: Make the GOT read-only.
- 25: Add the CONFIG_X86_PIE option (off by default).
- 26: Adapt relocation tool to generate a 64-bit relocation table.
- 27: Add the CONFIG_RANDOMIZE_BASE_LARGE option to increase relocation range
from 1G to 3G (off by default).
Performance/Size impact:
Size of vmlinux (Default configuration):
File size:
- PIE disabled: +0.000031%
- PIE enabled: -3.210% (less relocations)
.text section:
- PIE disabled: +0.000644%
- PIE enabled: +0.837%
Size of vmlinux (Ubuntu configuration):
File size:
- PIE disabled: -0.201%
- PIE enabled: -0.082%
.text section:
- PIE disabled: same
- PIE enabled: +1.319%
Size of vmlinux (Default configuration + ORC):
File size:
- PIE enabled: -3.167%
.text section:
- PIE enabled: +0.814%
Size of vmlinux (Ubuntu configuration + ORC):
File size:
- PIE enabled: -3.167%
.text section:
- PIE enabled: +1.26%
The size increase is mainly due to not having access to the 32-bit signed
relocation that can be used with mcmodel=kernel. A small part is due to reduced
optimization for PIE code. This bug [1] was opened with gcc to provide a better
code generation for kernel PIE.
Hackbench (50% and 1600% on thread/process for pipe/sockets):
- PIE disabled: no significant change (avg +0.1% on latest test).
- PIE enabled: between -0.50% to +0.86% in average (default and Ubuntu config).
slab_test (average of 10 runs):
- PIE disabled: no significant change (-2% on latest run, likely noise).
- PIE enabled: between -1% and +0.8% on latest runs.
Kernbench (average of 10 Half and Optimal runs):
Elapsed Time:
- PIE disabled: no significant change (avg -0.239%)
- PIE enabled: average +0.07%
System Time:
- PIE disabled: no significant change (avg -0.277%)
- PIE enabled: average +0.7%
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303
diffstat:
Documentation/x86/x86_64/mm.txt | 3
arch/x86/Kconfig | 37 ++++
arch/x86/Makefile | 14 +
arch/x86/boot/boot.h | 2
arch/x86/boot/compressed/Makefile | 5
arch/x86/boot/compressed/misc.c | 10 +
arch/x86/crypto/aes-x86_64-asm_64.S | 45 +++--
arch/x86/crypto/aesni-intel_asm.S | 14 +
arch/x86/crypto/aesni-intel_avx-x86_64.S | 6
arch/x86/crypto/camellia-aesni-avx-asm_64.S | 42 ++---
arch/x86/crypto/camellia-aesni-avx2-asm_64.S | 44 ++---
arch/x86/crypto/camellia-x86_64-asm_64.S | 8 -
arch/x86/crypto/cast5-avx-x86_64-asm_64.S | 50 +++---
arch/x86/crypto/cast6-avx-x86_64-asm_64.S | 44 +++--
arch/x86/crypto/des3_ede-asm_64.S | 96 ++++++++----
arch/x86/crypto/ghash-clmulni-intel_asm.S | 4
arch/x86/crypto/glue_helper-asm-avx.S | 4
arch/x86/crypto/glue_helper-asm-avx2.S | 6
arch/x86/entry/entry_32.S | 3
arch/x86/entry/entry_64.S | 29 ++-
arch/x86/include/asm/asm.h | 13 +
arch/x86/include/asm/bug.h | 2
arch/x86/include/asm/ftrace.h | 23 ++-
arch/x86/include/asm/jump_label.h | 8 -
arch/x86/include/asm/kvm_host.h | 6
arch/x86/include/asm/module.h | 14 +
arch/x86/include/asm/page_64_types.h | 9 +
arch/x86/include/asm/paravirt_types.h | 12 +
arch/x86/include/asm/percpu.h | 25 ++-
arch/x86/include/asm/pgtable_64_types.h | 6
arch/x86/include/asm/pm-trace.h | 2
arch/x86/include/asm/processor.h | 12 +
arch/x86/include/asm/sections.h | 4
arch/x86/include/asm/setup.h | 2
arch/x86/include/asm/stackprotector.h | 19 +-
arch/x86/kernel/acpi/wakeup_64.S | 31 ++--
arch/x86/kernel/asm-offsets.c | 3
arch/x86/kernel/asm-offsets_32.c | 3
arch/x86/kernel/asm-offsets_64.c | 3
arch/x86/kernel/cpu/common.c | 7
arch/x86/kernel/cpu/microcode/core.c | 4
arch/x86/kernel/ftrace.c | 168 ++++++++++++++--------
arch/x86/kernel/head64.c | 32 +++-
arch/x86/kernel/head_32.S | 3
arch/x86/kernel/head_64.S | 41 ++++-
arch/x86/kernel/kvm.c | 6
arch/x86/kernel/module.c | 204 ++++++++++++++++++++++++++-
arch/x86/kernel/module.lds | 3
arch/x86/kernel/process.c | 5
arch/x86/kernel/relocate_kernel_64.S | 8 -
arch/x86/kernel/setup_percpu.c | 2
arch/x86/kernel/vmlinux.lds.S | 13 +
arch/x86/kvm/svm.c | 4
arch/x86/lib/cmpxchg16b_emu.S | 8 -
arch/x86/mm/dump_pagetables.c | 11 -
arch/x86/power/hibernate_asm_64.S | 4
arch/x86/tools/relocs.c | 170 ++++++++++++++++++++--
arch/x86/tools/relocs.h | 4
arch/x86/tools/relocs_common.c | 15 +
arch/x86/xen/xen-asm.S | 12 -
arch/x86/xen/xen-head.S | 9 -
arch/x86/xen/xen-pvh.S | 13 +
drivers/base/firmware_class.c | 4
include/asm-generic/sections.h | 6
include/asm-generic/vmlinux.lds.h | 12 +
include/linux/compiler.h | 8 +
init/Kconfig | 9 +
kernel/kallsyms.c | 16 +-
kernel/trace/trace.h | 4
lib/dynamic_debug.c | 4
70 files changed, 1109 insertions(+), 363 deletions(-)
^ permalink raw reply
* [kernel-hardening] x86: PIE support and option to extend KASLR randomization
From: Thomas Garnier @ 2017-10-04 21:19 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Thomas Gleixner, Ingo Molnar,
H . Peter Anvin, Peter Zijlstra, Josh Poimboeuf, Thomas Garnier,
Arnd Bergmann, Kees Cook, Matthias Kaehlcke, Tom Lendacky,
Andy Lutomirski, Kirill A . Shutemov, Borislav Petkov,
Rafael J . Wysocki, Len Brown, Pavel Machek, Juergen Gross,
Chris Wright, Alok Kataria, Rusty Russell, Tejun Heo,
Christoph Lameter, Boris Ostrovsky, Alexey Dobriyan,
Andrew Morton, Paul Gortmaker, Chris Metcalf, Paul E . McKenney,
Nicolas Pitre, Borislav Petkov, Luis R . Rodriguez,
Greg Kroah-Hartman, Christopher Li, Steven Rostedt, Jason Baron,
Dou Liyang, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Masahiro Yamada, Alexei Starovoitov, Daniel Borkmann,
Markus Trippelsdorf, Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Rik van Riel, David Howells, Ard Biesheuvel,
Waiman Long, Kyle Huey, Andrey Ryabinin, Jonathan Corbet,
Matthew Wilcox, Michal Hocko, Peter Foley, Paul Bolle,
Jiri Kosina, Rob Landley, H . J . Lu, Baoquan He,
Jan H . Schönherr, Daniel Micay
Cc: x86, linux-crypto, linux-kernel, linux-pm, virtualization,
xen-devel, linux-arch, linux-sparse, kvm, linux-doc,
kernel-hardening
These patches make the changes necessary to build the kernel as Position
Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below
the top 2G of the virtual address space. It allows to optionally extend the
KASLR randomization range from 1G to 3G.
Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler
changes, PIE support and KASLR in general. Thanks to Roland McGrath on his
feedback for using -pie versus --emit-relocs and details on compiler code
generation.
The patches:
- 1-3, 5-1#, 17-18: Change in assembly code to be PIE compliant.
- 4: Add a new _ASM_GET_PTR macro to fetch a symbol address generically.
- 14: Adapt percpu design to work correctly when PIE is enabled.
- 15: Provide an option to default visibility to hidden except for key symbols.
It removes errors between compilation units.
- 16: Adapt relocation tool to handle PIE binary correctly.
- 19: Add support for global cookie.
- 20: Support ftrace with PIE (used on Ubuntu config).
- 21: Fix incorrect address marker on dump_pagetables.
- 22: Add option to move the module section just after the kernel.
- 23: Adapt module loading to support PIE with dynamic GOT.
- 24: Make the GOT read-only.
- 25: Add the CONFIG_X86_PIE option (off by default).
- 26: Adapt relocation tool to generate a 64-bit relocation table.
- 27: Add the CONFIG_RANDOMIZE_BASE_LARGE option to increase relocation range
from 1G to 3G (off by default).
Performance/Size impact:
Size of vmlinux (Default configuration):
File size:
- PIE disabled: +0.000031%
- PIE enabled: -3.210% (less relocations)
.text section:
- PIE disabled: +0.000644%
- PIE enabled: +0.837%
Size of vmlinux (Ubuntu configuration):
File size:
- PIE disabled: -0.201%
- PIE enabled: -0.082%
.text section:
- PIE disabled: same
- PIE enabled: +1.319%
Size of vmlinux (Default configuration + ORC):
File size:
- PIE enabled: -3.167%
.text section:
- PIE enabled: +0.814%
Size of vmlinux (Ubuntu configuration + ORC):
File size:
- PIE enabled: -3.167%
.text section:
- PIE enabled: +1.26%
The size increase is mainly due to not having access to the 32-bit signed
relocation that can be used with mcmodel=kernel. A small part is due to reduced
optimization for PIE code. This bug [1] was opened with gcc to provide a better
code generation for kernel PIE.
Hackbench (50% and 1600% on thread/process for pipe/sockets):
- PIE disabled: no significant change (avg +0.1% on latest test).
- PIE enabled: between -0.50% to +0.86% in average (default and Ubuntu config).
slab_test (average of 10 runs):
- PIE disabled: no significant change (-2% on latest run, likely noise).
- PIE enabled: between -1% and +0.8% on latest runs.
Kernbench (average of 10 Half and Optimal runs):
Elapsed Time:
- PIE disabled: no significant change (avg -0.239%)
- PIE enabled: average +0.07%
System Time:
- PIE disabled: no significant change (avg -0.277%)
- PIE enabled: average +0.7%
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303
diffstat:
Documentation/x86/x86_64/mm.txt | 3
arch/x86/Kconfig | 37 ++++
arch/x86/Makefile | 14 +
arch/x86/boot/boot.h | 2
arch/x86/boot/compressed/Makefile | 5
arch/x86/boot/compressed/misc.c | 10 +
arch/x86/crypto/aes-x86_64-asm_64.S | 45 +++--
arch/x86/crypto/aesni-intel_asm.S | 14 +
arch/x86/crypto/aesni-intel_avx-x86_64.S | 6
arch/x86/crypto/camellia-aesni-avx-asm_64.S | 42 ++---
arch/x86/crypto/camellia-aesni-avx2-asm_64.S | 44 ++---
arch/x86/crypto/camellia-x86_64-asm_64.S | 8 -
arch/x86/crypto/cast5-avx-x86_64-asm_64.S | 50 +++---
arch/x86/crypto/cast6-avx-x86_64-asm_64.S | 44 +++--
arch/x86/crypto/des3_ede-asm_64.S | 96 ++++++++----
arch/x86/crypto/ghash-clmulni-intel_asm.S | 4
arch/x86/crypto/glue_helper-asm-avx.S | 4
arch/x86/crypto/glue_helper-asm-avx2.S | 6
arch/x86/entry/entry_32.S | 3
arch/x86/entry/entry_64.S | 29 ++-
arch/x86/include/asm/asm.h | 13 +
arch/x86/include/asm/bug.h | 2
arch/x86/include/asm/ftrace.h | 23 ++-
arch/x86/include/asm/jump_label.h | 8 -
arch/x86/include/asm/kvm_host.h | 6
arch/x86/include/asm/module.h | 14 +
arch/x86/include/asm/page_64_types.h | 9 +
arch/x86/include/asm/paravirt_types.h | 12 +
arch/x86/include/asm/percpu.h | 25 ++-
arch/x86/include/asm/pgtable_64_types.h | 6
arch/x86/include/asm/pm-trace.h | 2
arch/x86/include/asm/processor.h | 12 +
arch/x86/include/asm/sections.h | 4
arch/x86/include/asm/setup.h | 2
arch/x86/include/asm/stackprotector.h | 19 +-
arch/x86/kernel/acpi/wakeup_64.S | 31 ++--
arch/x86/kernel/asm-offsets.c | 3
arch/x86/kernel/asm-offsets_32.c | 3
arch/x86/kernel/asm-offsets_64.c | 3
arch/x86/kernel/cpu/common.c | 7
arch/x86/kernel/cpu/microcode/core.c | 4
arch/x86/kernel/ftrace.c | 168 ++++++++++++++--------
arch/x86/kernel/head64.c | 32 +++-
arch/x86/kernel/head_32.S | 3
arch/x86/kernel/head_64.S | 41 ++++-
arch/x86/kernel/kvm.c | 6
arch/x86/kernel/module.c | 204 ++++++++++++++++++++++++++-
arch/x86/kernel/module.lds | 3
arch/x86/kernel/process.c | 5
arch/x86/kernel/relocate_kernel_64.S | 8 -
arch/x86/kernel/setup_percpu.c | 2
arch/x86/kernel/vmlinux.lds.S | 13 +
arch/x86/kvm/svm.c | 4
arch/x86/lib/cmpxchg16b_emu.S | 8 -
arch/x86/mm/dump_pagetables.c | 11 -
arch/x86/power/hibernate_asm_64.S | 4
arch/x86/tools/relocs.c | 170 ++++++++++++++++++++--
arch/x86/tools/relocs.h | 4
arch/x86/tools/relocs_common.c | 15 +
arch/x86/xen/xen-asm.S | 12 -
arch/x86/xen/xen-head.S | 9 -
arch/x86/xen/xen-pvh.S | 13 +
drivers/base/firmware_class.c | 4
include/asm-generic/sections.h | 6
include/asm-generic/vmlinux.lds.h | 12 +
include/linux/compiler.h | 8 +
init/Kconfig | 9 +
kernel/kallsyms.c | 16 +-
kernel/trace/trace.h | 4
lib/dynamic_debug.c | 4
70 files changed, 1109 insertions(+), 363 deletions(-)
^ permalink raw reply
* [PATCH v2 3/5] clk: aspeed: Add platform driver and register PLLs
From: Stephen Boyd @ 2017-10-04 21:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACPK8XeHj2xdw6HgkWRDiJPjurip3wVbkOmY0mGW=dSTVWsYmg@mail.gmail.com>
On 10/03, Joel Stanley wrote:
> On Tue, Oct 3, 2017 at 6:54 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> > On 09/21, Joel Stanley wrote:
> >> @@ -160,6 +191,104 @@ static struct clk_hw *aspeed_calc_pll(const char *name, u32 val)
> >> + /*
> >> + * Memory controller (M-PLL) PLL. This clock is configured by the
> >> + * bootloader, and is exposed to Linux as a read-only clock rate.
> >> + */
> >> + regmap_read(map, ASPEED_MPLL_PARAM, &val);
> >> + aspeed_clk_data->hws[ASPEED_CLK_MPLL] = aspeed_calc_pll("mpll", val);
> >> +
> >> + /* SD/SDIO clock divider (TODO: There's a gate too) */
> >> + hw = clk_hw_register_divider_table(NULL, "sdio", "hpll", 0,
> >
> > Please pass your dev pointer here from the platform device.
> >
> >> + scu_base + ASPEED_CLK_SELECTION, 12, 3, 0,
> >> + div_table,
> >> + &aspeed_clk_lock);
> >
> > And check for errors? Perhaps use devm_clk_hw_regsiter() APIs and
> > construct the dividers and muxes directly instead of using the
> > basic type registration APIs.
>
> Do you think that devm_ is overkill, given we will never unload this driver?
Is probe defer going to happen? Even if unload can't happen,
probe defer is a concern unless that is also ruled out.
>
> Can you explain why you suggest to construct the structures directly
> instead of using the APIs?
There aren't devm APIs for some of these basic clk type
registration functions.
>
> I had a read of the basic type registration functions, and the
> relevant failure paths are memory allocation failures. If we're out of
> memory that early in boot then things have gone pretty bad.
>
> I can add checks for null and bail out; I don't think there's value in
> freeing the allocated memory: if a system can't load it's clock driver
> then it's super hosed.
If we can't proceed without this driver because it's super hosed,
then perhaps we need to panic the system on errors here. Should
be simple enough to add some error checks and goto panic("Things
are super hosed").
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2 3/5] clk: aspeed: Add platform driver and register PLLs
From: Stephen Boyd @ 2017-10-04 21:18 UTC (permalink / raw)
To: Joel Stanley
Cc: Lee Jones, Michael Turquette, Linux Kernel Mailing List,
linux-clk, Linux ARM, Andrew Jeffery, Benjamin Herrenschmidt,
Jeremy Kerr, Rick Altherr, Ryan Chen, Arnd Bergmann
In-Reply-To: <CACPK8XeHj2xdw6HgkWRDiJPjurip3wVbkOmY0mGW=dSTVWsYmg@mail.gmail.com>
On 10/03, Joel Stanley wrote:
> On Tue, Oct 3, 2017 at 6:54 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> > On 09/21, Joel Stanley wrote:
> >> @@ -160,6 +191,104 @@ static struct clk_hw *aspeed_calc_pll(const char *name, u32 val)
> >> + /*
> >> + * Memory controller (M-PLL) PLL. This clock is configured by the
> >> + * bootloader, and is exposed to Linux as a read-only clock rate.
> >> + */
> >> + regmap_read(map, ASPEED_MPLL_PARAM, &val);
> >> + aspeed_clk_data->hws[ASPEED_CLK_MPLL] = aspeed_calc_pll("mpll", val);
> >> +
> >> + /* SD/SDIO clock divider (TODO: There's a gate too) */
> >> + hw = clk_hw_register_divider_table(NULL, "sdio", "hpll", 0,
> >
> > Please pass your dev pointer here from the platform device.
> >
> >> + scu_base + ASPEED_CLK_SELECTION, 12, 3, 0,
> >> + div_table,
> >> + &aspeed_clk_lock);
> >
> > And check for errors? Perhaps use devm_clk_hw_regsiter() APIs and
> > construct the dividers and muxes directly instead of using the
> > basic type registration APIs.
>
> Do you think that devm_ is overkill, given we will never unload this driver?
Is probe defer going to happen? Even if unload can't happen,
probe defer is a concern unless that is also ruled out.
>
> Can you explain why you suggest to construct the structures directly
> instead of using the APIs?
There aren't devm APIs for some of these basic clk type
registration functions.
>
> I had a read of the basic type registration functions, and the
> relevant failure paths are memory allocation failures. If we're out of
> memory that early in boot then things have gone pretty bad.
>
> I can add checks for null and bail out; I don't think there's value in
> freeing the allocated memory: if a system can't load it's clock driver
> then it's super hosed.
If we can't proceed without this driver because it's super hosed,
then perhaps we need to panic the system on errors here. Should
be simple enough to add some error checks and goto panic("Things
are super hosed").
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v6 2/2] media: rc: Add driver for tango HW IR decoder
From: Sean Young @ 2017-10-04 21:18 UTC (permalink / raw)
To: Marc Gonzalez; +Cc: Mans Rullgard, linux-media, Mason
In-Reply-To: <3dc97914-048f-e932-c05d-211b5111eb84@sigmadesigns.com>
On Wed, Oct 04, 2017 at 06:00:47PM +0200, Marc Gonzalez wrote:
> On 26/09/2017 10:51, Marc Gonzalez wrote:
>
> > From: Mans Rullgard <mans@mansr.com>
> >
> > The tango HW IR decoder supports NEC, RC-5, RC-6 protocols.
> >
> > Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
> > ---
> > Changes between v5 and v6
> > * Move "register fields" macros to top of file
> > * Restore IRQ pending writes
> > ---
> > drivers/media/rc/Kconfig | 10 ++
> > drivers/media/rc/Makefile | 1 +
> > drivers/media/rc/tango-ir.c | 279 ++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 290 insertions(+)
> > create mode 100644 drivers/media/rc/tango-ir.c
>
> Hello Sean,
>
> Are there issues remaining before this series can be accepted upstream?
>
> Are you waiting for the DT folks to review the DT binding?
I am waiting for that review.
> Can I submit a keymap patch on top of the series?
Of course. Or you could post v7 with a keymap.
Thanks
Sean
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v6 6/6] tests: Add check-qobject for equality tests
From: Eric Blake @ 2017-10-04 21:18 UTC (permalink / raw)
To: Max Reitz, qemu-block; +Cc: qemu-devel, Markus Armbruster, Kevin Wolf
In-Reply-To: <20171004152553.30263-7-mreitz@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 702 bytes --]
On 10/04/2017 10:25 AM, Max Reitz wrote:
> Add a new test file (check-qobject.c) for unit tests that concern
> QObjects as a whole.
>
> Its only purpose for now is to test the qobject_is_equal() function.
>
> Signed-off-by: Max Reitz <mreitz@redhat.com>
> ---
> tests/Makefile.include | 4 +-
> tests/check-qobject.c | 325 +++++++++++++++++++++++++++++++++++++++++++++++++
> tests/.gitignore | 1 +
> 3 files changed, 329 insertions(+), 1 deletion(-)
> create mode 100644 tests/check-qobject.c
Reviewed-by: Eric Blake <eblake@redhat.com>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]
^ permalink raw reply
* Re: Linux Plumbers MD BOF discussion notes
From: Phil Turmel @ 2017-10-04 21:18 UTC (permalink / raw)
To: Artur Paszkiewicz, NeilBrown, Mikael Abrahamsson; +Cc: linux-raid
In-Reply-To: <076977d4-dfae-e8d3-7606-29e838f422ec@intel.com>
On 10/04/2017 07:23 AM, Artur Paszkiewicz wrote:
> On 10/04/2017 01:02 PM, Artur Paszkiewicz wrote:
>> Applications like mdadm can use this to hide/unhide their component
>> devices.
>
> And here is an example patch for mdadm. It adds options to manually hide
> or unhide the component devices:
>
> mdadm --hide-components /dev/md0
> mdadm --unhide-components /dev/md0
>
> And an option for mdadm.conf that automatically hides the array's member
> disks when assembling and when new disks are added:
>
> ARRAY /dev/md/0 metadata=1.2 UUID=c2c4f8c6:cd775924:9cb2cc62:88fa45bd
> name=linux-ns31:0 hide-components=yes
>
> Hidden disks (by mdadm --hide-components or by config) should unhide
> when the array is stopped or disks are removed. It only works for whole
> devices, not partitions.
I am not at all in favor of these patches, as they break all kinds of
diagnostic tooling and certainly violate the principle of least
surprise. Tools like "lsblk --tree" and my own "lsdrv" [1].
Please keep these out of the kernel, or better yet, explain to your
customers that visibility into the components is a key *advantage*
of software raid.
Regards,
Phil Turmel
[1] https://github.com/pturmel/lsdrv
^ permalink raw reply
* Re: Line ending normalization doesn't work as expected
From: Torsten Bögershausen @ 2017-10-04 21:17 UTC (permalink / raw)
To: Robert Dailey; +Cc: Junio C Hamano, Git
In-Reply-To: <CAHd499BCMOcur6NRbKfwd81zpnyzoiVCY54d=UmGpAhbD7AVTA@mail.gmail.com>
On Wed, Oct 04, 2017 at 11:26:55AM -0500, Robert Dailey wrote:
> On Tue, Oct 3, 2017 at 9:00 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Torsten Bögershausen <tboegi@web.de> writes:
> >
> >>> $ git rm -r --cached . && git add .
> >>
> >> (Both should work)
> >>
> >> To be honest, from the documentation, I can't figure out the difference between
> >> $ git read-tree --empty
> >> and
> >> $ git rm -r --cached .
> >>
> >> Does anybody remember the discussion, why we ended up with read-tree ?
> >
> > We used to use neither, and considered it fine to "rm .git/index" if
> > you wanted to empty the on-disk index file in the old world. In the
> > modern world, folks want you to avoid touching filesystem directly
> > and instead want you to use Git tools, and the above are two obvious
> > ways to do so.
> >
> > "git read-tree" (without any parameter, i.e. "read these 0 trees and
> > populate the index with it") and its modern and preferred synonym
> > "git read-tree --empty" (i.e. "I am giving 0 trees and I know the
> > sole effect of this command is to empty the index.") are more direct
> > ways to express "I want the index emptied" between the two.
> >
> > The other one, "git rm -r --cached .", in the end gives you the same
> > state because it tells Git to "iterate over all the entries in the
> > index, find the ones that match pathspec '.', and remove them from
> > the index.". It is not wrong per-se, but conceptually it is a bit
> > roundabout way to say that "I want the index emptied", I would
> > think.
> >
> > I wouldn't be surprised if the "rm -r --cached ." were a lot slower,
> > due to the overhead of having to do the pathspec filtering that ends
> > up to be a no-op, but there shouldn't be a difference in the end
> > result.
>
> You guys are obviously worlds ahead of me on the internals of things,
> but from my perspective I like to avoid the "plumbing" commands as
> much as I can. Even if I used them, if I have to tell the rest of my
> team "this is the way to do it", they're going to give me dirty looks
> if I ask them to run things like this that make no sense to them.
> That's the argument I have to deal with when it comes to Git's
> usability within the team I manage. So based on this, I'd favor the
> `git rm -r --cached` approach because this is the more common result
> you see in Google, and also makes a little more sense from a high
> level of thought perspective. However, this is just my personal
> opinion. `read-tree --empty` is far less self explanatory IMHO.
>
> Also let's not forget the second part of the command chain that
> results in the different behavior. In one case, I use `git add` which
> results in proper line ending normalization. In the other case, I do
> `git reset --hard` which does *NOT* result in the line endings
> normalized (`git status` shows no results). In both cases, I'm still
> doing `git rm -r --cached`, so I am doubtful that is the root cause
> for the line ending normalization piece. I'm still trying to
> understand why both give different results (root cause) and also get
> an understanding of what the correct (modern) solution is for line
> ending normalization (not necessarily which is the right way to
> clear/delete the index, which is really AFAIK just a means to this end
> and an implementation detail of sorts for this specific task).
Hopefully I am able to give a useful answer.
"git reset --hard" works like a hammer
and may destroy work that has been done,
in our case the cleaning of the index,
which is needed for normalization since Git 2.10 (or so)
Back to the question:
One solution, which you can tell your team, is this one:
$ git rm -r --cached . && git add .
And as Junio pointed out, this may be slower than needed.
And we don't want "slow" solutions in the official documentation ;-)
Whatever you find on search engines may get stale after a while,
so that we appreciate direct questions here.
(And I will open an issue on Github the next days)
The background is that the CRLF handling in Git changed over the years,
and one effect is that "git reset" is not "allowed" any more.
For the interested reader:
https://github.com/git-for-windows/git/issues/954
^ permalink raw reply
* Re: [PATCH] firmware: add firmware to new device's devres list for second time cache
From: Luis R. Rodriguez @ 2017-10-04 21:17 UTC (permalink / raw)
To: Kai-Heng Feng; +Cc: mcgrof, gregkh, linux-kernel
In-Reply-To: <20170822075246.16315-1-kai.heng.feng@canonical.com>
On Tue, Aug 22, 2017 at 03:52:46PM +0800, Kai-Heng Feng wrote:
> Currently, firmware will only be chached if assign_firmware_buf() gets
> called.
True, but also more importantly we peg the fw cache to the device via devres
*iff* the firmware actually was found. We do this so that we don't try to look
for bogus firmwares or firmwares which we currently do not have on our
filesystem (consider a driver that uses a series of revisions of firmwares).
> When a device loses its power or a USB device gets plugged to another
> port under suspend, request_firmware() can still find cached firmware,
> but firmware name no longer associates with the new device's devres.
> So next time the system suspend, those firmware won't be cached.
Gah, its a bit more complicated than that. During suspend we call out to
request firmware proactively for all firmwares in our fw cache. The
fw cache is used simply to fetch the caches for firwmares during suspend
so that on resume they exist to avoid races against the filesystem. It
however uses the same functionality as the batched firwmare feature, which
in turn is used to share one buf over different requests.
If a device is unplugged its not clear to me why the old cache would
not work for the new one as its all shared, so the only thing that I
can think of is if the old device being disconnected is processed first,
and therefore releases the old cache, so when the new device is processed
it does not use the new cache. This should still not be an issue though,
unless of course real races happen with the filesystem.
As of recently though we have had new findings which indicate that the
old UMH lock was causing issues on resume on BT devices which *only*
needed firmware on resume, but not on boot, so their first fw cache
was not generated. That issue can resemble this one, in that no cache
can be present, and a race happens on resume.
The old UMH lock then was causing a failure on resume, and one of the
solutions which could have worked was a proactive "hey set this cache
up for me" even though the device didn't need the firmware. This
is no longer needed given that the UMH lock stuff is gone from
direct FS lookups and the issue should no longer be present.
That is, Linus' revert of commit f007cad159e99fa2acd3b2e9364fbb32ad28b971
("Revert "firmware: add sanity check on shutdown/suspend") I believe
should fix this issue.
I'm actually inclined to remove the fw cache stuff as I no longer see
the advantage of it given we are doing FS lookups and I see no races
possible anymore.
> Hence, we should add the firmware name to the devres when the firmware
> is found in cache, to make the firmware cacheable next time.
>
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> ---
> drivers/base/firmware_class.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index bfbe1e154128..a99de34e3fdc 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -1177,6 +1177,10 @@ _request_firmware_prepare(struct firmware **firmware_p, const char *name,
>
> ret = fw_lookup_and_allocate_buf(name, &fw_cache, &buf, dbuf, size);
>
> + /* device might be a new one, add it to devres list */
> + if (ret == 0 || ret == 1)
> + fw_add_devm_name(device, name);
> +
Even if this was correct notice we have requests for which a FW cache is not
desired -- see FW_OPT_NOCACHE, and the above does not respect it.
Given all the above, can you test with a kernel which has
commit f007cad159e99fa2acd3b2e9364fbb32ad28b971 and tell me if you
still see the issue?
Luis
^ permalink raw reply
* ✗ Fi.CI.IGT: failure for series starting with [v2,1/2] drm/i915/edp: Get the Panel Power Off timestamp after panel is off (rev2)
From: Patchwork @ 2017-10-04 21:15 UTC (permalink / raw)
To: Manasi Navare; +Cc: intel-gfx
In-Reply-To: <1507073845-13420-1-git-send-email-manasi.d.navare@intel.com>
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/edp: Get the Panel Power Off timestamp after panel is off (rev2)
URL : https://patchwork.freedesktop.org/series/31361/
State : failure
== Summary ==
Test gem_flink_race:
Subgroup flink_close:
fail -> PASS (shard-hsw) fdo#102655
Test kms_atomic_transition:
Subgroup plane-all-transition-nonblocking-fencing:
pass -> FAIL (shard-hsw)
fdo#102655 https://bugs.freedesktop.org/show_bug.cgi?id=102655
shard-hsw total:2430 pass:1330 dwarn:7 dfail:0 fail:9 skip:1084 time:10151s
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5901/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: Yocto 2.3 - Pyro release for FSL boards
From: Otavio Salvador @ 2017-10-04 21:14 UTC (permalink / raw)
To: K, Ganesan (GE Healthcare); +Cc: meta-freescale@yoctoproject.org
In-Reply-To: <PS1P101MB00595681783878798D0171BF83730@PS1P101MB0059.NAMP101.PROD.OUTLOOK.COM>
On Wed, Oct 4, 2017 at 9:16 AM, K, Ganesan (GE Healthcare)
<ganesan.k@ge.com> wrote:
> What is the planned release date for Yocto 2.3 – Pyro for FSL boards?
It is available for use now. We just did not make a formal release
announcement as we did not got the docs finished.
For new development, use rocko as it is going to be official really soon...
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply
* Re: [PATCH 2/4] media: dt-bindings: Add bindings for TDA1997X
From: Rob Herring @ 2017-10-04 21:14 UTC (permalink / raw)
To: Tim Harvey
Cc: linux-media, devicetree, linux-kernel, shawnguo, Steve Longerbeam,
Philipp Zabel, Hans Verkuil, Mauro Carvalho Chehab
In-Reply-To: <1506119053-21828-3-git-send-email-tharvey@gateworks.com>
On Fri, Sep 22, 2017 at 03:24:11PM -0700, Tim Harvey wrote:
> Signed-off-by: Tim Harvey <tharvey@gateworks.com>
You need a commit msg. Otherwise, maintainers get publicly shamed.
> ---
> .../devicetree/bindings/media/i2c/tda1997x.txt | 159 +++++++++++++++++++++
> 1 file changed, 159 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/tda1997x.txt b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
> new file mode 100644
> index 0000000..8330733
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
> @@ -0,0 +1,159 @@
> +Device-Tree bindings for the NXP TDA1997x HDMI receiver
> +
> +The TDA19971/73 are HDMI video receivers.
> +
> +The TDA19971 Video port output pins can be used as follows:
> + - RGB 8bit per color (24 bits total): R[11:4] B[11:4] G[11:4]
> + - YUV444 8bit per color (24 bits total): Y[11:4] Cr[11:4] Cb[11:4]
> + - YUV422 semi-planar 8bit per component (16 bits total): Y[11:4] CbCr[11:4]
> + - YUV422 semi-planar 10bit per component (20 bits total): Y[11:2] CbCr[11:2]
> + - YUV422 semi-planar 12bit per component (24 bits total): - Y[11:0] CbCr[11:0]
> + - YUV422 BT656 8bit per component (8 bits total): YCbCr[11:4] (2-cycles)
> + - YUV422 BT656 10bit per component (10 bits total): YCbCr[11:2] (2-cycles)
> + - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
> +
> +The TDA19973 Video port output pins can be used as follows:
> + - RGB 12bit per color (36 bits total): R[11:0] B[11:0] G[11:0]
> + - YUV444 12bit per color (36 bits total): Y[11:0] Cb[11:0] Cr[11:0]
> + - YUV422 semi-planar 12bit per component (24 bits total): Y[11:0] CbCr[11:0]
> + - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
> +
> +The Video port output pins are mapped via 4-bit 'pin groups' allowing
> +for a variety fo connection possibilities including swapping pin order within
> +pin groups. The video_portcfg device-tree property consists of register mapping
> +pairs which map a chip-specific VP output register to a 4-bit pin group. If
> +the pin group needs to be bit-swapped you can use the *_S pin-group defines.
> +
> +Required Properties:
> + - compatible :
> + - "nxp,tda19971" for the TDA19971
> + - "nxp,tda19973" for the TDA19973
> + - reg : I2C slave address
> + - interrupts : The interrupt number
> + - DOVDD-supply : Digital I/O supply
> + - DVDD-supply : Digital Core supply
> + - AVDD-supply : Analog supply
> + - vidout_portcfg : array of pairs mapping VP output pins to pin groups
Needs a vendor prefix and don't use '_'.
> +
> +Optional Properties:
> + - max-pixel-rate : Maximum pixel rate supported by the SoC (MP/sec)
> + - audio-port : parameters defining audio output port connection
That description is meaningless to me.
> +
> +Optional Endpoint Properties:
> + The following three properties are defined in video-interfaces.txt and
> + are valid for source endpoints only:
> + - hsync-active: Horizontal synchronization polarity. Defaults to active high.
> + - vsync-active: Vertical synchronization polarity. Defaults to active high.
> + - data-active: Data polarity. Defaults to active high.
> +
> +The Audio output port consists of A_CLK, A_WS, AP0, AP1, AP2, and AP3 pins
> +and can support up to 8-chanenl audio using the following audio bus DAI formats:
> + - I2S16
> + - I2S32
> + - SPDIF
> + - OBA (One-Bit-Audio)
> + - I2S16_HBR_STRAIGHT (High Bitrate straight through)
> + - I2S16_HBR_DEMUX (High Bitrate demuxed)
> + - I2S32_HBR_DEMUX (High Bitrate demuxed)
> + - DST (Direct Stream Transfer)
This either should be a standard, common property or not be in DT.
Practically every system is going to have at least one end of the
connection that is configurable. The kernel should be able to get lists
of supported modes and pick one.
> +
> +Audio samples can be output in either SPDIF or I2S bus formats.
> +In I2S mode, the TDF1997X is the master with 16bit or 32bit words.
> +The audio port output is configured by three parameters: DAI format, layout
> +and clock scaler.
> +
> +Each DAI format has two pin layouts shown by the following table:
> + | SPDIF | SPDIF | I2S | I2S | HBR demux
> + | Layout0 | Layout1 | Layout0 | Layout1 | SPDIF | I2S
> + ------+---------+---------+---------+---------+------------+------------
> + A_WS | WS | WS | WS | WS | WS | WS
> + AP3 | | SPDIF3 | | SD3 | SPDIF[x+3] | SD[x+3]
> + AP2 | | SPDIF2 | | SD2 | SPDIF[x+2] | SD[x+2]
> + AP1 | | SPDIF1 | | SD1 | SPDIF[x+1] | SD[x+1]
> + AP0 | SPDIF | SPDIF0 | SD | SD0 | SPDIF[x] | SD[x]
> + A_CLK | (32*Fs) | (32*Fs) |(32*Fs) | (32*Fs) | (32*Fs) | (32*Fs)
> + | (64*Fs) | (64*Fs) |(64*Fs) | (64*Fs) | (64*Fs) | (64*Fs)
> +
> +Freq(Sysclk) = 2*freq(Aclk)
> +
> +Examples:
> + - VP[15:0] connected to IMX6 CSI_DATA[19:4] for 16bit YUV422
> + 16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins)
> + hdmi_receiver@48 {
s/_/-/
> + compatible = "nxp,tda19971";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_tda1997x>;
> + reg = <0x48>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
> + DOVDD-supply = <®_3p3v>;
> + AVDD-supply = <®_1p8v>;
> + DVDD-supply = <®_1p8v>;
> + /* audio output format */
> + audio-port = < TDA1997X_I2S16
> + TDA1997X_LAYOUT0
> + TDA1997X_ACLK_128FS >;
> + /*
> + * The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
> + * and Y[11:4] across 16bits in the same pixclk cycle.
> + */
> + vidout_portcfg =
> + /* Y[11:8]<->VP[15:12]<->CSI_DATA[19:16] */
> + < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
> + /* Y[7:4]<->VP[11:08]<->CSI_DATA[15:12] */
> + < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
> + /* CbCc[11:8]<->VP[07:04]<->CSI_DATA[11:8] */
> + < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
> + /* CbCr[7:4]<->VP[03:00]<->CSI_DATA[7:4] */
> + < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
> + max-pixel-rate = <180>; /* IMX6 CSI max pixel rate 180MP/sec */
That's a constraint that belongs in the i.MX CSI node or driver.
> +
> + port@0 {
> + reg = <0>;
> + };
> + port@1 {
You need to describe how many ports and what they are.
> + reg = <1>;
> + hdmi_in: endpoint {
> + remote-endpoint = <&ccdc_in>;
> + };
> + };
> + };
> + - VP[15:8] connected to IMX6 CSI_DATA[19:12] for 8bit BT656
> + 16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins)
Do you really need 2 examples? It should be possible to figure out other
configurations with better descriptions above.
> + hdmi_receiver@48 {
> + compatible = "nxp,tda19971";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_tda1997x>;
> + reg = <0x48>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
> + DOVDD-supply = <®_3p3v>;
> + AVDD-supply = <®_1p8v>;
> + DVDD-supply = <®_1p8v>;
> + /* audio output format */
> + #sound-dai-cells = <0>;
> + audio-port = < TDA1997X_I2S16
> + TDA1997X_LAYOUT0
> + TDA1997X_ACLK_128FS >;
> + /*
> + * The 8bpp BT656 mode outputs YCbCr[11:4] across 8bits over
> + * 2 pixclk cycles.
> + */
> + vidout_portcfg =
> + /* YCbCr[11:8]<->VP[15:12]<->CSI_DATA[19:16] */
> + < TDA1997X_VP24_V15_12 TDA1997X_R_CR_CBCR_11_8 >,
> + /* YCbCr[7:4]<->VP[11:08]<->CSI_DATA[15:12] */
> + < TDA1997X_VP24_V11_08 TDA1997X_R_CR_CBCR_7_4 >,
> + max-pixel-rate = <180>; /* IMX6 CSI max pixel rate 180MP/sec */
> +
> + port@0 {
> + reg = <0>;
> + };
> + port@1 {
> + reg = <1>;
> + hdmi_in: endpoint {
> + remote-endpoint = <&ccdc_in>;
> + };
> + };
> + };
> +
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v8 2/2] btrfs: check device for critical errors and mark failed
From: Liu Bo @ 2017-10-04 20:11 UTC (permalink / raw)
To: Anand Jain; +Cc: linux-btrfs
In-Reply-To: <20171003155920.24925-3-anand.jain@oracle.com>
On Tue, Oct 03, 2017 at 11:59:20PM +0800, Anand Jain wrote:
> From: Anand Jain <Anand.Jain@oracle.com>
>
> Write and flush errors are critical errors, upon which the device fd
> must be closed and marked as failed.
>
Can we defer the job of closing device to umount?
We can go mark the device failed and skip it while doing read/write,
and umount can do the cleanup work.
That way we don't need a dedicated thread looping around to detect a
rare situation.
Thanks,
-liubo
> There are two type of device close in btrfs, one, close as part
> of clean up where we shall release the struct btrfs_device and
> or btrfs_fs_devices as well. And the other type which is introduced
> here is where we close the device fd for the reason that it has failed
> and the mounted FS is still present using the other redundant device.
> In this new case we shall keep the failed device's struct btrfs_device
> similar to missing device.
>
> Further the approach here is to monitor the device statistics and
> trigger the action based on one or more device state.
>
> Signed-off-by: Anand Jain <anand.jain@oracle.com>
> Tested-by: Austin S. Hemmelgarn <ahferroin7@gmail.com>
> ---
> V8: General misc cleanup. Based on v4.14-rc2
>
> fs/btrfs/ctree.h | 2 ++
> fs/btrfs/disk-io.c | 78 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
> fs/btrfs/volumes.c | 1 +
> fs/btrfs/volumes.h | 4 +++
> 4 files changed, 84 insertions(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
> index 5a8933da39a7..bad8fbaff18d 100644
> --- a/fs/btrfs/ctree.h
> +++ b/fs/btrfs/ctree.h
> @@ -824,6 +824,7 @@ struct btrfs_fs_info {
> struct mutex tree_log_mutex;
> struct mutex transaction_kthread_mutex;
> struct mutex cleaner_mutex;
> + struct mutex health_mutex;
> struct mutex chunk_mutex;
> struct mutex volume_mutex;
>
> @@ -941,6 +942,7 @@ struct btrfs_fs_info {
> struct btrfs_workqueue *extent_workers;
> struct task_struct *transaction_kthread;
> struct task_struct *cleaner_kthread;
> + struct task_struct *health_kthread;
> int thread_pool_size;
>
> struct kobject *space_info_kobj;
> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
> index 487bbe4fb3c6..be22104bafbf 100644
> --- a/fs/btrfs/disk-io.c
> +++ b/fs/btrfs/disk-io.c
> @@ -1922,6 +1922,70 @@ static int cleaner_kthread(void *arg)
> return 0;
> }
>
> +static void btrfs_check_device_fatal_errors(struct btrfs_root *root)
> +{
> + struct btrfs_device *device;
> + struct btrfs_fs_info *fs_info = root->fs_info;
> +
> + /* Mark devices with write or flush errors as failed. */
> + mutex_lock(&fs_info->volume_mutex);
> + list_for_each_entry_rcu(device,
> + &fs_info->fs_devices->devices, dev_list) {
> + int c_err;
> +
> + if (device->failed)
> + continue;
> +
> + /* Todo: Skip replace target for now. */
> + if (device->is_tgtdev_for_dev_replace)
> + continue;
> + if (!device->dev_stats_valid)
> + continue;
> +
> + c_err = atomic_read(&device->new_critical_errs);
> + atomic_sub(c_err, &device->new_critical_errs);
> + if (c_err) {
> + btrfs_crit_in_rcu(fs_info,
> + "%s: Fatal write/flush error",
> + rcu_str_deref(device->name));
> + btrfs_mark_device_failed(device);
> + }
> + }
> + mutex_unlock(&fs_info->volume_mutex);
> +}
> +
> +static int health_kthread(void *arg)
> +{
> + struct btrfs_root *root = arg;
> +
> + do {
> + /* Todo rename the below function */
> + if (btrfs_need_cleaner_sleep(root->fs_info))
> + goto sleep;
> +
> + if (!mutex_trylock(&root->fs_info->health_mutex))
> + goto sleep;
> +
> + if (btrfs_need_cleaner_sleep(root->fs_info)) {
> + mutex_unlock(&root->fs_info->health_mutex);
> + goto sleep;
> + }
> +
> + /* Check devices health */
> + btrfs_check_device_fatal_errors(root);
> +
> + mutex_unlock(&root->fs_info->health_mutex);
> +
> +sleep:
> + set_current_state(TASK_INTERRUPTIBLE);
> + if (!kthread_should_stop())
> + schedule();
> + __set_current_state(TASK_RUNNING);
> + } while (!kthread_should_stop());
> +
> + return 0;
> +}
> +
> static int transaction_kthread(void *arg)
> {
> struct btrfs_root *root = arg;
> @@ -1969,6 +2033,7 @@ static int transaction_kthread(void *arg)
> btrfs_end_transaction(trans);
> }
> sleep:
> + wake_up_process(fs_info->health_kthread);
> wake_up_process(fs_info->cleaner_kthread);
> mutex_unlock(&fs_info->transaction_kthread_mutex);
>
> @@ -2713,6 +2778,7 @@ int open_ctree(struct super_block *sb,
> mutex_init(&fs_info->chunk_mutex);
> mutex_init(&fs_info->transaction_kthread_mutex);
> mutex_init(&fs_info->cleaner_mutex);
> + mutex_init(&fs_info->health_mutex);
> mutex_init(&fs_info->volume_mutex);
> mutex_init(&fs_info->ro_block_group_mutex);
> init_rwsem(&fs_info->commit_root_sem);
> @@ -3049,11 +3115,16 @@ int open_ctree(struct super_block *sb,
> if (IS_ERR(fs_info->cleaner_kthread))
> goto fail_sysfs;
>
> + fs_info->health_kthread = kthread_run(health_kthread, tree_root,
> + "btrfs-health");
> + if (IS_ERR(fs_info->health_kthread))
> + goto fail_cleaner;
> +
> fs_info->transaction_kthread = kthread_run(transaction_kthread,
> tree_root,
> "btrfs-transaction");
> if (IS_ERR(fs_info->transaction_kthread))
> - goto fail_cleaner;
> + goto fail_health;
>
> if (!btrfs_test_opt(fs_info, NOSSD) &&
> !fs_info->fs_devices->rotating) {
> @@ -3222,6 +3293,10 @@ int open_ctree(struct super_block *sb,
> kthread_stop(fs_info->transaction_kthread);
> btrfs_cleanup_transaction(fs_info);
> btrfs_free_fs_roots(fs_info);
> +
> +fail_health:
> + kthread_stop(fs_info->health_kthread);
> +
> fail_cleaner:
> kthread_stop(fs_info->cleaner_kthread);
>
> @@ -3896,6 +3971,7 @@ void close_ctree(struct btrfs_fs_info *fs_info)
>
> kthread_stop(fs_info->transaction_kthread);
> kthread_stop(fs_info->cleaner_kthread);
> + kthread_stop(fs_info->health_kthread);
>
> set_bit(BTRFS_FS_CLOSING_DONE, &fs_info->flags);
>
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index 06e7cf4cef81..18dabd0364bf 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -247,6 +247,7 @@ static struct btrfs_device *__alloc_device(void)
> spin_lock_init(&dev->reada_lock);
> atomic_set(&dev->reada_in_flight, 0);
> atomic_set(&dev->dev_stats_ccnt, 0);
> + atomic_set(&dev->new_critical_errs, 0);
> btrfs_device_data_ordered_init(dev);
> INIT_RADIX_TREE(&dev->reada_zones, GFP_NOFS & ~__GFP_DIRECT_RECLAIM);
> INIT_RADIX_TREE(&dev->reada_extents, GFP_NOFS & ~__GFP_DIRECT_RECLAIM);
> diff --git a/fs/btrfs/volumes.h b/fs/btrfs/volumes.h
> index 05b150c03995..9328a5d12e78 100644
> --- a/fs/btrfs/volumes.h
> +++ b/fs/btrfs/volumes.h
> @@ -163,6 +163,7 @@ struct btrfs_device {
> /* Counter to record the change of device stats */
> atomic_t dev_stats_ccnt;
> atomic_t dev_stat_values[BTRFS_DEV_STAT_VALUES_MAX];
> + atomic_t new_critical_errs;
> };
>
> /*
> @@ -513,6 +514,9 @@ static inline void btrfs_dev_stat_inc(struct btrfs_device *dev,
> atomic_inc(dev->dev_stat_values + index);
> smp_mb__before_atomic();
> atomic_inc(&dev->dev_stats_ccnt);
> + if (index == BTRFS_DEV_STAT_WRITE_ERRS ||
> + index == BTRFS_DEV_STAT_FLUSH_ERRS)
> + atomic_inc(&dev->new_critical_errs);
> }
>
> static inline int btrfs_dev_stat_read(struct btrfs_device *dev,
> --
> 2.7.0
>
^ permalink raw reply
* [PATCH] glibc-locale.inc: fix typo in comment
From: Gianfranco Costamagna @ 2017-10-04 21:12 UTC (permalink / raw)
To: openembedded-core; +Cc: Gianfranco Costamagna, Lorenzo Chianura
Signed-off-by: Gianfranco Costamagna <gianfranco.costamagna@abinsula.com>
Signed-off-by: Lorenzo Chianura <lorenzo.chianura@abinsula.com>
---
meta/recipes-core/glibc/glibc-locale.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/glibc/glibc-locale.inc b/meta/recipes-core/glibc/glibc-locale.inc
index 75ababea68..1a629fc69d 100644
--- a/meta/recipes-core/glibc/glibc-locale.inc
+++ b/meta/recipes-core/glibc/glibc-locale.inc
@@ -12,7 +12,7 @@ BINUTILSDEP = "virtual/${MLPREFIX}${TARGET_PREFIX}binutils:do_populate_sysroot"
BINUTILSDEP_class-nativesdk = "virtual/${TARGET_PREFIX}binutils-crosssdk:do_populate_sysroot"
do_package[depends] += "${BINUTILSDEP}"
-# localedef links with libc.so and glibc-collateral.incinhibits all default deps
+# localedef links with libc.so and glibc-collateral.inc inhibits all default deps
# cannot add virtual/libc to DEPENDS, because it would conflict with libc-initial in RSS
RDEPENDS_localedef += "glibc"
--
2.11.0
^ permalink raw reply related
* [PATCH] Use wic.gz for all i.MX machines by default
From: Otavio Salvador @ 2017-10-04 21:12 UTC (permalink / raw)
To: meta-freescale Mailing List; +Cc: Otavio Salvador
This change moves the default image for all i.MX machines. We moved
from sdcard.gz to wic.gz.
Following machines were change:
- imx25pdk: use imx-uboot.wks
- imx6qdlsabreauto: use imx-uboot-spl-bootpart.wks
- imx6qdlsabresd: use imx-uboot-spl-bootpart.wks
- imx6ulevk: use imx-uboot-spl-bootpart.wks
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
conf/machine/imx25pdk.conf | 2 +-
conf/machine/imx6qdlsabreauto.conf | 1 +
conf/machine/imx6qdlsabresd.conf | 1 +
conf/machine/imx6ulevk.conf | 1 +
conf/machine/include/imx-base.inc | 7 +++----
5 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/conf/machine/imx25pdk.conf b/conf/machine/imx25pdk.conf
index f35d0db4..e22d9f4e 100644
--- a/conf/machine/imx25pdk.conf
+++ b/conf/machine/imx25pdk.conf
@@ -17,7 +17,7 @@ SERIAL_CONSOLE = "115200 ttymxc0"
MACHINE_FEATURES = "usbgadget usbhost vfat alsa touchscreen"
-WKS_FILE ?= "imx-uboot.wks"
+WKS_FILE = "imx-uboot.wks"
MACHINE_ESSENTIAL_EXTRA_RDEPENDS += " \
kernel-image \
kernel-devicetree \
diff --git a/conf/machine/imx6qdlsabreauto.conf b/conf/machine/imx6qdlsabreauto.conf
index 8967c150..0eed1e5c 100644
--- a/conf/machine/imx6qdlsabreauto.conf
+++ b/conf/machine/imx6qdlsabreauto.conf
@@ -31,6 +31,7 @@ UBOOT_MACHINE ?= "mx6sabreauto_defconfig"
UBOOT_MAKE_TARGET = "all"
UBOOT_SUFFIX = "img"
SPL_BINARY = "SPL"
+WKS_FILE = "imx-uboot-spl-bootpart.wks"
SERIAL_CONSOLE = "115200 ttymxc3"
diff --git a/conf/machine/imx6qdlsabresd.conf b/conf/machine/imx6qdlsabresd.conf
index 92c92884..91ca9b45 100644
--- a/conf/machine/imx6qdlsabresd.conf
+++ b/conf/machine/imx6qdlsabresd.conf
@@ -31,6 +31,7 @@ UBOOT_MACHINE ?= "mx6sabresd_defconfig"
UBOOT_MAKE_TARGET = "all"
UBOOT_SUFFIX = "img"
SPL_BINARY = "SPL"
+WKS_FILE = "imx-uboot-spl-bootpart.wks"
SERIAL_CONSOLE = "115200 ttymxc0"
diff --git a/conf/machine/imx6ulevk.conf b/conf/machine/imx6ulevk.conf
index dadd525b..1b55a4ad 100644
--- a/conf/machine/imx6ulevk.conf
+++ b/conf/machine/imx6ulevk.conf
@@ -23,3 +23,4 @@ UBOOT_CONFIG[sd] = "mx6ul_14x14_evk_config,sdcard"
UBOOT_CONFIG[emmc] = "mx6ul_14x14_evk_emmc_config,sdcard"
UBOOT_CONFIG[qspi1] = "mx6ul_14x14_evk_qspi1_config"
UBOOT_CONFIG[mfgtool] = "mx6ul_14x14_evk_config"
+WKS_FILE = "imx-uboot-spl-bootpart.wks"
diff --git a/conf/machine/include/imx-base.inc b/conf/machine/include/imx-base.inc
index c96216de..d2414472 100644
--- a/conf/machine/include/imx-base.inc
+++ b/conf/machine/include/imx-base.inc
@@ -222,8 +222,8 @@ IMX_DEFAULT_KERNEL_use-mainline-bsp = "linux-fslc"
PREFERRED_PROVIDER_virtual/kernel ??= "${IMX_DEFAULT_KERNEL}"
-SOC_DEFAULT_IMAGE_FSTYPES = "sdcard.gz"
-SOC_DEFAULT_IMAGE_FSTYPES_mxs = "uboot-mxsboot-sdcard sdcard.gz"
+SOC_DEFAULT_IMAGE_FSTYPES = "wic.gz"
+SOC_DEFAULT_IMAGE_FSTYPES_mxs = "uboot-mxsboot-sdcard wic.gz"
SDCARD_ROOTFS ?= "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.ext4"
IMAGE_FSTYPES ?= "${SOC_DEFAULT_IMAGE_FSTYPES}"
@@ -240,8 +240,7 @@ WKS_FILE_DEPENDS ?= " \
e2fsprogs-native \
bmap-tools-native \
"
-
-SOC_DEFAULT_IMAGE_FSTYPES_mx25 = "wic.gz"
+WKS_FILE ?= "imx-uboot-bootpart.wks"
SERIAL_CONSOLE = "115200 ttymxc0"
SERIAL_CONSOLE_mxs = "115200 ttyAMA0"
--
2.14.2
^ permalink raw reply related
* Re: system hung up when offlining CPUs
From: Thomas Gleixner @ 2017-10-04 21:10 UTC (permalink / raw)
To: YASUAKI ISHIMATSU
Cc: Kashyap Desai, Hannes Reinecke, Marc Zyngier, Christoph Hellwig,
axboe, mpe, keith.busch, peterz, LKML, linux-scsi, Sumit Saxena,
Shivasharan Srikanteshwara
In-Reply-To: <78ce7246-c567-3f5f-b168-9bcfc659d4bd@gmail.com>
On Mon, 2 Oct 2017, YASUAKI ISHIMATSU wrote:
>
> We are talking about megasas driver.
> So I added linux-scsi and maintainers of megasas into the thread.
Another question:
Is this the in tree megasas driver and you are observing this on Linus
latest tree, i.e. 4.14-rc3+ ?
Thanks,
tglx
^ permalink raw reply
* [PATCH v3 2/2] dt-bindings: pinctrl: add support for RZ/A1M and RZ/A1L
From: Chris Brandt @ 2017-10-04 21:07 UTC (permalink / raw)
To: Linus Walleij, Rob Herring, Mark Rutland, Geert Uytterhoeven
Cc: linux-gpio, devicetree, linux-renesas-soc, Simon Horman,
Jacopo Mondi, Chris Brandt
In-Reply-To: <20171004210724.59797-1-chris.brandt@renesas.com>
Describe how to specify RZ/A1M and RZ/A1L devices.
Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v3:
* Reworded
* Added Reviewed-by
v2:
* Added description for RZ/A1M
---
Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
index 43e21474528a..fd3696eb36bf 100644
--- a/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
@@ -12,8 +12,10 @@ Pin controller node
-------------------
Required properties:
- - compatible
- this shall be "renesas,r7s72100-ports".
+ - compatible: should be:
+ - "renesas,r7s72100-ports": for RZ/A1H
+ - "renesas,r7s72101-ports", "renesas,r7s72100-ports": for RZ/A1M
+ - "renesas,r7s72102-ports": for RZ/A1L
- reg
address base and length of the memory area where the pin controller
--
2.14.1
^ permalink raw reply related
* [PATCH v3 1/2] pinctrl: rza1: add support for RZ/A1L
From: Chris Brandt @ 2017-10-04 21:07 UTC (permalink / raw)
To: Linus Walleij, Rob Herring, Mark Rutland, Geert Uytterhoeven
Cc: linux-gpio, devicetree, linux-renesas-soc, Simon Horman,
Jacopo Mondi, Chris Brandt
In-Reply-To: <20171004210724.59797-1-chris.brandt@renesas.com>
Aspects like the number of ports and the location where peripherals are
brought out differ between the RZ/A1H and RZ/A1L.
Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
v2:
* added Reviewed-by
---
drivers/pinctrl/pinctrl-rza1.c | 134 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 134 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-rza1.c b/drivers/pinctrl/pinctrl-rza1.c
index 04d058706b80..717c0f4449a0 100644
--- a/drivers/pinctrl/pinctrl-rza1.c
+++ b/drivers/pinctrl/pinctrl-rza1.c
@@ -302,6 +302,134 @@ static const struct rza1_pinmux_conf rza1h_pmx_conf = {
.swio_entries = rza1h_swio_entries,
};
+/* ----------------------------------------------------------------------------
+ * RZ/A1L (r7s72102) pinmux flags
+ */
+
+static const struct rza1_bidir_pin rza1l_bidir_pins_p1[] = {
+ { .pin = 0, .func = 1 },
+ { .pin = 1, .func = 1 },
+ { .pin = 2, .func = 1 },
+ { .pin = 3, .func = 1 },
+ { .pin = 4, .func = 1 },
+ { .pin = 5, .func = 1 },
+ { .pin = 6, .func = 1 },
+ { .pin = 7, .func = 1 },
+};
+
+static const struct rza1_bidir_pin rza1l_bidir_pins_p3[] = {
+ { .pin = 0, .func = 2 },
+ { .pin = 1, .func = 2 },
+ { .pin = 2, .func = 2 },
+ { .pin = 4, .func = 2 },
+ { .pin = 5, .func = 2 },
+ { .pin = 10, .func = 2 },
+ { .pin = 11, .func = 2 },
+ { .pin = 12, .func = 2 },
+ { .pin = 13, .func = 2 },
+};
+
+static const struct rza1_bidir_pin rza1l_bidir_pins_p4[] = {
+ { .pin = 1, .func = 4 },
+ { .pin = 2, .func = 2 },
+ { .pin = 3, .func = 2 },
+ { .pin = 6, .func = 2 },
+ { .pin = 7, .func = 2 },
+};
+
+static const struct rza1_bidir_pin rza1l_bidir_pins_p5[] = {
+ { .pin = 0, .func = 1 },
+ { .pin = 1, .func = 1 },
+ { .pin = 2, .func = 1 },
+ { .pin = 3, .func = 1 },
+ { .pin = 4, .func = 1 },
+ { .pin = 5, .func = 1 },
+ { .pin = 6, .func = 1 },
+ { .pin = 7, .func = 1 },
+ { .pin = 8, .func = 1 },
+ { .pin = 9, .func = 1 },
+ { .pin = 10, .func = 1 },
+ { .pin = 11, .func = 1 },
+ { .pin = 12, .func = 1 },
+ { .pin = 13, .func = 1 },
+ { .pin = 14, .func = 1 },
+ { .pin = 15, .func = 1 },
+ { .pin = 0, .func = 2 },
+ { .pin = 1, .func = 2 },
+ { .pin = 2, .func = 2 },
+ { .pin = 3, .func = 2 },
+};
+
+static const struct rza1_bidir_pin rza1l_bidir_pins_p6[] = {
+ { .pin = 0, .func = 1 },
+ { .pin = 1, .func = 1 },
+ { .pin = 2, .func = 1 },
+ { .pin = 3, .func = 1 },
+ { .pin = 4, .func = 1 },
+ { .pin = 5, .func = 1 },
+ { .pin = 6, .func = 1 },
+ { .pin = 7, .func = 1 },
+ { .pin = 8, .func = 1 },
+ { .pin = 9, .func = 1 },
+ { .pin = 10, .func = 1 },
+ { .pin = 11, .func = 1 },
+ { .pin = 12, .func = 1 },
+ { .pin = 13, .func = 1 },
+ { .pin = 14, .func = 1 },
+ { .pin = 15, .func = 1 },
+};
+
+static const struct rza1_bidir_pin rza1l_bidir_pins_p7[] = {
+ { .pin = 2, .func = 2 },
+ { .pin = 3, .func = 2 },
+ { .pin = 5, .func = 2 },
+ { .pin = 6, .func = 2 },
+ { .pin = 7, .func = 2 },
+ { .pin = 2, .func = 3 },
+ { .pin = 3, .func = 3 },
+ { .pin = 5, .func = 3 },
+ { .pin = 6, .func = 3 },
+ { .pin = 7, .func = 3 },
+};
+
+static const struct rza1_bidir_pin rza1l_bidir_pins_p9[] = {
+ { .pin = 1, .func = 2 },
+ { .pin = 0, .func = 3 },
+ { .pin = 1, .func = 3 },
+ { .pin = 3, .func = 3 },
+ { .pin = 4, .func = 3 },
+ { .pin = 5, .func = 3 },
+};
+
+static const struct rza1_swio_pin rza1l_swio_pins[] = {
+ { .port = 2, .pin = 8, .func = 2, .input = 0 },
+ { .port = 5, .pin = 6, .func = 3, .input = 0 },
+ { .port = 6, .pin = 6, .func = 3, .input = 0 },
+ { .port = 6, .pin = 10, .func = 3, .input = 0 },
+ { .port = 7, .pin = 10, .func = 2, .input = 0 },
+ { .port = 8, .pin = 2, .func = 3, .input = 0 },
+};
+
+static const struct rza1_bidir_entry rza1l_bidir_entries[RZA1_NPORTS] = {
+ [1] = { ARRAY_SIZE(rza1l_bidir_pins_p1), rza1l_bidir_pins_p1 },
+ [3] = { ARRAY_SIZE(rza1l_bidir_pins_p3), rza1l_bidir_pins_p3 },
+ [4] = { ARRAY_SIZE(rza1l_bidir_pins_p4), rza1l_bidir_pins_p4 },
+ [5] = { ARRAY_SIZE(rza1l_bidir_pins_p4), rza1l_bidir_pins_p5 },
+ [6] = { ARRAY_SIZE(rza1l_bidir_pins_p6), rza1l_bidir_pins_p6 },
+ [7] = { ARRAY_SIZE(rza1l_bidir_pins_p7), rza1l_bidir_pins_p7 },
+ [9] = { ARRAY_SIZE(rza1l_bidir_pins_p9), rza1l_bidir_pins_p9 },
+};
+
+static const struct rza1_swio_entry rza1l_swio_entries[] = {
+ [0] = { ARRAY_SIZE(rza1h_swio_pins), rza1h_swio_pins },
+};
+
+/* RZ/A1L (r7s72102x) pinmux flags table */
+static const struct rza1_pinmux_conf rza1l_pmx_conf = {
+ .bidir_entries = rza1l_bidir_entries,
+ .swio_entries = rza1l_swio_entries,
+};
+
/* ----------------------------------------------------------------------------
* RZ/A1 types
*/
@@ -1283,9 +1411,15 @@ static int rza1_pinctrl_probe(struct platform_device *pdev)
static const struct of_device_id rza1_pinctrl_of_match[] = {
{
+ /* RZ/A1H, RZ/A1M */
.compatible = "renesas,r7s72100-ports",
.data = &rza1h_pmx_conf,
},
+ {
+ /* RZ/A1L */
+ .compatible = "renesas,r7s72102-ports",
+ .data = &rza1l_pmx_conf,
+ },
{ }
};
--
2.14.1
^ permalink raw reply related
* [PATCH v3 0/2] pinctrl: rza1: add support for RZ/A1L
From: Chris Brandt @ 2017-10-04 21:07 UTC (permalink / raw)
To: Linus Walleij, Rob Herring, Mark Rutland, Geert Uytterhoeven
Cc: linux-gpio, devicetree, linux-renesas-soc, Simon Horman,
Jacopo Mondi, Chris Brandt
The RZ/A series has 3 main device: RZ/A1L, RZ/A1M, RZ/A1H.
In terms of pinctrl, RZ/A1H and RZ/A1M are exactly the same.
Aspects like the number of ports and the location where peripherals are
brought out differ between the RZ/A1H and RZ/A1L.
Basically this series adds a new set of tables for RZ/A1L and a new
compatible "renesas,r7s72102-ports"
This was tested on a Renesas Stream it board which contains an RZ/A1L and
external SDRAM.
v3:
* rewored DT documentation
* Added Reviewed-by for renesas,rza1-pinctrl.txt
v2:
* Added RZ/A1M to DT documentation
* Added Reviewed-by for pinctrl-rza1.c
Chris Brandt (2):
pinctrl: rza1: add support for RZ/A1L
dt-bindings: pinctrl: add support for RZ/A1M and RZ/A1L
.../bindings/pinctrl/renesas,rza1-pinctrl.txt | 6 +-
drivers/pinctrl/pinctrl-rza1.c | 134 +++++++++++++++++++++
2 files changed, 138 insertions(+), 2 deletions(-)
--
2.14.1
^ permalink raw reply
* Re: hung grow
From: Anthony Youngman @ 2017-10-04 21:08 UTC (permalink / raw)
To: Curt; +Cc: Joe Landman, linux-raid
In-Reply-To: <CADg2FGbSyvLykThXBpMd4MOuHgh2Q_-zPGm-HFxdYW2z4qsNDQ@mail.gmail.com>
On 04/10/17 21:01, Curt wrote:
> Hello,
>
> Thanks for clarifying. All current good drives report that they are
> part of a 8 drive array. I only grew the raid by 1 device, so it
> would from 7-8, which is what they all report.
That's good.
> The 3rd failed doesn't
> report anything on examine, I haven't touched it at all and was not
> included in my assemble.
So this wasn't part of your original "assemble --force"? This wasn't
part of the array you managed to get working and then failed again?
> The 2 I replaced, the original drives I
> yanked, think they are still part of a 7 drive array.
Okay. The remaining five original disks are the ones we NEED. I'm
seriously concerned that if that third drive was one of these five,
we're in big trouble - we've lost the superblock.
>
> I'll be doing a ddrescue on the drives tonight, but will wait till
> Phil or someone chimes in with my next steps after I do that.
If you've got enough to ddrescue all of those five original drives, then
that's absolutely great.
Remember - if we can't get five original drives (or copies thereof) the
array is toast.
>
> lol, chalk one more up for FML. "SCT Error Recovery Control command
> not supported". I'm guessing this is a real bad thing now? I didn't
> buy these drives or org set it up.
>
I'm not sure whether this is good news or bad. Actually, it *could* be
great news for the rescue! It's bad news for raid though, if you don't
deal with it up front - I guess that wasn't done ...
*************
Go and read the wiki - the "When Things Go Wrogn" section. That will
hopefully help a lot and it explains the Error Recovery stuff (the
timeout mismatch page). Fix that problem and your dodgy drives will
probably dd without trouble at all.
Hopefully with all copied drives, but if you have to mix dd'd and
original drives you're probably okay, you should now be able to assemble
a working array with five drives by doing an
mdadm --assemble blah blah blah --update=revert-reshape
That will put you back to a "5 drives out of 7" working array. The
problem with this is that it will be a degraded, linear array.
I'm not sure whether a --display will list the failed drives - if it
does you can now --remove them. So you'll now have a working, 7-drive
array, with two drives missing.
Now --add in the two new drives. MAKE SURE you've read the section on
timeout mismatch and dealt with it! The rebuild/recovery will ALMOST
CERTAINLY FAIL if you don't! Also note that I am not sure about how
those drives will display while rebuilding - they may well display as
being spares during a rebuild.
Lastly, MAKE SURE you set up a regular scrub. There's a distinct
possibility that this problem wouldn't have arisen (or would have been
found quicker) if a scrub had been in place. And if you can set up a
trigger that emails you the contents of /proc/mdstat every few days.
It's far too easy to miss a failed drive if you don't have something
shoving it in your face every few days.
Cheers,
Wol
> On Wed, Oct 4, 2017 at 3:46 PM, Anthony Youngman
> <antlists@youngman.org.uk> wrote:
>> On 04/10/17 20:09, Curt wrote:
>>>
>>> Ok, thanks.
>>>
>>> I'm pretty sure I'll be able to DD from at least one of the failed
>>> drives, as I could still query them before I yanked them. Assuming I
>>> can DD one of the old drives to one of my new ones.
>>>
>>> I'd DDrescue old to new drive. Then do an assemble for force, with a
>>> mix of the dd drives and my old good ones? So if sda/b are new DD'd
>>> drives and sdc/d/e are hosed grow drives, I'd do an assemble force
>>> revert-reshape /dev/md127 sda sdb sdc sdd and sde? Then assemble can
>>> use my info from the DD drives to assemble the array back to 7 drives?
>>> Did I understand that right?
>>
>>
>> This sounds like you need to take a great big step backwards, and make sure
>> you understand EXACTLY what is going on. We have a mix of good drives,
>> copies of bad drives, and an array that doesn't know whether it is supposed
>> to have 7 or 9 drives. One wrong step and your array will be toast.
>>
>> You want ALL FOUR KNOWN GOOD DRIVES. You want JUST ONE ddrescue'd drive.
>>
>> But I think the first thing we need to do, is to wait for an expert like
>> Phil to chime in and sort out that reshape. Your four good drives all think
>> they are part of a 9-drive array. Your first two drives to fail think they
>> are part of a 7-drive array. Does the third drive think it's part of a
>> 7-drive or 9-drive array?
>>
>> Can you do a --examine on this drive? I suspect the grow blew up because it
>> couldn't access this drive. I this drive thinks it is part of a 7-drive
>> array, we have a bit of a problem on our hands.
>>
>> I'm hoping it thinks it's part of a 9-drive array - I think we may be able
>> to get out of this ...
>>>
>>>
>>> Oh and how can I tell if I have a timeout mismatch. They should be raid
>>> drives.
>>
>>
>> smartctl -x /dev/sdX
>>
>> This will give you both the sort of drive you have - yes if it's in a
>> datacentre chances are it is a raid drive - and then search the output for
>> Error Recovery Control. This is from my hard drive...
>>
>> SCT capabilities: (0x003f) SCT Status supported.
>> SCT Error Recovery Control
>> supported.
>> SCT Feature Control supported.
>> SCT Data Table supported.
>>
>> You need error recovery to be supported. If it isn't ...
>>
>>>
>>> Cheers,
>>> Curt
>>
>>
>> Cheers,
>> Wol
>
^ permalink raw reply
* [PATCH v3 0/2] pinctrl: rza1: add support for RZ/A1L
From: Chris Brandt @ 2017-10-04 21:07 UTC (permalink / raw)
To: Linus Walleij, Rob Herring, Mark Rutland, Geert Uytterhoeven
Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Simon Horman,
Jacopo Mondi, Chris Brandt
The RZ/A series has 3 main device: RZ/A1L, RZ/A1M, RZ/A1H.
In terms of pinctrl, RZ/A1H and RZ/A1M are exactly the same.
Aspects like the number of ports and the location where peripherals are
brought out differ between the RZ/A1H and RZ/A1L.
Basically this series adds a new set of tables for RZ/A1L and a new
compatible "renesas,r7s72102-ports"
This was tested on a Renesas Stream it board which contains an RZ/A1L and
external SDRAM.
v3:
* rewored DT documentation
* Added Reviewed-by for renesas,rza1-pinctrl.txt
v2:
* Added RZ/A1M to DT documentation
* Added Reviewed-by for pinctrl-rza1.c
Chris Brandt (2):
pinctrl: rza1: add support for RZ/A1L
dt-bindings: pinctrl: add support for RZ/A1M and RZ/A1L
.../bindings/pinctrl/renesas,rza1-pinctrl.txt | 6 +-
drivers/pinctrl/pinctrl-rza1.c | 134 +++++++++++++++++++++
2 files changed, 138 insertions(+), 2 deletions(-)
--
2.14.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v6 2/6] qapi/qlist: Add qlist_append_null() macro
From: Eric Blake @ 2017-10-04 21:06 UTC (permalink / raw)
To: Max Reitz, qemu-block; +Cc: qemu-devel, Markus Armbruster, Kevin Wolf
In-Reply-To: <20171004152553.30263-3-mreitz@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 493 bytes --]
On 10/04/2017 10:25 AM, Max Reitz wrote:
> Besides the macro itself, this patch also adds a corresponding
> Coccinelle rule.
>
> Signed-off-by: Max Reitz <mreitz@redhat.com>
> ---
> include/qapi/qmp/qlist.h | 3 +++
> scripts/coccinelle/qobject.cocci | 3 +++
> 2 files changed, 6 insertions(+)
Reviewed-by: Eric Blake <eblake@redhat.com>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]
^ permalink raw reply
* Re: [lockdep] b09be676e0 BUG: unable to handle kernel NULL pointer dereference at 000001f2
From: Josh Poimboeuf @ 2017-10-04 21:06 UTC (permalink / raw)
To: Tetsuo Handa
Cc: fengguang.wu, byungchul.park, mingo, peterz, linux-kernel, lkp,
torvalds, bp, x86, hpa, tglx
In-Reply-To: <201710040644.GJE89219.FOHMFSFOVtOQLJ@I-love.SAKURA.ne.jp>
On Wed, Oct 04, 2017 at 06:44:50AM +0900, Tetsuo Handa wrote:
> Josh Poimboeuf wrote:
> > On Tue, Oct 03, 2017 at 11:28:15AM -0500, Josh Poimboeuf wrote:
> > > There are two bugs:
> > >
> > > 1) Somebody -- presumably lockdep -- is corrupting the stack. Need the
> > > lockdep people to look at that.
> > >
> > > 2) The 32-bit FP unwinder isn't handling the corrupt stack very well,
> > > It's blindly dereferencing untrusted data:
> > >
> > > /* Is the next frame pointer an encoded pointer to pt_regs? */
> > > regs = decode_frame_pointer(next_bp);
> > > if (regs) {
> > > frame = (unsigned long *)regs;
> > > len = regs_size(regs);
> > > state->got_irq = true;
> > >
> > > On 32-bit, regs_size() dereferences the regs pointer before we know it
> > > points to a valid stack. I'll fix that, along with the other unwinder
> > > improvements I discussed with Linus.
> >
> > Tetsuo and/or Fengguang,
> >
> > Would you mind testing with this patch? It should at least prevent the
> > unwinder panic and should hopefully print a useful unwinder dump
> > instead.
> >
> Here are two outputs.
Thanks, both outputs were helpful.
This is another unwinder-related issue, unrelated to lockdep this time.
I compiled the same kernel with a similar version of GCC. It turns out
that GCC *does* create unaligned stacks with frame pointers enabled:
c124a388 <acpi_rs_move_data>:
c124a388: 55 push %ebp
c124a389: 89 e5 mov %esp,%ebp
c124a38b: 57 push %edi
c124a38c: 56 push %esi
c124a38d: 89 d6 mov %edx,%esi
c124a38f: 53 push %ebx
c124a390: 31 db xor %ebx,%ebx
c124a392: 83 ec 03 sub $0x3,%esp
...
c124a3e3: 83 c4 03 add $0x3,%esp
c124a3e6: 5b pop %ebx
c124a3e7: 5e pop %esi
c124a3e8: 5f pop %edi
c124a3e9: 5d pop %ebp
c124a3ea: c3 ret
This was a leaf function. For no apparent reason, GCC 4.8 decided to
subtract 3 from the stack pointer in the prologue.
Then in the middle of the function, it got an interrupt. On 64-bit,
interrupts always align the stack, but on 32-bit they don't. So the
pt_regs were stored at an unaligned address (0xf60bbb25).
The frame pointer encoding logic assumes an aligned stack pointer, so it
didn't work as expected.
.macro ENCODE_FRAME_POINTER
#ifdef CONFIG_FRAME_POINTER
mov %esp, %ebp
orl $0x1, %ebp
#endif
.endm
That effectively cleared the LSB of the encoded pt_regs address,
confusing the unwinder.
So on 32-bit, maybe the encoding should clear the MSB instead of setting
the LSB.
--
Josh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.