diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2022-06-05 10:53:41 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2022-06-05 10:53:41 -0700 |
commit | a925128092d8dd5c2ea8644e1dddd510b7ebc9c7 (patch) | |
tree | 50fba71b3bc2c442e511208957130dd09c5e1018 /arch | |
parent | 1fd9f4ce8442e34d4f817924d191d2855cdb80c5 (diff) | |
parent | f7081834b2d5bbc77d67073d8ab490bfeaf3c13b (diff) |
Merge tag 'x86-cleanups-2022-06-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 cleanups from Thomas Gleixner:
"A set of small x86 cleanups:
- Remove unused headers in the IDT code
- Kconfig indendation and comment fixes
- Fix all 'the the' typos in one go instead of waiting for bots to
fix one at a time"
* tag 'x86-cleanups-2022-06-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86: Fix all occurences of the "the the" typo
x86/idt: Remove unused headers
x86/Kconfig: Fix indentation of arch/x86/Kconfig.debug
x86/Kconfig: Fix indentation and add endif comments to arch/x86/Kconfig
Diffstat (limited to 'arch')
-rw-r--r-- | arch/x86/Kconfig | 102 | ||||
-rw-r--r-- | arch/x86/Kconfig.debug | 29 | ||||
-rw-r--r-- | arch/x86/kvm/vmx/vmx.c | 2 | ||||
-rw-r--r-- | arch/x86/kvm/x86.c | 2 | ||||
-rw-r--r-- | arch/x86/platform/efi/efi_thunk_64.S | 2 |
5 files changed, 66 insertions, 71 deletions
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index e0498b2e9b79..7df2a9ef3662 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -41,11 +41,11 @@ config FORCE_DYNAMIC_FTRACE depends on FUNCTION_TRACER select DYNAMIC_FTRACE help - We keep the static function tracing (!DYNAMIC_FTRACE) around - in order to test the non static function tracing in the - generic code, as other architectures still use it. But we - only need to keep it around for x86_64. No need to keep it - for x86_32. For x86_32, force DYNAMIC_FTRACE. + We keep the static function tracing (!DYNAMIC_FTRACE) around + in order to test the non static function tracing in the + generic code, as other architectures still use it. But we + only need to keep it around for x86_64. No need to keep it + for x86_32. For x86_32, force DYNAMIC_FTRACE. # # Arch settings # @@ -394,9 +394,9 @@ config CC_HAS_SANE_STACKPROTECTOR default $(success,$(srctree)/scripts/gcc-x86_64-has-stack-protector.sh $(CC)) if 64BIT default $(success,$(srctree)/scripts/gcc-x86_32-has-stack-protector.sh $(CC)) help - We have to make sure stack protector is unconditionally disabled if - the compiler produces broken code or if it does not let us control - the segment on 32-bit kernels. + We have to make sure stack protector is unconditionally disabled if + the compiler produces broken code or if it does not let us control + the segment on 32-bit kernels. menu "Processor type and features" @@ -532,7 +532,7 @@ config X86_EXTENDED_PLATFORM If you have one of these systems, or if you want to build a generic distribution kernel, say Y here - otherwise say N. -endif +endif # X86_32 if X86_64 config X86_EXTENDED_PLATFORM @@ -551,7 +551,7 @@ config X86_EXTENDED_PLATFORM If you have one of these systems, or if you want to build a generic distribution kernel, say Y here - otherwise say N. -endif +endif # X86_64 # This is an alphabetically sorted list of 64 bit extended platforms # Please maintain the alphabetic order if and when there are additions config X86_NUMACHIP @@ -599,9 +599,9 @@ config X86_GOLDFISH bool "Goldfish (Virtual Platform)" depends on X86_EXTENDED_PLATFORM help - Enable support for the Goldfish virtual platform used primarily - for Android development. Unless you are building for the Android - Goldfish emulator say N here. + Enable support for the Goldfish virtual platform used primarily + for Android development. Unless you are building for the Android + Goldfish emulator say N here. config X86_INTEL_CE bool "CE4100 TV platform" @@ -900,7 +900,7 @@ config INTEL_TDX_GUEST memory contents and CPU state. TDX guests are protected from some attacks from the VMM. -endif #HYPERVISOR_GUEST +endif # HYPERVISOR_GUEST source "arch/x86/Kconfig.cpu" @@ -1167,16 +1167,16 @@ config X86_MCE_INTEL prompt "Intel MCE features" depends on X86_MCE && X86_LOCAL_APIC help - Additional support for intel specific MCE features such as - the thermal monitor. + Additional support for intel specific MCE features such as + the thermal monitor. config X86_MCE_AMD def_bool y prompt "AMD MCE features" depends on X86_MCE && X86_LOCAL_APIC && AMD_NB help - Additional support for AMD specific MCE features such as - the DRAM Error Threshold. + Additional support for AMD specific MCE features such as + the DRAM Error Threshold. config X86_ANCIENT_MCE bool "Support for old Pentium 5 / WinChip machine checks" @@ -1254,18 +1254,18 @@ config X86_VSYSCALL_EMULATION default y depends on X86_64 help - This enables emulation of the legacy vsyscall page. Disabling - it is roughly equivalent to booting with vsyscall=none, except - that it will also disable the helpful warning if a program - tries to use a vsyscall. With this option set to N, offending - programs will just segfault, citing addresses of the form - 0xffffffffff600?00. + This enables emulation of the legacy vsyscall page. Disabling + it is roughly equivalent to booting with vsyscall=none, except + that it will also disable the helpful warning if a program + tries to use a vsyscall. With this option set to N, offending + programs will just segfault, citing addresses of the form + 0xffffffffff600?00. - This option is required by many programs built before 2013, and - care should be used even with newer programs if set to N. + This option is required by many programs built before 2013, and + care should be used even with newer programs if set to N. - Disabling this option saves about 7K of kernel size and - possibly 4K of additional runtime pagetable memory. + Disabling this option saves about 7K of kernel size and + possibly 4K of additional runtime pagetable memory. config X86_IOPL_IOPERM bool "IOPERM and IOPL Emulation" @@ -2002,15 +2002,15 @@ config EFI_MIXED bool "EFI mixed-mode support" depends on EFI_STUB && X86_64 help - Enabling this feature allows a 64-bit kernel to be booted - on a 32-bit firmware, provided that your CPU supports 64-bit - mode. + Enabling this feature allows a 64-bit kernel to be booted + on a 32-bit firmware, provided that your CPU supports 64-bit + mode. - Note that it is not possible to boot a mixed-mode enabled - kernel via the EFI boot stub - a bootloader that supports - the EFI handover protocol must be used. + Note that it is not possible to boot a mixed-mode enabled + kernel via the EFI boot stub - a bootloader that supports + the EFI handover protocol must be used. - If unsure, say N. + If unsure, say N. source "kernel/Kconfig.hz" @@ -2235,16 +2235,16 @@ config RANDOMIZE_MEMORY select DYNAMIC_MEMORY_LAYOUT default RANDOMIZE_BASE help - Randomizes the base virtual address of kernel memory sections - (physical memory mapping, vmalloc & vmemmap). This security feature - makes exploits relying on predictable memory locations less reliable. + Randomizes the base virtual address of kernel memory sections + (physical memory mapping, vmalloc & vmemmap). This security feature + makes exploits relying on predictable memory locations less reliable. - The order of allocations remains unchanged. Entropy is generated in - the same way as RANDOMIZE_BASE. Current implementation in the optimal - configuration have in average 30,000 different possible virtual - addresses for each memory section. + The order of allocations remains unchanged. Entropy is generated in + the same way as RANDOMIZE_BASE. Current implementation in the optimal + configuration have in average 30,000 different possible virtual + addresses for each memory section. - If unsure, say Y. + If unsure, say Y. config RANDOMIZE_MEMORY_PHYSICAL_PADDING hex "Physical memory mapping padding" if EXPERT @@ -2254,12 +2254,12 @@ config RANDOMIZE_MEMORY_PHYSICAL_PADDING range 0x1 0x40 if MEMORY_HOTPLUG range 0x0 0x40 help - Define the padding in terabytes added to the existing physical - memory size during kernel memory randomization. It is useful - for memory hotplug support but reduces the entropy available for - address randomization. + Define the padding in terabytes added to the existing physical + memory size during kernel memory randomization. It is useful + for memory hotplug support but reduces the entropy available for + address randomization. - If unsure, leave at the default value. + If unsure, leave at the default value. config HOTPLUG_CPU def_bool y @@ -2606,7 +2606,6 @@ source "drivers/idle/Kconfig" endmenu - menu "Bus options (PCI etc.)" choice @@ -2830,7 +2829,6 @@ config AMD_NB endmenu - menu "Binary Emulations" config IA32_EMULATION @@ -2868,14 +2866,12 @@ config COMPAT def_bool y depends on IA32_EMULATION || X86_X32_ABI -if COMPAT config COMPAT_FOR_U64_ALIGNMENT def_bool y -endif + depends on COMPAT endmenu - config HAVE_ATOMIC_IOMAP def_bool y depends on X86_32 diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug index d872a7522e55..340399f69954 100644 --- a/arch/x86/Kconfig.debug +++ b/arch/x86/Kconfig.debug @@ -73,20 +73,19 @@ config DEBUG_TLBFLUSH bool "Set upper limit of TLB entries to flush one-by-one" depends on DEBUG_KERNEL help + X86-only for now. - X86-only for now. + This option allows the user to tune the amount of TLB entries the + kernel flushes one-by-one instead of doing a full TLB flush. In + certain situations, the former is cheaper. This is controlled by the + tlb_flushall_shift knob under /sys/kernel/debug/x86. If you set it + to -1, the code flushes the whole TLB unconditionally. Otherwise, + for positive values of it, the kernel will use single TLB entry + invalidating instructions according to the following formula: - This option allows the user to tune the amount of TLB entries the - kernel flushes one-by-one instead of doing a full TLB flush. In - certain situations, the former is cheaper. This is controlled by the - tlb_flushall_shift knob under /sys/kernel/debug/x86. If you set it - to -1, the code flushes the whole TLB unconditionally. Otherwise, - for positive values of it, the kernel will use single TLB entry - invalidating instructions according to the following formula: + flush_entries <= active_tlb_entries / 2^tlb_flushall_shift - flush_entries <= active_tlb_entries / 2^tlb_flushall_shift - - If in doubt, say "N". + If in doubt, say "N". config IOMMU_DEBUG bool "Enable IOMMU debugging" @@ -119,10 +118,10 @@ config X86_DECODER_SELFTEST depends on DEBUG_KERNEL && INSTRUCTION_DECODER depends on !COMPILE_TEST help - Perform x86 instruction decoder selftests at build time. - This option is useful for checking the sanity of x86 instruction - decoder code. - If unsure, say "N". + Perform x86 instruction decoder selftests at build time. + This option is useful for checking the sanity of x86 instruction + decoder code. + If unsure, say "N". choice prompt "IO delay type" diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index f5aeade623d6..a07e8cd753ec 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -6219,7 +6219,7 @@ static noinstr void vmx_l1d_flush(struct kvm_vcpu *vcpu) int size = PAGE_SIZE << L1D_CACHE_ORDER; /* - * This code is only executed when the the flush mode is 'cond' or + * This code is only executed when the flush mode is 'cond' or * 'always' */ if (static_branch_likely(&vmx_l1d_flush_cond)) { diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index b81ef4f497f4..e9473c7c7390 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -11937,7 +11937,7 @@ void kvm_arch_destroy_vm(struct kvm *kvm) if (current->mm == kvm->mm) { /* * Free memory regions allocated on behalf of userspace, - * unless the the memory map has changed due to process exit + * unless the memory map has changed due to process exit * or fd copying. */ mutex_lock(&kvm->slots_lock); diff --git a/arch/x86/platform/efi/efi_thunk_64.S b/arch/x86/platform/efi/efi_thunk_64.S index 854dd81804b7..9ffe2bad27d5 100644 --- a/arch/x86/platform/efi/efi_thunk_64.S +++ b/arch/x86/platform/efi/efi_thunk_64.S @@ -8,7 +8,7 @@ * The below thunking functions are only used after ExitBootServices() * has been called. This simplifies things considerably as compared with * the early EFI thunking because we can leave all the kernel state - * intact (GDT, IDT, etc) and simply invoke the the 32-bit EFI runtime + * intact (GDT, IDT, etc) and simply invoke the 32-bit EFI runtime * services from __KERNEL32_CS. This means we can continue to service * interrupts across an EFI mixed mode call. * |