* Re: [PATCH] x86/mm: fix objtool failure with KMSAN enabled [not found] <20260701125151.352632-1-voytikd@gmail.com> @ 2026-07-02 2:53 ` Borislav Petkov 2026-07-02 10:41 ` Dmitry Voytik 0 siblings, 1 reply; 6+ messages in thread From: Borislav Petkov @ 2026-07-02 2:53 UTC (permalink / raw) To: Dmitry Voytik, linux-toolchains Cc: Alexander Potapenko, Peter Zijlstra, Thomas Gleixner, Ingo Molnar, Dave Hansen, Josh Poimboeuf, Dmitry Vyukov, Andrew Morton, Ankur Arora, H . Peter Anvin, Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt, Marco Elver, x86, linux-kernel, kasan-dev, linux-mm, llvm On Wed, Jul 01, 2026 at 02:51:51PM +0200, Dmitry Voytik wrote: > This patch fixes broken builds with defconfig + CONFIG_KMSAN + > CONFIG_DEBUG_INFO_*. > > To reproduce the issue before the fix: > make mrproper > make LLVM=1 defconfig > ./scripts/config -e CONFIG_KMSAN \ > -e CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT > make LLVM=1 olddefconfig > make LLVM=1 -j(nproc) vmlinux > ... > LD vmlinux.o > vmlinux.o: warning: objtool: folio_zero_user+0x801: undefined stack state > vmlinux.o: error: objtool: folio_zero_user+0x801: unknown CFA base reg -1 > make[2]: *** [scripts/Makefile.vmlinux_o:76: vmlinux.o] Error 255 > > objtool in verbose mode shows how the frame pointer is omitted: > make LLVM=1 OBJTOOL_VERBOSE=1 -j(nproc) vmlinux > ... > b15a2c: folio_zero_user+0x7fc xor %eax,%eax > b15a2e: folio_zero_user+0x7fe mov %rcx,%rsp > b15a31: folio_zero_user+0x801 mov %r14,%rdi > b15a34: folio_zero_user+0x804 mov %rbx,%rcx > b15a37: folio_zero_user+0x807 call 0xb15a3c <__clear_pages_unrol > > After the fix, the frame pointer is back: > b15a37: 31 c0 xor %eax,%eax > b15a39: 48 89 ec mov %rbp,%rsp > b15a3c: 4c 89 f7 mov %r14,%rdi > b15a3f: 48 89 d9 mov %rbx,%rcx > b15a42: e8 00 00 00 00 call b15a47 <folio_zero_user+0x817> > > It seems the issue was introduced by > commit 54a6b89a3db2 ("x86/mm: simplify clear_page_*") > > The actual fix is to revert the change how ASM_CALL_CONSTRAINT is > positioned. Why? Where does it say that the current stack ptr dependency needs to be the first asm input operand? If that were the case, we have a bunch more of those bugs around the tree. Anyway, + linux-toolchains. > Additionally, reintroduce asm_inline to prevent potential compiler > rejection of inlining. > > Link: https://lore.kernel.org/CAAX90H2_RPnZL_dFYN7cQF6yt-wAweKKSx2=6e2aZ0kv+Pm+NQ@mail.gmail.com > Signed-off-by: Dmitry Voytik <voytikd@gmail.com> > --- > arch/x86/include/asm/page_64.h | 13 +++++++------ > 1 file changed, 7 insertions(+), 6 deletions(-) > > diff --git a/arch/x86/include/asm/page_64.h b/arch/x86/include/asm/page_64.h > index 1895c207f629..de8604f0a3a1 100644 > --- a/arch/x86/include/asm/page_64.h > +++ b/arch/x86/include/asm/page_64.h > @@ -100,12 +100,13 @@ static inline void clear_pages(void *addr, unsigned int npages) > * __clear_pages_unrolled() are part of the inline asm register > * specification. > */ > - asm volatile(ALTERNATIVE_2("call __clear_pages_unrolled", > - "shrq $3, %%rcx; rep stosq", X86_FEATURE_REP_GOOD, > - "rep stosb", X86_FEATURE_ERMS) > - : "+c" (len), "+D" (addr), ASM_CALL_CONSTRAINT > - : "a" (0) > - : "cc", "memory"); > + asm_inline volatile( > + ALTERNATIVE_2("call __clear_pages_unrolled", > + "shrq $3, %%rcx; rep stosq", X86_FEATURE_REP_GOOD, > + "rep stosb", X86_FEATURE_ERMS) > + : ASM_CALL_CONSTRAINT, "+c"(len), "+D"(addr) > + : "a"(0) > + : "cc", "memory"); > } > #define clear_pages clear_pages -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] x86/mm: fix objtool failure with KMSAN enabled 2026-07-02 2:53 ` [PATCH] x86/mm: fix objtool failure with KMSAN enabled Borislav Petkov @ 2026-07-02 10:41 ` Dmitry Voytik 2026-07-02 11:15 ` Peter Zijlstra 0 siblings, 1 reply; 6+ messages in thread From: Dmitry Voytik @ 2026-07-02 10:41 UTC (permalink / raw) To: Borislav Petkov Cc: linux-toolchains, Alexander Potapenko, Peter Zijlstra, Thomas Gleixner, Ingo Molnar, Dave Hansen, Josh Poimboeuf, Dmitry Vyukov, Andrew Morton, Ankur Arora, H . Peter Anvin, Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt, Marco Elver, x86, linux-kernel, kasan-dev, linux-mm, llvm Hi Borislav, On Thu, Jul 2, 2026 at 4:54 AM Borislav Petkov <bp@alien8.de> wrote: > > On Wed, Jul 01, 2026 at 02:51:51PM +0200, Dmitry Voytik wrote: > > This patch fixes broken builds with defconfig + CONFIG_KMSAN + > > CONFIG_DEBUG_INFO_*. > > > > To reproduce the issue before the fix: > > make mrproper > > make LLVM=1 defconfig > > ./scripts/config -e CONFIG_KMSAN \ > > -e CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT > > make LLVM=1 olddefconfig > > make LLVM=1 -j(nproc) vmlinux > > ... > > LD vmlinux.o > > vmlinux.o: warning: objtool: folio_zero_user+0x801: undefined stack state > > vmlinux.o: error: objtool: folio_zero_user+0x801: unknown CFA base reg -1 > > make[2]: *** [scripts/Makefile.vmlinux_o:76: vmlinux.o] Error 255 > > > > objtool in verbose mode shows how the frame pointer is omitted: > > make LLVM=1 OBJTOOL_VERBOSE=1 -j(nproc) vmlinux > > ... > > b15a2c: folio_zero_user+0x7fc xor %eax,%eax > > b15a2e: folio_zero_user+0x7fe mov %rcx,%rsp > > b15a31: folio_zero_user+0x801 mov %r14,%rdi > > b15a34: folio_zero_user+0x804 mov %rbx,%rcx > > b15a37: folio_zero_user+0x807 call 0xb15a3c <__clear_pages_unrol > > > > After the fix, the frame pointer is back: > > b15a37: 31 c0 xor %eax,%eax > > b15a39: 48 89 ec mov %rbp,%rsp > > b15a3c: 4c 89 f7 mov %r14,%rdi > > b15a3f: 48 89 d9 mov %rbx,%rcx > > b15a42: e8 00 00 00 00 call b15a47 <folio_zero_user+0x817> > > > > It seems the issue was introduced by > > commit 54a6b89a3db2 ("x86/mm: simplify clear_page_*") > > > > The actual fix is to revert the change how ASM_CALL_CONSTRAINT is > > positioned. > > Why? > > Where does it say that the current stack ptr dependency needs to be the first > asm input operand? Very good question. My uneducated guess - bugs in clang. Out of curiosity, I compared (see below) what clang and gcc do when ASM_CALL_CONSTRAINT moves around, and it indeed affects generated code, which is weird. I might just be holding it wrong, like optimization must be on, etc. > If that were the case, we have a bunch more of those bugs around the tree. At least, it makes objtool happy for the defconfig + KMSAN. > Anyway, + linux-toolchains. Thanks for looking into this. Comparing clang and gcc: // clang asm_clang.c -o out // gcc asm_clang.c -o out // objdump -d --disassemble=main out #include <stdio.h> int func() { return 42; } #define __stringify_1(x...) #x #define __stringify(x...) __stringify_1(x) # define __ASM_FORM_RAW(x, ...) __stringify(x,##__VA_ARGS__) # define __ASM_SEL_RAW(a,b) __ASM_FORM_RAW(b) #define __ASM_REG(reg) __ASM_SEL_RAW(e##reg, r##reg) #define _ASM_SP __ASM_REG(sp) register unsigned long current_stack_pointer asm(_ASM_SP); #define ASM_CALL_CONSTRAINT "+r" (current_stack_pointer) int main() { int output_val = 0; __asm__ __volatile__ ( "call func\n\t" : "=a" (output_val) : :); // clang v22.1.6 // 1142: e8 d9 ff ff ff call 1120 <func> // 1147: 89 45 f8 mov %eax,-0x8(%rbp) // gcc: // 112f: e8 e5 ff ff ff call 1119 <func> // 1134: 89 45 fc mov %eax,-0x4(%rbp) __asm__ __volatile__ ( "call func\n\t" : ASM_CALL_CONSTRAINT, "=a" (output_val) : :); // clang v22.1.6 // 114a: 48 89 e0 mov %rsp,%rax // 114d: 48 89 c4 mov %rax,%rsp // 1150: e8 cb ff ff ff call 1120 <func> // 1155: 48 89 e1 mov %rsp,%rcx // 1158: 48 89 cc mov %rcx,%rsp // 115b: 89 45 f8 mov %eax,-0x8(%rbp) // gcc: // 1137: e8 dd ff ff ff call 1119 <func> // 113c: 89 45 fc mov %eax,-0x4(%rbp) __asm__ __volatile__ ( "call func\n\t" : "=a" (output_val), ASM_CALL_CONSTRAINT : :); // clang v22.1.6 // 115e: 48 89 e0 mov %rsp,%rax // 1161: 48 89 c4 mov %rax,%rsp // 1164: e8 b7 ff ff ff call 1120 <func> // 1169: 89 c1 mov %eax,%ecx // 116b: 48 89 e0 mov %rsp,%rax // 116e: 89 4d f8 mov %ecx,-0x8(%rbp) // 1171: 48 89 c4 mov %rax,%rsp // gcc: // 113f: e8 d5 ff ff ff call 1119 <func> // 1144: 89 45 fc mov %eax,-0x4(%rbp) return 0; } > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] x86/mm: fix objtool failure with KMSAN enabled 2026-07-02 10:41 ` Dmitry Voytik @ 2026-07-02 11:15 ` Peter Zijlstra 2026-07-02 19:46 ` Thomas Gleixner 0 siblings, 1 reply; 6+ messages in thread From: Peter Zijlstra @ 2026-07-02 11:15 UTC (permalink / raw) To: Dmitry Voytik Cc: Borislav Petkov, linux-toolchains, Alexander Potapenko, Thomas Gleixner, Ingo Molnar, Dave Hansen, Josh Poimboeuf, Dmitry Vyukov, Andrew Morton, Ankur Arora, H . Peter Anvin, Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt, Marco Elver, x86, linux-kernel, kasan-dev, linux-mm, llvm On Thu, Jul 02, 2026 at 12:41:09PM +0200, Dmitry Voytik wrote: > Hi Borislav, > > On Thu, Jul 2, 2026 at 4:54 AM Borislav Petkov <bp@alien8.de> wrote: > > > > On Wed, Jul 01, 2026 at 02:51:51PM +0200, Dmitry Voytik wrote: > > > This patch fixes broken builds with defconfig + CONFIG_KMSAN + > > > CONFIG_DEBUG_INFO_*. > > > > > > To reproduce the issue before the fix: > > > make mrproper > > > make LLVM=1 defconfig > > > ./scripts/config -e CONFIG_KMSAN \ > > > -e CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT > > > make LLVM=1 olddefconfig > > > make LLVM=1 -j(nproc) vmlinux > > > ... > > > LD vmlinux.o > > > vmlinux.o: warning: objtool: folio_zero_user+0x801: undefined stack state > > > vmlinux.o: error: objtool: folio_zero_user+0x801: unknown CFA base reg -1 > > > make[2]: *** [scripts/Makefile.vmlinux_o:76: vmlinux.o] Error 255 > > > > > > objtool in verbose mode shows how the frame pointer is omitted: > > > make LLVM=1 OBJTOOL_VERBOSE=1 -j(nproc) vmlinux > > > ... > > > b15a2c: folio_zero_user+0x7fc xor %eax,%eax > > > b15a2e: folio_zero_user+0x7fe mov %rcx,%rsp > > > b15a31: folio_zero_user+0x801 mov %r14,%rdi > > > b15a34: folio_zero_user+0x804 mov %rbx,%rcx > > > b15a37: folio_zero_user+0x807 call 0xb15a3c <__clear_pages_unrol > > > > > > After the fix, the frame pointer is back: > > > b15a37: 31 c0 xor %eax,%eax > > > b15a39: 48 89 ec mov %rbp,%rsp > > > b15a3c: 4c 89 f7 mov %r14,%rdi > > > b15a3f: 48 89 d9 mov %rbx,%rcx > > > b15a42: e8 00 00 00 00 call b15a47 <folio_zero_user+0x817> > > > > > > It seems the issue was introduced by > > > commit 54a6b89a3db2 ("x86/mm: simplify clear_page_*") > > > > > > The actual fix is to revert the change how ASM_CALL_CONSTRAINT is > > > positioned. > > > > Why? > > > > Where does it say that the current stack ptr dependency needs to be the first > > asm input operand? > > Very good question. My uneducated guess - bugs in clang. > Out of curiosity, I compared (see below) what clang and gcc do when > ASM_CALL_CONSTRAINT moves around, and it indeed affects generated > code, which is weird. > I might just be holding it wrong, like optimization must be on, etc. > > > If that were the case, we have a bunch more of those bugs around the tree. > > At least, it makes objtool happy for the defconfig + KMSAN. Yeah, for all the wrong reasons. AFAICT it is one clang bug causing another clang bug to manifest less onerous. This ASM_CALL_CONSTRAINT placement is, for some reason, forcing a stack frame (which is not in fact required), but having a stack frame then avoids the absolutely retarded: mov %rsp, %rcx; 1: mov %rcx, %rsp ... mov %rsp, disp(%rsp) call __msam_foo mov disp(%rsp), %rcx test je 1b construct. Becaus having the stack frame (rbp) then makes all the rsp juggling less of a problem. So on the one hand the __msan 'functions' are special annotated in clang to force re-align the stack. Then it notices the stack is already properly aligned and the actual stack alignment code goes missing, BUT it keeps the save/restore rsp (for raisins). It then furher compounds the failure by spilling the RSP copy onto the stack, and voila, total and utter insanity. I suspect you can simply remove that magic annotate for KMSAM, kernel stacks are always aligned, there no point, what-so-ever, to do the whole save/align/restore thing. There is also this thread from last year, which looks to be a similar/same problem: https://lore.kernel.org/174108458405.14745.4864877018394987266.tip-bot2@tip-bot2 those patches never made it in, Josh was going to rework, but that never quite happened either. And I think we need to, at least temporarily, deal with this, until a fixed clang is released and we can make KMSAN depend on that version, but I worry about the impact of this change on !KMSAN builds. A quick test with folio_zero_user() seems to suggest the ASM_CALL_CONSTRAINT movement (your patch) generates the same code for defconfg as does the unmodified code. The change from the thread linked above (input constraint on __builtin_frame_address(0)) generates different code. A third option is to force FRAME_POINTER=y for KMSAN builds -- for now, until clang is taught to be less insane. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] x86/mm: fix objtool failure with KMSAN enabled 2026-07-02 11:15 ` Peter Zijlstra @ 2026-07-02 19:46 ` Thomas Gleixner 2026-07-02 20:05 ` Thomas Gleixner 0 siblings, 1 reply; 6+ messages in thread From: Thomas Gleixner @ 2026-07-02 19:46 UTC (permalink / raw) To: Peter Zijlstra, Dmitry Voytik Cc: Borislav Petkov, linux-toolchains, Alexander Potapenko, Ingo Molnar, Dave Hansen, Josh Poimboeuf, Dmitry Vyukov, Andrew Morton, Ankur Arora, H . Peter Anvin, Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt, Marco Elver, x86, linux-kernel, kasan-dev, linux-mm, llvm On Thu, Jul 02 2026 at 13:15, Peter Zijlstra wrote: > A quick test with folio_zero_user() seems to suggest the > ASM_CALL_CONSTRAINT movement (your patch) generates the same code for > defconfg as does the unmodified code. The change from the thread linked > above (input constraint on __builtin_frame_address(0)) generates > different code. > > A third option is to force FRAME_POINTER=y for KMSAN builds -- for now, > until clang is taught to be less insane. With FRAME_POINTER=y I get now with clang-22 vmlinux.o: warning: objtool: folio_zero_user+0xa7b: stack state mismatch: reg1[4]=-1+0 reg2[4]=-2-336 vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x64: relocation to !ENDBR: machine_kexec_prepare+0x8f0 That's with your objtool patch applied. When I remove that then the folio_zero_user one goes away. The relocation to !ENDBR stays. Oh well... ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] x86/mm: fix objtool failure with KMSAN enabled 2026-07-02 19:46 ` Thomas Gleixner @ 2026-07-02 20:05 ` Thomas Gleixner 2026-07-03 10:34 ` Dmitry Voytik 0 siblings, 1 reply; 6+ messages in thread From: Thomas Gleixner @ 2026-07-02 20:05 UTC (permalink / raw) To: Peter Zijlstra, Dmitry Voytik Cc: Borislav Petkov, linux-toolchains, Alexander Potapenko, Ingo Molnar, Dave Hansen, Josh Poimboeuf, Dmitry Vyukov, Andrew Morton, Ankur Arora, H . Peter Anvin, Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt, Marco Elver, x86, linux-kernel, kasan-dev, linux-mm, llvm On Thu, Jul 02 2026 at 21:46, Thomas Gleixner wrote: > On Thu, Jul 02 2026 at 13:15, Peter Zijlstra wrote: >> A quick test with folio_zero_user() seems to suggest the >> ASM_CALL_CONSTRAINT movement (your patch) generates the same code for >> defconfg as does the unmodified code. The change from the thread linked >> above (input constraint on __builtin_frame_address(0)) generates >> different code. >> >> A third option is to force FRAME_POINTER=y for KMSAN builds -- for now, >> until clang is taught to be less insane. > > With FRAME_POINTER=y I get now with clang-22 > > vmlinux.o: warning: objtool: folio_zero_user+0xa7b: stack state mismatch: reg1[4]=-1+0 reg2[4]=-2-336 > vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x64: relocation to !ENDBR: machine_kexec_prepare+0x8f0 > > That's with your objtool patch applied. When I remove that then the > folio_zero_user one goes away. The relocation to !ENDBR stays. > > Oh well... And none of this boots when KMSAN=y .... ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] x86/mm: fix objtool failure with KMSAN enabled 2026-07-02 20:05 ` Thomas Gleixner @ 2026-07-03 10:34 ` Dmitry Voytik 0 siblings, 0 replies; 6+ messages in thread From: Dmitry Voytik @ 2026-07-03 10:34 UTC (permalink / raw) To: Thomas Gleixner Cc: Peter Zijlstra, Borislav Petkov, linux-toolchains, Alexander Potapenko, Ingo Molnar, Dave Hansen, Josh Poimboeuf, Dmitry Vyukov, Andrew Morton, Ankur Arora, H . Peter Anvin, Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt, Marco Elver, x86, linux-kernel, kasan-dev, linux-mm, llvm Hi Thomas, On Thu, Jul 2, 2026 at 10:05 PM Thomas Gleixner <tglx@kernel.org> wrote: > > On Thu, Jul 02 2026 at 21:46, Thomas Gleixner wrote: > > On Thu, Jul 02 2026 at 13:15, Peter Zijlstra wrote: > >> A quick test with folio_zero_user() seems to suggest the > >> ASM_CALL_CONSTRAINT movement (your patch) generates the same code for > >> defconfg as does the unmodified code. The change from the thread linked > >> above (input constraint on __builtin_frame_address(0)) generates > >> different code. > >> > >> A third option is to force FRAME_POINTER=y for KMSAN builds -- for now, > >> until clang is taught to be less insane. > > > > With FRAME_POINTER=y I get now with clang-22 > > > > vmlinux.o: warning: objtool: folio_zero_user+0xa7b: stack state mismatch: reg1[4]=-1+0 reg2[4]=-2-336 > > vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x64: relocation to !ENDBR: machine_kexec_prepare+0x8f0 > > > > That's with your objtool patch applied. When I remove that then the > > folio_zero_user one goes away. The relocation to !ENDBR stays. > > > > Oh well... > > And none of this boots when KMSAN=y .... Thanks for checking this! I wonder if we are debugging clang here because I just retested the patch with CONFIG_FRAME_POINTER on the current Linus' tree and it works in my env: clang --version clang version 22.1.6 git pull -r git show -s --oneline -2 21f3d2b2069e (HEAD -> master) x86/mm: fix objtool failure with KMSAN enabled d2c9a99135da (origin/master, origin/HEAD) Merge tag 'device-id-rework' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux make mrproper make LLVM=1 defconfig ./scripts/config \ -e CONFIG_KMSAN \ -e CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT \ -e UNWINDER_FRAME_POINTER make LLVM=1 olddefconfig make LLVM=1 W=ce -j(nproc) bzImage grep -e CONFIG_KMSAN= -e CONFIG_FRAME_POINTER \ -e CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT .config CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y CONFIG_FRAME_POINTER=y CONFIG_KMSAN=y qemu-system-x86_64 \ -kernel arch/x86/boot/bzImage \ -accel kvm \ -append "console=ttyS0" \ -nographic \ -m 8G -smp 4 \ -serial file:serial_out.log grep -e 'Linux version' -A1 -e KernelMemorySanitizer -e 'append a correct' serial_out.log [ 0.000000] Linux version 7.2.0-rc1-00009-gb0b29f0286be (voyt@voyt-laptop-dell) (clang version 22.1.6, LLD 22.1.6) #1 SMP PREEMPT_DYNAMIC Fri Jul 3 11:55:02 CEST 2026 [ 0.000000] Command line: console=ttyS0 -- [ 0.218380] Starting KernelMemorySanitizer [ 0.218382] ATTENTION: KMSAN is a debugging tool! Do not use it on production machines! -- [ 4.037384] Please append a correct "root=" boot option; here are the available partitions: [ 4.037772] 0b00 1048575 sr0 Could another CONFIG_ be the culprit on your side? Or, has your clang version some different (buggy?) behaviour? ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-07-03 10:34 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20260701125151.352632-1-voytikd@gmail.com>
2026-07-02 2:53 ` [PATCH] x86/mm: fix objtool failure with KMSAN enabled Borislav Petkov
2026-07-02 10:41 ` Dmitry Voytik
2026-07-02 11:15 ` Peter Zijlstra
2026-07-02 19:46 ` Thomas Gleixner
2026-07-02 20:05 ` Thomas Gleixner
2026-07-03 10:34 ` Dmitry Voytik
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox