[GIT PULL] x86/build for v5.12

building. - Add documentation about "make kvm_guest/xen.config" in "make help" output. ---- Borislav Petkov (2): x86/build: Add {kvm_guest,xen}.config targets to make help's output x86/build: Realign archh

[GIT PULL] x86/cache for v5.12

Hi Linus, please pull a couple of resctrl fixes for v5.12. Thx. --- The following changes since commit 7c53f6b671f4aba70ff15e1b05148b10d58c2837: Linux 5.11-rc3 (2021-01-10 14:34:50 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git

[GIT PULL] x86/cpu for v5.12

Hi Linus, please pull a single cleanup to the x86/cpu area for v5.12. Thx. --- The following changes since commit 7c53f6b671f4aba70ff15e1b05148b10d58c2837: Linux 5.11-rc3 (2021-01-10 14:34:50 -0800) are available in the Git repository at:

[GIT PULL] x86/fpu for v5.12

Hi Linus, please pull an x86/fpu usage optimization and cleanups for v5.12. Thx. --- The following changes since commit 6ee1d745b7c9fd573fba142a2efdad76a9f1cb04: Linux 5.11-rc5 (2021-01-24 16:47:14 -0800) are available in the Git repository at:

[GIT PULL] x86/microcode for v5.12

. Borislav Petkov (1): x86/microcode: Make microcode_init() static arch/x86/include/asm/microcode.h | 2 -- arch/x86/kernel/cpu/microcode/core.c | 2 +- 2 files changed, 1 insertion(+), 3 deletions(-) -- Regards/Gruss, Boris

[GIT PULL] x86/misc for v5.12

Hi Linus, please pull the pile of miscellaneous fixes for v5.12. Thx. --- The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the Git repository at:

[GIT PULL] x86/mm for v5.12

Hi Linus, please pull the x86/mm pile (which has x86/cleanups too as they topically belong together) for v5.12. Thx. --- The following changes since commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62: Linux 5.11-rc2 (2021-01-03 15:55:30 -0800) are available in the Git repository at:

[GIT PULL] x86/paravirt for v5.12

Hi Linus, please pull the first part of the conversion of the paravirt infrastructure to our patching facilities. Thx. --- The following changes since commit 92bf22614b21a2706f4993b278017e437f7785b3: Linux 5.11-rc7 (2021-02-07 13:57:38 -0800) are available in the Git repository at:

[GIT PULL] x86/platform for v5.12

Hi Linus, please pull x86/platform fixes for v5.12. Thx. --- The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git

[GIT PULL] x86/seves for v5.12

Hi Linus, please pull a single SEV-ES fix for v5.12. Thx. --- The following changes since commit 1048ba83fb1c00cd24172e23e8263972f6b5d9ac: Linux 5.11-rc6 (2021-01-31 13:50:09 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git

[GIT PULL] x86/sgx for v5.12

Hi Linus, please pull some SGX fixes for v5.12. Thx. --- The following changes since commit 7c53f6b671f4aba70ff15e1b05148b10d58c2837: Linux 5.11-rc3 (2021-01-10 14:34:50 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git

[GIT PULL] RAS updates for v5.12

. - Identify CPUs which miss to enter the broadcast handler, as an additional debugging aid. Borislav Petkov (2): x86/mce: Get rid of mcheck_intel_therm_init() thermal: Move therm_throt there from x86/mce Paul E. McKenney (1

[GIT PULL] EDAC updates for v5.12

: - merge debugging and error injection functionality into the main driver - tone down info/error output - do not attempt to load it on F15h client hw - Misc fixes to other drivers Borislav Petkov (6): EDAC/amd64: Do not load

[GIT PULL] x86/urgent for v5.11

CET instrumentation generation for kernel code. We forgot 32-bit, which we seem to do very often nowadays. - A Xen PV fix to irqdomain init ordering. ---- Borislav Petkov (1): x86/build: Disable CET instrumentation in the kernel fo

Re: [tip:x86/mm] BUILD SUCCESS WITH WARNING c46f52231e79af025e2c89e889d69ec20a4c024f

On Thu, Feb 11, 2021 at 06:46:19PM +0800, kernel test robot wrote: > tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > x86/mm > branch HEAD: c46f52231e79af025e2c89e889d69ec20a4c024f x86/{fault,efi}: Fix > and rename efi_recover_from_page_fault() > > possible Warning in

Re: [PATCH v2 08/14] x86/fault: Skip erratum #93 workaround on new CPUs

On Tue, Feb 09, 2021 at 10:06:02PM -0800, Andy Lutomirski wrote: > On Tue, Feb 9, 2021 at 6:33 PM Andy Lutomirski wrote: > > > > Erratum #93 applies to the first generation of AMD K8 CPUs. Skip the > > workaround on newer CPUs. > > Whoops, this breaks the !CPU_SUP_AMD build. It needs a fixup

Re: [PATCH v1] x86/vdso: fix CE on non-compatible cflags

On Tue, Feb 09, 2021 at 07:07:49PM -0500, Tong Zhang wrote: > I am getting some compilation error on when using CONFIG_X86_32 kernel > configuration With an ubuntu gcc? Does this branch work: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/urgent ? Thx. --

Re: [PATCH v3 08/21] x86/fpu/xstate: Define the scope of the initial xstate data

On Mon, Feb 08, 2021 at 06:53:23PM +, Bae, Chang Seok wrote: > Maybe, drop ‘for convenience’ from this sentence, since the buffer’s usage is > not much relevant in this changelog. Yes, "init_fpstate" is kinda clear what it is, from the name. > It does functional change, but it is conditional

[tip: x86/urgent] x86/build: Disable CET instrumentation in the kernel for 32-bit too

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: 256b92af784d5043eeb7d559b6d5963dcc2ecb10 Gitweb: https://git.kernel.org/tip/256b92af784d5043eeb7d559b6d5963dcc2ecb10 Author:Borislav Petkov AuthorDate:Mon, 08 Feb 2021 16:43:30 +01:00

Re: [kbuild-all] Re: [patch 06/12] x86/entry: Convert system vectors to irq stack macro

On Tue, Feb 09, 2021 at 04:57:09PM +0800, Rong Chen wrote: > Thanks for the help, how can we identify the patches for tip tree, > could you please guide us? I guess something like: cat patch | ./scripts/get_maintainer.pl -m --no-r --no-l For a tip patch, it should give, among others:

Re: linux-next: Tree for Feb 8 (Warning at arch/x86/kernel/irq.c:390)

On Mon, Feb 08, 2021 at 07:33:17PM -0800, Randy Dunlap wrote: > On 2/8/21 4:52 AM, Stephen Rothwell wrote: > > Hi all, > > > > Changes since 20210205: > > > > on x86_64: > > Re: commit 1dba8a9538f5164eb8874eed4c7d6799a3c64963 > Author: Borislav Petko

Re: [PATCH v2 2/2] thermal: Move therm_throt there from x86/mce

Hi, On Tue, Feb 09, 2021 at 11:27:57AM +0900, Sergey Senozhatsky wrote: > Seems that the patch triggers some WARNs on my laptop. yeah, that one is replaced with a better variant now and it should land in the next linux-next, the one after next-20210208 :) Thx. -- Regards/Gruss, Boris.

Re: [PATCH v19 06/25] x86/cet: Add control-protection fault handler

On Mon, Feb 08, 2021 at 11:23:18AM -0800, Yu, Yu-cheng wrote: > exc_general_protection() and do_trap() both call show_signal(), which > then calls printk_ratelimit(). You could've done some git archeology and could've found abd4f7505baf ("x86: i386-show-unhandled-signals-v3") which explains

Re: [PATCH V3 2/6] x86_32: use percpu instead of offset-calculation to get thread.sp0 when SWITCH_TO_KERNEL_STACK

On Thu, Jan 28, 2021 at 12:32:18AM +0800, Lai Jiangshan wrote: > From: Lai Jiangshan > > TSS_entry2task_stack is used to refer to tss.sp1 which is stored the value > of thread.sp0. "... which is a copy of thread.sp0." > > At the code where TSS_entry2task_stack is used in

Re: [PATCH 02/49] x86/cpu: Describe hybrid CPUs in cpuinfo_x86

On Mon, Feb 08, 2021 at 11:10:18AM -0800, Luck, Tony wrote: > > +u32 x86_read_hybrid_type(void) > > +{ > > + if (cpu_feature_enabled(X86_FEATURE_HYBRID_CPU)) > > + return cpuid_eax(0x001a); > > + > > + return 0; > > +} > > Machine check logging will want to include this in

Re: [PATCH v19 06/25] x86/cet: Add control-protection fault handler

On Mon, Feb 08, 2021 at 10:50:07AM -0800, Yu, Yu-cheng wrote: > I have not run into the situation. Initially it was there because other > faults have it. Which other faults? > When you asked, I went through it and put out my reasoning. What does that mean? > I think it still makes sense to

Re: [PATCH v19 06/25] x86/cet: Add control-protection fault handler

On Fri, Feb 05, 2021 at 10:00:21AM -0800, Yu, Yu-cheng wrote: > The ratelimit here is only for #CP, and its rate is not counted together > with other types of faults. If a task gets here, it will exit. The only > condition the ratelimit will trigger is when multiple tasks hit #CP at once, >

Re: [PATCH 02/49] x86/cpu: Describe hybrid CPUs in cpuinfo_x86

On Mon, Feb 08, 2021 at 07:24:59AM -0800, kan.li...@linux.intel.com wrote: > diff --git a/arch/x86/include/asm/processor.h > b/arch/x86/include/asm/processor.h > index c20a52b..1f25ac9 100644 > --- a/arch/x86/include/asm/processor.h > +++ b/arch/x86/include/asm/processor.h > @@ -139,6 +139,16 @@

[PATCH] x86/build: Disable CET instrumentation in the kernel for 32-bit too

On Mon, Feb 08, 2021 at 10:19:33AM -0500, AC wrote: > That did fix it, thank you! Thanks! --- From: Borislav Petkov Date: Mon, 8 Feb 2021 16:43:30 +0100 Subject: [PATCH] x86/build: Disable CET instrumentation in the kernel for 32-bit too Commit 20bf2b378729 ("x86/build: Dis

Re: [patch 05/12] x86/irq: Provide macro for inlining irq stack switching

On Thu, Feb 04, 2021 at 09:49:08PM +0100, Thomas Gleixner wrote: > The effort to make the ASM entry code slim and unified moved the irq stack > switching out of the low level ASM code so that the whole return from > interrupt work and state handling can be done in C and the ASM code just > handles

Re: [kbuild-all] Re: [patch 06/12] x86/entry: Convert system vectors to irq stack macro

On Sun, Feb 07, 2021 at 04:15:11PM +0800, Rong Chen wrote: > Thanks for the advice, we'll add the check to our cluster, > and sorry for the inconvenience. When it comes to the tip tree, I'd say you guys are much better off not scraping any patches from the mailing list but simply testing the tip

Re: [PATCH v3 10/21] x86/fpu/xstate: Update xstate save function to support dynamic xstate

On Wed, Dec 23, 2020 at 07:57:06AM -0800, Chang S. Bae wrote: > copy_xregs_to_kernel() used to save all user states in a kernel buffer. > When the dynamic user state is enabled, it becomes conditional which state > to be saved. > > fpu->state_mask can indicate which state components are reserved

Re: [PATCH v3 09/21] x86/fpu/xstate: Introduce wrapper functions to organize xstate buffer access

On Wed, Dec 23, 2020 at 07:57:05AM -0800, Chang S. Bae wrote: > The struct fpu includes two (possible) xstate buffers -- fpu->state and > fpu->state_ptr. Instead of open code for accessing one of them, provide a > wrapper that covers both cases. Right, if you do the thing I suggested - have a

Re: [PATCH v3 08/21] x86/fpu/xstate: Define the scope of the initial xstate data

On Wed, Dec 23, 2020 at 07:57:04AM -0800, Chang S. Bae wrote: > init_fpstate is used to record the initial xstate value for convenience convenience? > and covers all the states. But it is wasteful to cover large states all > with trivial initial data. > > Limit init_fpstate by clarifying its

Re: PROBLEM: 5.11.0-rc7 fails to compile with error: ‘-mindirect-branch’ and ‘-fcf-protection’ are not compatible

On Sun, Feb 07, 2021 at 07:40:32PM -0500, Stuart Little wrote: > > On Sun, Feb 07, 2021 at 06:31:22PM -0500, Stuart Little wrote: > > > I am trying to compile on an x86_64 host for a 32-bit system; my config > > > is at > > > > > > https://termbin.com/v8jl > > > > > > I am getting numerous

[tip: ras/core] thermal: Move therm_throt there from x86/mce

The following commit has been merged into the ras/core branch of tip: Commit-ID: 9223d0dccb8f8523754122f68316dd1a4f39f7f8 Gitweb: https://git.kernel.org/tip/9223d0dccb8f8523754122f68316dd1a4f39f7f8 Author:Borislav Petkov AuthorDate:Thu, 07 Jan 2021 13:29:05 +01:00

[tip: ras/core] x86/mce: Get rid of mcheck_intel_therm_init()

The following commit has been merged into the ras/core branch of tip: Commit-ID: 4f432e8bb15b352da72525144da025a46695968f Gitweb: https://git.kernel.org/tip/4f432e8bb15b352da72525144da025a46695968f Author:Borislav Petkov AuthorDate:Thu, 07 Jan 2021 13:23:34 +01:00

Re: WARNING: at arch/x86/kernel/irq.c:390 thermal_set_handler

On Mon, Feb 08, 2021 at 03:01:39PM +0530, Naresh Kamboju wrote: > The following kernel warning noticed on Linux next tag 20210205 while booting > x86_64 and i386. > > step to reproduce: > - Boot linux next tag 20210205 on x86_64 > - While booting you will notice the below warning > > > [

Re: [GIT PULL] x86/urgent for v5.11-rc7

On Sun, Feb 07, 2021 at 09:49:18AM -0800, Linus Torvalds wrote: > On Sun, Feb 7, 2021 at 2:40 AM Borislav Petkov wrote: > > > > - Disable CET instrumentation in the kernel so that gcc doesn't add > > ENDBR64 to kernel code and thus confuse tracing. > > So this is cl

[GIT PULL] irq/urgent for v5.11-rc7

Hi Linus, please pull two irq/urgent fixes for v5.11. Thx. --- The following changes since commit 13391c60da3308ed9980de0168f74cce6c62ac1d: Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 (2021-01-25 15:26:51 -0800) are available in the Git

Re: [PATCH RFC 3/7] kvm: x86: XSAVE state and XFD MSRs context switch

On Sun, Feb 07, 2021 at 10:42:52AM -0500, Jing Liu wrote: > diff --git a/arch/x86/kernel/fpu/init.c b/arch/x86/kernel/fpu/init.c > index 7e0c68043ce3..fbb761fc13ec 100644 > --- a/arch/x86/kernel/fpu/init.c > +++ b/arch/x86/kernel/fpu/init.c > @@ -145,6 +145,7 @@

[GIT PULL] core/urgent for v5.11-rc7

Hi Linus, pls pull two core/urgent fixes for v5.11. Thx. --- The following changes since commit 1048ba83fb1c00cd24172e23e8263972f6b5d9ac: Linux 5.11-rc6 (2021-01-31 13:50:09 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git

[GIT PULL] sched/urgent for v5.11-rc7

Hi Linus, pls pull one sched/urgent revert for v5.11. Thx. --- The following changes since commit 1048ba83fb1c00cd24172e23e8263972f6b5d9ac: Linux 5.11-rc6 (2021-01-31 13:50:09 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git

[GIT PULL] timers/urgent for v5.11-rc7

Hi Linus, please pull two more timers-related fixes for v5.11. Thx. --- The following changes since commit 211e5db19d15a721b2953ea54b8f26c2963720eb: rtc: mc146818: Detect and handle broken RTCs (2021-01-27 09:36:22 +0100) are available in the Git repository at:

[GIT PULL] x86/urgent for v5.11-rc7

watchpoints with gdb again. - Disable CET instrumentation in the kernel so that gcc doesn't add ENDBR64 to kernel code and thus confuse tracing. Borislav Petkov (2): tools/power/turbostat: Fallback to an MSR read for EPB

[tip: x86/urgent] x86/efi: Remove EFI PGD build time checks

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: 816ef8d7a2c4182e19bc06ab65751cb9e3951e94 Gitweb: https://git.kernel.org/tip/816ef8d7a2c4182e19bc06ab65751cb9e3951e94 Author:Borislav Petkov AuthorDate:Fri, 05 Feb 2021 11:31:31 +01:00

Re: [PATCH v19 06/25] x86/cet: Add control-protection fault handler

On Wed, Feb 03, 2021 at 02:55:28PM -0800, Yu-cheng Yu wrote: > +DEFINE_IDTENTRY_ERRORCODE(exc_control_protection) > +{ > + static DEFINE_RATELIMIT_STATE(rs, DEFAULT_RATELIMIT_INTERVAL, > + DEFAULT_RATELIMIT_BURST); > + struct task_struct *tsk; > + > +

Re: [PATCH v19 04/25] x86/cpufeatures: Introduce X86_FEATURE_CET and setup functions

On Wed, Feb 03, 2021 at 02:55:26PM -0800, Yu-cheng Yu wrote: > @@ -1252,6 +1260,13 @@ static void __init cpu_parse_early_param(void) > if (cmdline_find_option_bool(boot_command_line, "noxsaves")) > setup_clear_cpu_cap(X86_FEATURE_XSAVES); > > +#ifdef CONFIG_X86_CET > + if

Re: [PATCH v2 1/2] EDAC/ghes: Add EDAC device for reporting the CPU cache errors

On Fri, Feb 05, 2021 at 01:54:04PM +0100, Rafael J. Wysocki wrote: > Boris, James, I need your input here. Gave mine already: https://lkml.kernel.org/r/20210119101655.gd27...@zn.tnic -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette

Re: [patch 01/12] x86/entry: Fix instrumentation annotation

On Thu, Feb 04, 2021 at 09:49:04PM +0100, Thomas Gleixner wrote: > Embracing a callout into instrumentation_begin() / instrumentation_begin() > does not really make sense. Make the latter instrumentation_end(). > > Signed-off-by: Thomas Gleixner > --- > arch/x86/entry/common.c |2 +- > 1

[PATCH] x86/efi: Remove EFI PGD build time checks

From: Borislav Petkov With CONFIG_X86_5LEVEL, CONFIG_UBSAN and CONFIG_UBSAN_UNSIGNED_OVERFLOW enabled, clang fails the build with x86_64-linux-ld: arch/x86/platform/efi/efi_64.o: in function `efi_sync_low_kernel_mappings': efi_64.c:(.text+0x22c): undefined reference

Re: [PATCH] x86: efi: avoid BUILD_BUG_ON() for non-constant p4d_index

On Wed, Feb 03, 2021 at 11:51:48AM -0700, Nathan Chancellor wrote: > x86_64 all{mod,yes}config with clang are going to ship broken in 5.11. Dunno, it is still broken here even with those build assertions removed. And it ain't even an all{mod,yes}config - just my machine's config with

Re: [PATCH v4 2/5] KVM: X86: Expose PKS to guest

On Fri, Feb 05, 2021 at 10:25:48AM +0100, Paolo Bonzini wrote: > On 05/02/21 09:37, Chenyi Qiang wrote: > > > > diff --git a/arch/x86/mm/pkeys.c b/arch/x86/mm/pkeys.c > > index 57718716cc70..8027f854c600 100644 > > --- a/arch/x86/mm/pkeys.c > > +++ b/arch/x86/mm/pkeys.c > > @@ -390,3 +390,9 @@

Re: [RFC][PATCH 1/2] x86: remove duplicate TSC DEADLINE MSR definitions

On Thu, Mar 05, 2020 at 09:47:06AM -0800, Dave Hansen wrote: > > There are two definitions for the TSC deadline MSR in msr-index.h, > one with an underscore and one without. Axe one of them and move > all the references over to the other one. > > Cc: x...@kernel.org > Cc: Peter Zijlstra > >

Re: [PATCH] x86: efi: avoid BUILD_BUG_ON() for non-constant p4d_index

On Thu, Feb 04, 2021 at 04:43:58PM -0500, Arvind Sankar wrote: > This should check EFI_VA_END instead of EFI_VA_START, and maybe throw in > a BUG_ON if EFI_VA_END >= EFI_VA_START. No need: if (efi_va < EFI_VA_END) { pr_warn(FW_WARN "VA address range overflow!\n");

Re: [PATCH V3 1/6] x86_64: move cpu_current_top_of_stack out of TSS

> Subject: Re: [PATCH V3 1/6] x86_64: move cpu_current_top_of_stack out of TSS The tip tree preferred format for patch subject prefixes is 'subsys/component:', e.g. 'x86/apic:', 'x86/mm/fault:', 'sched/fair:', 'genirq/core:'. Please do not use file names or complete file paths as prefix. 'git log

Re: [PATCH v3 07/21] x86/fpu/xstate: Introduce helpers to manage dynamic xstate buffers

On Wed, Feb 03, 2021 at 04:10:24AM +, Bae, Chang Seok wrote: > Okay, how about: > “ > This alignment bit is set if the state is saved on a 64B-aligned address in > the compacted format buffer. > " I'd prefer: /* * True if the buffer of the corresponding XFEATURE is located on the next 64 *

Re: [PATCH] x86: efi: avoid BUILD_BUG_ON() for non-constant p4d_index

On Wed, Feb 03, 2021 at 09:29:18PM +0100, Ard Biesheuvel wrote: > I think we have agreement on the approach but it is unclear who is > going to write the patch. How's that below? And frankly, I'd even vote for removing those assertions altogether. If somehow the EFI pgd lands somewhere else, the

Re: [PATCH 09/11] x86/fault: Rename no_context() to kernelmode_fixup_or_oops()

On Wed, Feb 03, 2021 at 12:14:24PM -0800, Andy Lutomirski wrote: > Hmm. I'm not convinced this is really much better. Maybe it is. Let > me think about it. I feel like it's somehow too close to the previous > tangle where too many functions did too many different things. I know what you mean.

Re: [PATCH 09/11] x86/fault: Rename no_context() to kernelmode_fixup_or_oops()

On Wed, Feb 03, 2021 at 11:53:03AM -0800, Andy Lutomirski wrote: > I feel like that would be more obfuscated — then the function would > return without fixing anything for usermode faults, return after > fixing it for kernel mode faults, or oops. You practically pretty much have it already with

Re: [PATCH 10/11] x86/fault: Don't run fixups for SMAP violations

On Sun, Jan 31, 2021 at 09:24:41AM -0800, Andy Lutomirski wrote: > A SMAP-violating kernel access is not a recoverable condition. Imagine > kernel code that, outside of a uaccess region, dereferences a pointer to > the user range by accident. If SMAP is on, this will reliably generate > as an

Re: [PATCH 07/11] x86/fault: Split the OOPS code out from no_context()

On Wed, Feb 03, 2021 at 11:29:39AM -0800, Andy Lutomirski wrote: > That function is a lie. It tries to keep the system alive but it > doesn’t return if it “recovers”. Maybe I should add a comment? ... or rename it? That schedule() at the end, I dunno if that does anything since we're going to

Re: [PATCH 09/11] x86/fault: Rename no_context() to kernelmode_fixup_or_oops()

On Sun, Jan 31, 2021 at 09:24:40AM -0800, Andy Lutomirski wrote: > The name no_context() has never been very clear. It's only called for > faults from kernel mode, so rename it and change the no-longer-useful > user_mode(regs) check to a WARN_ON_ONCE. > > Cc: Dave Hansen > Cc: Peter Zijlstra >

Re: [PATCH 07/11] x86/fault: Split the OOPS code out from no_context()

On Sun, Jan 31, 2021 at 09:24:38AM -0800, Andy Lutomirski wrote: > Not all callers of no_context() want to run exception fixups. > Separate the OOPS code out from the fixup code in no_context(). > > Cc: Dave Hansen > Cc: Peter Zijlstra > Signed-off-by: Andy Lutomirski > --- >

Re: [PATCH 06/11] x86/fault: Improve kernel-executing-user-memory handling

On Sun, Jan 31, 2021 at 09:24:37AM -0800, Andy Lutomirski wrote: > Right now we treat the case of the kernel trying to execute from user > memory more or less just like the kernel getting a page fault on a user > access. In the failure path, we check for erratum #93, try to otherwise > fix up the

Re: [PATCH 06/11] x86/fault: Improve kernel-executing-user-memory handling

On Mon, Feb 01, 2021 at 05:00:37PM -0800, Andy Lutomirski wrote: > I defer to Boris as to exactly what condition we should check here. Same as for erratum #91: https://lkml.kernel.org/r/20210201203146.gc14...@zn.tnic A single helper containing that check is probably a good idea. Thx. --

Re: [PATCH] x86/fpu: Use consistent test for X86_FEATURE_XSAVES

On Wed, Feb 03, 2021 at 07:40:07AM -0800, Dave Hansen wrote: > On 2/3/21 3:23 AM, Borislav Petkov wrote: > >> -/* > >> - * 'XSAVES' implies two different things: > >> - * 1. saving of supervisor/system state > >> - * 2. using the compacted format > >

Re: [PATCH 05/11] x86/fault: Correct a few user vs kernel checks wrt WRUSS

On Sun, Jan 31, 2021 at 09:24:36AM -0800, Andy Lutomirski wrote: > In general, page fault errors for WRUSS should be just like get_user(), > etc. Fix three bugs in this area: > > We have a comment that says that, if we can't handle a page fault on a user > address due to OOM, we will skip the

Re: [PATCH 03/11] x86/fault/32: Move is_f00f_bug() do do_kern_addr_fault()

On Sun, Jan 31, 2021 at 09:24:34AM -0800, Andy Lutomirski wrote: > Subject: Re: [PATCH 03/11] x86/fault/32: Move is_f00f_bug() do > do_kern_addr_fault() s/do /to / -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v2] arch/x86: Propagate $(CLANG_FLAGS) to $(REALMODE_FLAGS)

On Sat, Dec 26, 2020 at 05:41:25PM +0900, John Millikin wrote: > When cross-compiling with Clang, the `$(CLANG_FLAGS)' variable > contains additional flags needed to build C and assembly sources > for the target platform. Normally this variable is automatically > included in `$(KBUILD_CFLAGS)' by

Re: [PATCH] x86/tools: Use POSIX-compliant syntax for empty regex groups

On Fri, Dec 25, 2020 at 10:30:43PM +0900, John Millikin wrote: > The syntax for POSIX regexes technically doesn't allow empty branches in > conditional match groups. GNU libc accepts them as equivalent to `()', > but other libc implementations (e.g. macOS libc) reject them with a > parse error. >

Re: [PATCH v1 00/19] x86/insn: Add an insn_decode() API

On Sun, Dec 27, 2020 at 09:26:04AM -0600, Tom Lendacky wrote: > > We could also say that probably there should be a way to say "decode > > only the first insn in the buffer and ignore the rest". That is all up > > to the use cases so I'm looking for suggestions here. > > That's the way it works

Re: [PATCH] x86/fpu: Use consistent test for X86_FEATURE_XSAVES

On Tue, Feb 02, 2021 at 06:40:52PM -0800, Chang S. Bae wrote: > When XSAVES is present, the kernel always takes advantage of it, and XSAVES > always uses compacted format. > > The macro using_compacted_format() implies that using compacted format may Not a macro. > be possible without XSAVES

[tip: x86/urgent] tools/power/turbostat: Fallback to an MSR read for EPB

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: 7f1b11ba3564a391169420d98162987a12d0795d Gitweb: https://git.kernel.org/tip/7f1b11ba3564a391169420d98162987a12d0795d Author:Borislav Petkov AuthorDate:Thu, 28 Jan 2021 20:28:56 +01:00

Re: Alternative compilers to GCC/Clang

+ Micha. On Tue, Feb 02, 2021 at 10:00:39PM +0100, Willy Tarreau wrote: > On Tue, Feb 02, 2021 at 09:19:20PM +0100, Borislav Petkov wrote: > > On Tue, Feb 02, 2021 at 11:11:32AM -0800, Amy Parker wrote: > > > On Tue, Feb 2, 2021 at 8:26 AM Amy Parker wrote: > > > >

Re: [PATCH v5] x86/mce: Avoid infinite loop for copy from user recovery

On Tue, Feb 02, 2021 at 04:04:17PM +, Luck, Tony wrote: > > And the much more important question is, what is the code supposed to > > do when that overflow *actually* happens in real life? Because IINM, > > an overflow condition on the same page would mean killing the task to > > contain the

Re: Alternative compilers to GCC/Clang

On Tue, Feb 02, 2021 at 11:11:32AM -0800, Amy Parker wrote: > On Tue, Feb 2, 2021 at 8:26 AM Amy Parker wrote: > > > It compiles extremely fast, implements some subsets of gcc (a few > > > attributes for example), but is far from being able to compile a kernel > > > > Well, we'll see what I can

Re: [PATCH] Documentation/submitting-patches: Add blurb about backtraces in commit messages

On Tue, Jan 05, 2021 at 11:48:05AM +0100, Borislav Petkov wrote: > On Mon, Jan 04, 2021 at 04:19:11PM -0700, Jonathan Corbet wrote: > > So I have some questions, I guess... How often is a backtrace *in a commit > > message* really helpful at all? The value in problem r

Re: [PATCH v3 2/2] thermal: Move therm_throt there from x86/mce

On Mon, Feb 01, 2021 at 11:10:29AM -0800, Srinivas Pandruvada wrote: > Only user of the above interface is in drivers/thermal/intel. > So why can't we move these to drivers/thermal/intel/thermal_interrupt.h > or similar? Sure, see below. --- From: Borislav Petkov Date: Thu, 7 Jan 2021

Re: [PATCH] x86/ptrace: Clean up PTRACE_GETREGS/PTRACE_PUTREGS regset selection

On Thu, Jan 28, 2021 at 05:41:21PM -0800, Andy Lutomirski wrote: > task_user_regset_view() is fundamentally broken, but it's ABI for > PTRACE_GETREGSET and PTRACE_SETREGSET. > > We shouldn't be using it for PTRACE_GETREGS or PTRACE_SETREGS, No "We" etc pls. > though. A native 64-bit ptrace()

Re: [PATCH v5] x86/mce: Avoid infinite loop for copy from user recovery

On Mon, Feb 01, 2021 at 10:58:12AM -0800, Luck, Tony wrote: > On Thu, Jan 28, 2021 at 06:57:35PM +0100, Borislav Petkov wrote: > > Crazy idea: if you still can reproduce on -rc3, you could bisect: i.e., > > if you apply the patch on -rc3 and it explodes and if you apply the same &g

Re: [PATCH 01/11] x86/fault: Fix AMD erratum #91 errata fixup for user code

On Sun, Jan 31, 2021 at 09:24:32AM -0800, Andy Lutomirski wrote: > The recent rework of probe_kernel_read() and its conversion to Judging by 25f12ae45fc1 ("maccess: rename probe_kernel_address to get_kernel_nofault") I think you mean probe_kernel_address() above and below. >

Re: [PATCH V2] rtc: mc146818: Dont test for bit 0-5 in Register D

tual delta patch. Should have stayed away from > computers today > --- > drivers/rtc/rtc-cmos.c |4 ++-- > drivers/rtc/rtc-mc146818-lib.c |4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) FWIW: Reported-by: Borislav Petkov Tested-by:

Re: [PATCH v4 07/15] x86/paravirt: switch time pvops functions to use static_call()

On Wed, Jan 20, 2021 at 02:55:47PM +0100, Juergen Gross wrote: > The time pvops functions are the only ones left which might be > used in 32-bit mode and which return a 64-bit value. > > Switch them to use the static_call() mechanism instead of pvops, as > this allows quite some simplification of

[PATCH v3 2/2] thermal: Move therm_throt there from x86/mce

From: Borislav Petkov This functionality has nothing to do with MCE, move it to the thermal framework and untangle it from MCE. Requested-by: Peter Zijlstra Signed-off-by: Borislav Petkov --- arch/x86/Kconfig | 4 --- arch/x86/include/asm/mce.h

[PATCH v3 1/2] x86/mce: Get rid of mcheck_intel_therm_init()

From: Borislav Petkov Move the APIC_LVTTHMR read which needs to happen on the BSP, to intel_init_thermal(). One less boot dependency. No functional changes. Signed-off-by: Borislav Petkov --- arch/x86/include/asm/mce.h| 6 -- arch/x86/kernel/cpu/mce/core.c| 1

[PATCH v3 0/2] Move ...mce/therm_throt.c to drivers/thermal/

From: Borislav Petkov Hi, I know I already committed those but https://lkml.kernel.org/r/20210201032427.GB12524@xsang-OptiPlex-9020 made me look at the IRQ handler registration. And it does happen per CPU which is particularly daft and unneeded. And it used to do that before that change too

[GIT PULL] efi/urgent for v5.11-rc6

Hi Linus, please pull a (forwarded) single EFI urgent fix for v5.11-rc6. Thx. --- The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the Git repository at:

[GIT PULL] x86/entry for v5.11-rc6

. And a cleanup ontop. Borislav Petkov (1): x86/entry: Remove put_ret_addr_in_rdi THUNK macro argument Nick Desaulniers (1): x86/entry: Emit a symbol for register restoring thunk Documentation/asm-annotations.rst | 5 + arch/x86

Re: [PATCH v18 02/25] x86/cet/shstk: Add Kconfig option for user-mode control-flow protection

On Fri, Jan 29, 2021 at 12:33:43PM -0800, Dave Hansen wrote: > In that case is there any reason to keep the "depends on CPU_SUP_INTEL"? Probably not. I haven't heard of the AMD implementation being somehow different from Intel's. -- Regards/Gruss, Boris.

[tip: ras/core] thermal: Move therm_throt there from x86/mce

The following commit has been merged into the ras/core branch of tip: Commit-ID: 1dba8a9538f5164eb8874eed4c7d6799a3c64963 Gitweb: https://git.kernel.org/tip/1dba8a9538f5164eb8874eed4c7d6799a3c64963 Author:Borislav Petkov AuthorDate:Thu, 07 Jan 2021 13:29:05 +01:00

[tip: ras/core] x86/mce: Get rid of mcheck_intel_therm_init()

The following commit has been merged into the ras/core branch of tip: Commit-ID: b4e530ac40f25dbf07cbd37796bfcef3ec86fba8 Gitweb: https://git.kernel.org/tip/b4e530ac40f25dbf07cbd37796bfcef3ec86fba8 Author:Borislav Petkov AuthorDate:Thu, 07 Jan 2021 13:23:34 +01:00

Re: [PATCH] x86: Disable CET instrumentation in the kernel

On Fri, Jan 29, 2021 at 11:03:31AM -0600, Josh Poimboeuf wrote: > On Fri, Jan 29, 2021 at 06:54:08PM +0200, Nikolay Borisov wrote: > > > > > > On 29.01.21 г. 18:49 ч., Josh Poimboeuf wrote: > > > Agreed, stable is a good idea. I think Nikolay saw it with GCC 9. > > > > > > Yes I did, with

Re: [PATCH V3 0/6] x86: don't abuse tss.sp1

On Fri, Jan 29, 2021 at 11:35:46PM +0800, Lai Jiangshan wrote: > Any feedback? Yes: be patient please. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] x86: Disable CET instrumentation in the kernel

On Fri, Jan 29, 2021 at 09:10:34AM -0600, Josh Poimboeuf wrote: > Maybe eventually. But the enablement (actually enabling CET/CFI/etc) > happens in the arch code anyway, right? So it could be a per-arch > decision. Right. Ok, for this one, what about Cc: ? What are "some configurations of

Re: [PATCH v2] x86/debug: Fix DR6 handling

On Fri, Jan 29, 2021 at 04:41:09PM +0100, Oleg Nesterov wrote: > This seems to fix the problem reported by Jan, see his test-case below. Should it be part of tools/testing/selftests/breakpoints/ ? tglx has one destined for there already, wouldn't hurt to have a second one:

Re: [PATCH] x86: Disable CET instrumentation in the kernel

On Thu, Jan 28, 2021 at 03:52:19PM -0600, Josh Poimboeuf wrote: > > With retpolines disabled, some configurations of GCC will add Intel CET > instrumentation to the kernel by default. That breaks certain tracing > scenarios by adding a superfluous ENDBR64 instruction before the fentry > call,

Re: [PATCH v5] x86/mce: Avoid infinite loop for copy from user recovery

On Tue, Jan 26, 2021 at 02:36:05PM -0800, Luck, Tony wrote: > In some cases Linux might context switch to something else. Perhaps > this task even gets picked up by another CPU to run the task work > queued functions. But I imagine that the context switch should act > as a barrier ... shouldn't

Re: [PATCH] x86/msr: Filter msr write by X86_IOC_WRMSR_REGS ioctl

On Wed, Jan 27, 2021 at 09:24:56PM +0900, Misono Tomohiro wrote: > commit a7e1f67ed29f ("x86/msr: Filter MSR writes") introduces a > module parameter to disable writing to msr device file (and add_taint() > upon writing). As msr register can be written by X86_IOC_WRMSR_REGS > ioctl too, they

Re: [PATCH] x86/kgdb: Allow removal of early BPs

On Tue, Jan 26, 2021 at 12:39:17PM +0100, Peter Zijlstra wrote: > On Mon, Dec 14, 2020 at 03:13:12PM +0100, Stefan Saecherl wrote: > > > One thing to consider when doing this is that code can go away during boot > > (e.g. .init.text). Previously kgdb_arch_remove_breakpoint handled this case > >

<    1   2   3   4   5   6   7   8   9   10   >