* [PATCH 0/3] objtool: Few x86 decoder updates
@ 2025-09-24 13:45 Peter Zijlstra
2025-09-24 13:45 ` [PATCH 1/3] objtool/x86: Remove 0xea hack Peter Zijlstra
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: Peter Zijlstra @ 2025-09-24 13:45 UTC (permalink / raw)
To: jpoimboe, x86; +Cc: linux-kernel, peterz, alexandre.chartre
Hi,
few patches that update the 0xea/udb situation and fix up the x86_64 NOP
decoding.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 1/3] objtool/x86: Remove 0xea hack
2025-09-24 13:45 [PATCH 0/3] objtool: Few x86 decoder updates Peter Zijlstra
@ 2025-09-24 13:45 ` Peter Zijlstra
2025-09-25 9:55 ` Alexandre Chartre
2025-10-14 11:47 ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
2025-09-24 13:45 ` [PATCH 2/3] objtool/x86: Add UDB support Peter Zijlstra
2025-09-24 13:45 ` [PATCH 3/3] objtool/x86: Fix NOP decode Peter Zijlstra
2 siblings, 2 replies; 19+ messages in thread
From: Peter Zijlstra @ 2025-09-24 13:45 UTC (permalink / raw)
To: jpoimboe, x86; +Cc: linux-kernel, peterz, alexandre.chartre
Was properly fixed in the decoder with commit 4b626015e1bf ("x86/insn:
Stop decoding i64 instructions in x86-64 mode at opcode")
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
tools/objtool/arch/x86/decode.c | 9 ---------
1 file changed, 9 deletions(-)
--- a/tools/objtool/arch/x86/decode.c
+++ b/tools/objtool/arch/x86/decode.c
@@ -189,15 +189,6 @@ int arch_decode_instruction(struct objto
op2 = ins.opcode.bytes[1];
op3 = ins.opcode.bytes[2];
- /*
- * XXX hack, decoder is buggered and thinks 0xea is 7 bytes long.
- */
- if (op1 == 0xea) {
- insn->len = 1;
- insn->type = INSN_BUG;
- return 0;
- }
-
if (ins.rex_prefix.nbytes) {
rex = ins.rex_prefix.bytes[0];
rex_w = X86_REX_W(rex) >> 3;
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 2/3] objtool/x86: Add UDB support
2025-09-24 13:45 [PATCH 0/3] objtool: Few x86 decoder updates Peter Zijlstra
2025-09-24 13:45 ` [PATCH 1/3] objtool/x86: Remove 0xea hack Peter Zijlstra
@ 2025-09-24 13:45 ` Peter Zijlstra
2025-09-25 9:56 ` Alexandre Chartre
2025-10-14 11:47 ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
2025-09-24 13:45 ` [PATCH 3/3] objtool/x86: Fix NOP decode Peter Zijlstra
2 siblings, 2 replies; 19+ messages in thread
From: Peter Zijlstra @ 2025-09-24 13:45 UTC (permalink / raw)
To: jpoimboe, x86; +Cc: linux-kernel, peterz, alexandre.chartre
Per commit 85a2d4a890dc ("x86,ibt: Use UDB instead of 0xEA"), make
sure objtool also recognises UDB as a #UD instruction.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
tools/objtool/arch/x86/decode.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/tools/objtool/arch/x86/decode.c
+++ b/tools/objtool/arch/x86/decode.c
@@ -683,6 +683,10 @@ int arch_decode_instruction(struct objto
insn->type = INSN_SYSRET;
break;
+ case 0xd6: /* udb */
+ insn->type = INSN_BUG;
+ break;
+
case 0xe0: /* loopne */
case 0xe1: /* loope */
case 0xe2: /* loop */
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 3/3] objtool/x86: Fix NOP decode
2025-09-24 13:45 [PATCH 0/3] objtool: Few x86 decoder updates Peter Zijlstra
2025-09-24 13:45 ` [PATCH 1/3] objtool/x86: Remove 0xea hack Peter Zijlstra
2025-09-24 13:45 ` [PATCH 2/3] objtool/x86: Add UDB support Peter Zijlstra
@ 2025-09-24 13:45 ` Peter Zijlstra
2025-09-24 17:34 ` Alexandre Chartre
2025-10-14 11:47 ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
2 siblings, 2 replies; 19+ messages in thread
From: Peter Zijlstra @ 2025-09-24 13:45 UTC (permalink / raw)
To: jpoimboe, x86; +Cc: linux-kernel, peterz, alexandre.chartre
For x86_64 the kernel consistently uses 2 instructions for all NOPs:
90 - NOP
0f 1f /0 - NOPL
Notably:
- REP NOP is PAUSE, not a NOP instruction.
- 0f {0c...0f} is reserved space,
except for 0f 0d /1, which is PREFETCHW, not a NOP.
- 0f {19,1c...1f} is reserved space,
except for 0f 1f /0, which is NOPL.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
tools/objtool/arch/x86/decode.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
--- a/tools/objtool/arch/x86/decode.c
+++ b/tools/objtool/arch/x86/decode.c
@@ -494,7 +494,8 @@ int arch_decode_instruction(struct objto
break;
case 0x90:
- insn->type = INSN_NOP;
+ if (prefix != 0xf3) /* REP NOP := PAUSE */
+ insn->type = INSN_NOP;
break;
case 0x9c:
@@ -547,13 +548,14 @@ int arch_decode_instruction(struct objto
} else if (op2 == 0x0b || op2 == 0xb9) {
- /* ud2 */
+ /* ud2, ud1 */
insn->type = INSN_BUG;
- } else if (op2 == 0x0d || op2 == 0x1f) {
+ } else if (op2 == 0x1f) {
- /* nopl/nopw */
- insn->type = INSN_NOP;
+ /* 0f 1f /0 := NOPL */
+ if (modrm_reg == 0)
+ insn->type = INSN_NOP;
} else if (op2 == 0x1e) {
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] objtool/x86: Fix NOP decode
2025-09-24 13:45 ` [PATCH 3/3] objtool/x86: Fix NOP decode Peter Zijlstra
@ 2025-09-24 17:34 ` Alexandre Chartre
2025-09-24 18:41 ` Peter Zijlstra
2025-10-14 11:47 ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
1 sibling, 1 reply; 19+ messages in thread
From: Alexandre Chartre @ 2025-09-24 17:34 UTC (permalink / raw)
To: Peter Zijlstra, jpoimboe, x86; +Cc: alexandre.chartre, linux-kernel
On 9/24/25 15:45, Peter Zijlstra wrote:
> For x86_64 the kernel consistently uses 2 instructions for all NOPs:
>
> 90 - NOP
> 0f 1f /0 - NOPL
>
>
> Notably:
>
> - REP NOP is PAUSE, not a NOP instruction.
>
> - 0f {0c...0f} is reserved space,
> except for 0f 0d /1, which is PREFETCHW, not a NOP.
>
> - 0f {19,1c...1f} is reserved space,
> except for 0f 1f /0, which is NOPL.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
> tools/objtool/arch/x86/decode.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> --- a/tools/objtool/arch/x86/decode.c
> +++ b/tools/objtool/arch/x86/decode.c
> @@ -494,7 +494,8 @@ int arch_decode_instruction(struct objto
> break;
>
> case 0x90:
> - insn->type = INSN_NOP;
> + if (prefix != 0xf3) /* REP NOP := PAUSE */
> + insn->type = INSN_NOP;
> break;
So this covers NOP1 (0x90) and NOP2 (0x66 0x90), right?
>
> case 0x9c:
> @@ -547,13 +548,14 @@ int arch_decode_instruction(struct objto
>
> } else if (op2 == 0x0b || op2 == 0xb9) {
>
> - /* ud2 */
> + /* ud2, ud1 */
> insn->type = INSN_BUG;
>
> - } else if (op2 == 0x0d || op2 == 0x1f) {
> + } else if (op2 == 0x1f) {
>
> - /* nopl/nopw */
> - insn->type = INSN_NOP;
> + /* 0f 1f /0 := NOPL */
> + if (modrm_reg == 0)
> + insn->type = INSN_NOP;
>
> } else if (op2 == 0x1e) {
>
And this covers all other NOPs (0x0f 0x1f ...), including NOP6 which has
a 0x66 preifx (0x66 0xf 0x1f ...) ?
From arch/x86/include/asm/nops.h we have:
/*
* Generic 64bit nops from GAS:
*
* 1: nop
* 2: osp nop
* 3: nopl (%eax)
* 4: nopl 0x00(%eax)
* 5: nopl 0x00(%eax,%eax,1)
* 6: osp nopl 0x00(%eax,%eax,1)
* 7: nopl 0x00000000(%eax)
* 8: nopl 0x00000000(%eax,%eax,1)
*/
#define BYTES_NOP1 0x90
#define BYTES_NOP2 0x66,BYTES_NOP1
#define BYTES_NOP3 0x0f,0x1f,0x00
#define BYTES_NOP4 0x0f,0x1f,0x40,0x00
#define BYTES_NOP5 0x0f,0x1f,0x44,0x00,0x00
#define BYTES_NOP6 0x66,BYTES_NOP5
#define BYTES_NOP7 0x0f,0x1f,0x80,0x00,0x00,0x00,0x00
#define BYTES_NOP8 0x0f,0x1f,0x84,0x00,0x00,0x00,0x00,0x00
alex.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] objtool/x86: Fix NOP decode
2025-09-24 17:34 ` Alexandre Chartre
@ 2025-09-24 18:41 ` Peter Zijlstra
2025-09-25 9:55 ` Alexandre Chartre
0 siblings, 1 reply; 19+ messages in thread
From: Peter Zijlstra @ 2025-09-24 18:41 UTC (permalink / raw)
To: Alexandre Chartre; +Cc: jpoimboe, x86, linux-kernel
On Wed, Sep 24, 2025 at 07:34:00PM +0200, Alexandre Chartre wrote:
>
> On 9/24/25 15:45, Peter Zijlstra wrote:
> > For x86_64 the kernel consistently uses 2 instructions for all NOPs:
> >
> > 90 - NOP
> > 0f 1f /0 - NOPL
> >
> >
> > Notably:
> >
> > - REP NOP is PAUSE, not a NOP instruction.
> >
> > - 0f {0c...0f} is reserved space,
> > except for 0f 0d /1, which is PREFETCHW, not a NOP.
> >
> > - 0f {19,1c...1f} is reserved space,
> > except for 0f 1f /0, which is NOPL.
> >
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > ---
> > tools/objtool/arch/x86/decode.c | 12 +++++++-----
> > 1 file changed, 7 insertions(+), 5 deletions(-)
> >
> > --- a/tools/objtool/arch/x86/decode.c
> > +++ b/tools/objtool/arch/x86/decode.c
> > @@ -494,7 +494,8 @@ int arch_decode_instruction(struct objto
> > break;
> > case 0x90:
> > + if (prefix != 0xf3) /* REP NOP := PAUSE */
> > + insn->type = INSN_NOP;
> > break;
>
> So this covers NOP1 (0x90) and NOP2 (0x66 0x90), right?
Yes. Everything with opcode 0x90, except 0xf3 0x90, which as stated is
PAUSE.
> > case 0x9c:
> > @@ -547,13 +548,14 @@ int arch_decode_instruction(struct objto
> > } else if (op2 == 0x0b || op2 == 0xb9) {
> > + /* ud2, ud1 */
> > insn->type = INSN_BUG;
> > + } else if (op2 == 0x1f) {
> > + /* 0f 1f /0 := NOPL */
> > + if (modrm_reg == 0)
> > + insn->type = INSN_NOP;
> > } else if (op2 == 0x1e) {
>
> And this covers all other NOPs (0x0f 0x1f ...), including NOP6 which has
> a 0x66 preifx (0x66 0xf 0x1f ...) ?
Sorta, it accepts everything with opcode 0f 1f and modrm_reg==0, which is
how NOPL is encoded.
Both: 66 66 66 66 66 66 66 66 66 66 66 66 66 66 90 (NOP15)
And: 66 66 66 66 66 66 66 0f 1f 84 00 00 00 00 00 (NOP15)
will be accepted here as max length instructions. The kernel will not
actually use those, since a bunch of micro archs have decode penalties
for too many prefixes.
> From arch/x86/include/asm/nops.h we have:
You're looking at old code :-)
> /*
> * Generic 64bit nops from GAS:
> *
> * 1: nop
> * 2: osp nop
> * 3: nopl (%eax)
> * 4: nopl 0x00(%eax)
> * 5: nopl 0x00(%eax,%eax,1)
> * 6: osp nopl 0x00(%eax,%eax,1)
> * 7: nopl 0x00000000(%eax)
> * 8: nopl 0x00000000(%eax,%eax,1)
* 9: cs nopl 0x00000000(%eax,%eax,1)
* 10: osp cs nopl 0x00000000(%eax,%eax,1)
* 11: osp osp cs nopl 0x00000000(%eax,%eax,1)
> */
> #define BYTES_NOP1 0x90
> #define BYTES_NOP2 0x66,BYTES_NOP1
> #define BYTES_NOP3 0x0f,0x1f,0x00
> #define BYTES_NOP4 0x0f,0x1f,0x40,0x00
> #define BYTES_NOP5 0x0f,0x1f,0x44,0x00,0x00
> #define BYTES_NOP6 0x66,BYTES_NOP5
> #define BYTES_NOP7 0x0f,0x1f,0x80,0x00,0x00,0x00,0x00
> #define BYTES_NOP8 0x0f,0x1f,0x84,0x00,0x00,0x00,0x00,0x00
#define BYTES_NOP9 0x2e,BYTES_NOP8
#define BYTES_NOP10 0x66,BYTES_NOP9
#define BYTES_NOP11 0x66,BYTES_NOP10
But yes, first two are NOP and then it switches to NOPL for 3 bytes and
longer (2 opcode, 1 modrm). Where for 11 bytes we have:
- 3 prefixes
- 2 opcode
- 1 modrm
- 1 sib
- 4 displacement
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] objtool/x86: Fix NOP decode
2025-09-24 18:41 ` Peter Zijlstra
@ 2025-09-25 9:55 ` Alexandre Chartre
2025-09-25 10:03 ` Peter Zijlstra
0 siblings, 1 reply; 19+ messages in thread
From: Alexandre Chartre @ 2025-09-25 9:55 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: alexandre.chartre, jpoimboe, x86, linux-kernel
On 9/24/25 20:41, Peter Zijlstra wrote:
> On Wed, Sep 24, 2025 at 07:34:00PM +0200, Alexandre Chartre wrote:
>>
>> On 9/24/25 15:45, Peter Zijlstra wrote:
>>> For x86_64 the kernel consistently uses 2 instructions for all NOPs:
>>>
>>> 90 - NOP
>>> 0f 1f /0 - NOPL
>>>
>>>
>>> Notably:
>>>
>>> - REP NOP is PAUSE, not a NOP instruction.
>>>
>>> - 0f {0c...0f} is reserved space,
>>> except for 0f 0d /1, which is PREFETCHW, not a NOP.
>>>
>>> - 0f {19,1c...1f} is reserved space,
>>> except for 0f 1f /0, which is NOPL.
>>>
>>> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>>> ---
>>> tools/objtool/arch/x86/decode.c | 12 +++++++-----
>>> 1 file changed, 7 insertions(+), 5 deletions(-)
>>>
>>> --- a/tools/objtool/arch/x86/decode.c
>>> +++ b/tools/objtool/arch/x86/decode.c
>>> @@ -494,7 +494,8 @@ int arch_decode_instruction(struct objto
>>> break;
>>> case 0x90:
>>> + if (prefix != 0xf3) /* REP NOP := PAUSE */
>>> + insn->type = INSN_NOP;
>>> break;
>>
>> So this covers NOP1 (0x90) and NOP2 (0x66 0x90), right?
>
> Yes. Everything with opcode 0x90, except 0xf3 0x90, which as stated is
> PAUSE.
>
What about 0x49 0x90, which is xchg (XCHG r8,rAX) ?
>>> case 0x9c:
>>> @@ -547,13 +548,14 @@ int arch_decode_instruction(struct objto
>>> } else if (op2 == 0x0b || op2 == 0xb9) {
>>> + /* ud2, ud1 */
>>> insn->type = INSN_BUG;
>>> + } else if (op2 == 0x1f) {
>>> + /* 0f 1f /0 := NOPL */
>>> + if (modrm_reg == 0)
>>> + insn->type = INSN_NOP;
>>> } else if (op2 == 0x1e) {
>>
>> And this covers all other NOPs (0x0f 0x1f ...), including NOP6 which has
>> a 0x66 preifx (0x66 0xf 0x1f ...) ?
>
> Sorta, it accepts everything with opcode 0f 1f and modrm_reg==0, which is
> how NOPL is encoded.
>
> Both: 66 66 66 66 66 66 66 66 66 66 66 66 66 66 90 (NOP15)
> And: 66 66 66 66 66 66 66 0f 1f 84 00 00 00 00 00 (NOP15)
>
> will be accepted here as max length instructions. The kernel will not
> actually use those, since a bunch of micro archs have decode penalties
> for too many prefixes.
>
>> From arch/x86/include/asm/nops.h we have:
>
> You're looking at old code :-)
>
Correct, I was on the 5.15 branch.
alex.
>> /*
>> * Generic 64bit nops from GAS:
>> *
>> * 1: nop
>> * 2: osp nop
>> * 3: nopl (%eax)
>> * 4: nopl 0x00(%eax)
>> * 5: nopl 0x00(%eax,%eax,1)
>> * 6: osp nopl 0x00(%eax,%eax,1)
>> * 7: nopl 0x00000000(%eax)
>> * 8: nopl 0x00000000(%eax,%eax,1)
>
> * 9: cs nopl 0x00000000(%eax,%eax,1)
> * 10: osp cs nopl 0x00000000(%eax,%eax,1)
> * 11: osp osp cs nopl 0x00000000(%eax,%eax,1)
>
>> */
>> #define BYTES_NOP1 0x90
>> #define BYTES_NOP2 0x66,BYTES_NOP1
>> #define BYTES_NOP3 0x0f,0x1f,0x00
>> #define BYTES_NOP4 0x0f,0x1f,0x40,0x00
>> #define BYTES_NOP5 0x0f,0x1f,0x44,0x00,0x00
>> #define BYTES_NOP6 0x66,BYTES_NOP5
>> #define BYTES_NOP7 0x0f,0x1f,0x80,0x00,0x00,0x00,0x00
>> #define BYTES_NOP8 0x0f,0x1f,0x84,0x00,0x00,0x00,0x00,0x00
>
> #define BYTES_NOP9 0x2e,BYTES_NOP8
> #define BYTES_NOP10 0x66,BYTES_NOP9
> #define BYTES_NOP11 0x66,BYTES_NOP10
>
> But yes, first two are NOP and then it switches to NOPL for 3 bytes and
> longer (2 opcode, 1 modrm). Where for 11 bytes we have:
>
> - 3 prefixes
> - 2 opcode
> - 1 modrm
> - 1 sib
> - 4 displacement
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 1/3] objtool/x86: Remove 0xea hack
2025-09-24 13:45 ` [PATCH 1/3] objtool/x86: Remove 0xea hack Peter Zijlstra
@ 2025-09-25 9:55 ` Alexandre Chartre
2025-10-14 11:47 ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
1 sibling, 0 replies; 19+ messages in thread
From: Alexandre Chartre @ 2025-09-25 9:55 UTC (permalink / raw)
To: Peter Zijlstra, jpoimboe, x86; +Cc: alexandre.chartre, linux-kernel
On 9/24/25 15:45, Peter Zijlstra wrote:
> Was properly fixed in the decoder with commit 4b626015e1bf ("x86/insn:
> Stop decoding i64 instructions in x86-64 mode at opcode")
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
> tools/objtool/arch/x86/decode.c | 9 ---------
> 1 file changed, 9 deletions(-)
>
> --- a/tools/objtool/arch/x86/decode.c
> +++ b/tools/objtool/arch/x86/decode.c
> @@ -189,15 +189,6 @@ int arch_decode_instruction(struct objto
> op2 = ins.opcode.bytes[1];
> op3 = ins.opcode.bytes[2];
>
> - /*
> - * XXX hack, decoder is buggered and thinks 0xea is 7 bytes long.
> - */
> - if (op1 == 0xea) {
> - insn->len = 1;
> - insn->type = INSN_BUG;
> - return 0;
> - }
> -
> if (ins.rex_prefix.nbytes) {
> rex = ins.rex_prefix.bytes[0];
> rex_w = X86_REX_W(rex) >> 3;
>
>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
alex.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 2/3] objtool/x86: Add UDB support
2025-09-24 13:45 ` [PATCH 2/3] objtool/x86: Add UDB support Peter Zijlstra
@ 2025-09-25 9:56 ` Alexandre Chartre
2025-10-14 11:47 ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
1 sibling, 0 replies; 19+ messages in thread
From: Alexandre Chartre @ 2025-09-25 9:56 UTC (permalink / raw)
To: Peter Zijlstra, jpoimboe, x86; +Cc: alexandre.chartre, linux-kernel
On 9/24/25 15:45, Peter Zijlstra wrote:
> Per commit 85a2d4a890dc ("x86,ibt: Use UDB instead of 0xEA"), make
> sure objtool also recognises UDB as a #UD instruction.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
> tools/objtool/arch/x86/decode.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> --- a/tools/objtool/arch/x86/decode.c
> +++ b/tools/objtool/arch/x86/decode.c
> @@ -683,6 +683,10 @@ int arch_decode_instruction(struct objto
> insn->type = INSN_SYSRET;
> break;
>
> + case 0xd6: /* udb */
> + insn->type = INSN_BUG;
> + break;
> +
> case 0xe0: /* loopne */
> case 0xe1: /* loope */
> case 0xe2: /* loop */
>
>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
alex.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] objtool/x86: Fix NOP decode
2025-09-25 9:55 ` Alexandre Chartre
@ 2025-09-25 10:03 ` Peter Zijlstra
2025-09-25 10:42 ` Peter Zijlstra
0 siblings, 1 reply; 19+ messages in thread
From: Peter Zijlstra @ 2025-09-25 10:03 UTC (permalink / raw)
To: Alexandre Chartre; +Cc: jpoimboe, x86, linux-kernel
On Thu, Sep 25, 2025 at 11:55:23AM +0200, Alexandre Chartre wrote:
>
> On 9/24/25 20:41, Peter Zijlstra wrote:
> > On Wed, Sep 24, 2025 at 07:34:00PM +0200, Alexandre Chartre wrote:
> > >
> > > On 9/24/25 15:45, Peter Zijlstra wrote:
> > > > For x86_64 the kernel consistently uses 2 instructions for all NOPs:
> > > >
> > > > 90 - NOP
> > > > 0f 1f /0 - NOPL
> > > >
> > > >
> > > > Notably:
> > > >
> > > > - REP NOP is PAUSE, not a NOP instruction.
> > > >
> > > > - 0f {0c...0f} is reserved space,
> > > > except for 0f 0d /1, which is PREFETCHW, not a NOP.
> > > >
> > > > - 0f {19,1c...1f} is reserved space,
> > > > except for 0f 1f /0, which is NOPL.
> > > >
> > > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > > > ---
> > > > tools/objtool/arch/x86/decode.c | 12 +++++++-----
> > > > 1 file changed, 7 insertions(+), 5 deletions(-)
> > > >
> > > > --- a/tools/objtool/arch/x86/decode.c
> > > > +++ b/tools/objtool/arch/x86/decode.c
> > > > @@ -494,7 +494,8 @@ int arch_decode_instruction(struct objto
> > > > break;
> > > > case 0x90:
> > > > + if (prefix != 0xf3) /* REP NOP := PAUSE */
> > > > + insn->type = INSN_NOP;
> > > > break;
> > >
> > > So this covers NOP1 (0x90) and NOP2 (0x66 0x90), right?
> >
> > Yes. Everything with opcode 0x90, except 0xf3 0x90, which as stated is
> > PAUSE.
> >
>
> What about 0x49 0x90, which is xchg (XCHG r8,rAX) ?
Ooh, that is a nice one. Yes, that needs fixing. Thanks!
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] objtool/x86: Fix NOP decode
2025-09-25 10:03 ` Peter Zijlstra
@ 2025-09-25 10:42 ` Peter Zijlstra
2025-09-25 11:29 ` Andrew Cooper
2025-09-25 13:05 ` Alexandre Chartre
0 siblings, 2 replies; 19+ messages in thread
From: Peter Zijlstra @ 2025-09-25 10:42 UTC (permalink / raw)
To: Alexandre Chartre; +Cc: jpoimboe, x86, linux-kernel
On Thu, Sep 25, 2025 at 12:03:23PM +0200, Peter Zijlstra wrote:
> > > > > case 0x90:
> > > > > + if (prefix != 0xf3) /* REP NOP := PAUSE */
> > > > > + insn->type = INSN_NOP;
> > > > > break;
> > What about 0x49 0x90, which is xchg (XCHG r8,rAX) ?
I've made that:
case 0x90:
if (rex_b) /* XCHG %r8, %rax */
break;
if (prefix == 0xf3) /* REP NOP := PAUSE */
break;
insn->type = INSN_NOP;
break;
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] objtool/x86: Fix NOP decode
2025-09-25 10:42 ` Peter Zijlstra
@ 2025-09-25 11:29 ` Andrew Cooper
2025-09-25 12:43 ` Peter Zijlstra
2025-09-25 13:05 ` Alexandre Chartre
1 sibling, 1 reply; 19+ messages in thread
From: Andrew Cooper @ 2025-09-25 11:29 UTC (permalink / raw)
To: peterz; +Cc: alexandre.chartre, jpoimboe, linux-kernel, x86
> I've made that:
>
> case 0x90:
> if (rex_b) /* XCHG %r8, %rax */
> break;
>
> if (prefix == 0xf3) /* REP NOP := PAUSE */
> break;
>
> insn->type = INSN_NOP;
> break;
Legacy prefixes can come in any order. What is F3 66 90 ?
Also, VEX/EVEX/REX2 want excluding too, all of which can encode rex_b
differently.
Is it really only rex_b which prevents NOP becoming a pause, or is it
any REX prefix? I would have thought it was any REX prefix.
~Andrew
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] objtool/x86: Fix NOP decode
2025-09-25 11:29 ` Andrew Cooper
@ 2025-09-25 12:43 ` Peter Zijlstra
2025-09-25 13:04 ` Alexandre Chartre
2025-09-25 14:11 ` Peter Zijlstra
0 siblings, 2 replies; 19+ messages in thread
From: Peter Zijlstra @ 2025-09-25 12:43 UTC (permalink / raw)
To: Andrew Cooper; +Cc: alexandre.chartre, jpoimboe, linux-kernel, x86
On Thu, Sep 25, 2025 at 12:29:18PM +0100, Andrew Cooper wrote:
> > I've made that:
> >
> > case 0x90:
> > if (rex_b) /* XCHG %r8, %rax */
> > break;
> >
> > if (prefix == 0xf3) /* REP NOP := PAUSE */
> > break;
> >
> > insn->type = INSN_NOP;
> > break;
>
> Legacy prefixes can come in any order. What is F3 66 90 ?
>
> Also, VEX/EVEX/REX2 want excluding too, all of which can encode rex_b
> differently.
So luckily objtool only really cares about instructions as found in the
kernel text. Neither f3 66 90 nor VEX/EVEX/REX2 prefixes are of much
concern.
But yes.. I happen to have an insn_is_nop() function that can be used on
userspace, and that certainly wants to be taught about these... x86 is
such a pain :/
> Is it really only rex_b which prevents NOP becoming a pause, or is it
> any REX prefix? I would have thought it was any REX prefix.
SDM opcode table and instruction reference seems consistent with f3
only.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] objtool/x86: Fix NOP decode
2025-09-25 12:43 ` Peter Zijlstra
@ 2025-09-25 13:04 ` Alexandre Chartre
2025-09-25 14:11 ` Peter Zijlstra
1 sibling, 0 replies; 19+ messages in thread
From: Alexandre Chartre @ 2025-09-25 13:04 UTC (permalink / raw)
To: Peter Zijlstra, Andrew Cooper
Cc: alexandre.chartre, jpoimboe, linux-kernel, x86
On 9/25/25 14:43, Peter Zijlstra wrote:
> On Thu, Sep 25, 2025 at 12:29:18PM +0100, Andrew Cooper wrote:
>>> I've made that:
>>>
>>> case 0x90:
>>> if (rex_b) /* XCHG %r8, %rax */
>>> break;
>>>
>>> if (prefix == 0xf3) /* REP NOP := PAUSE */
>>> break;
>>>
>>> insn->type = INSN_NOP;
>>> break;
>>
>> Legacy prefixes can come in any order. What is F3 66 90 ?
>>
>> Also, VEX/EVEX/REX2 want excluding too, all of which can encode rex_b
>> differently.
>
> So luckily objtool only really cares about instructions as found in the
> kernel text. Neither f3 66 90 nor VEX/EVEX/REX2 prefixes are of much
> concern.
And it looks like objtool ignores VEX instructions earlier in the same function:
int arch_decode_instruction(struct objtool_file *file, const struct section *sec,
unsigned long offset, unsigned int maxlen,
struct instruction *insn)
{
...
if (ins.vex_prefix.nbytes)
return 0;
...
}
vex_prefix is set for VEX/EVEX/VEX3/VEX2.
alex.
> But yes.. I happen to have an insn_is_nop() function that can be used on
> userspace, and that certainly wants to be taught about these... x86 is
> such a pain :/
>
>> Is it really only rex_b which prevents NOP becoming a pause, or is it
>> any REX prefix? I would have thought it was any REX prefix.
>
> SDM opcode table and instruction reference seems consistent with f3
> only.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] objtool/x86: Fix NOP decode
2025-09-25 10:42 ` Peter Zijlstra
2025-09-25 11:29 ` Andrew Cooper
@ 2025-09-25 13:05 ` Alexandre Chartre
1 sibling, 0 replies; 19+ messages in thread
From: Alexandre Chartre @ 2025-09-25 13:05 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: alexandre.chartre, jpoimboe, x86, linux-kernel
On 9/25/25 12:42, Peter Zijlstra wrote:
> On Thu, Sep 25, 2025 at 12:03:23PM +0200, Peter Zijlstra wrote:
>
>>>>>> case 0x90:
>>>>>> + if (prefix != 0xf3) /* REP NOP := PAUSE */
>>>>>> + insn->type = INSN_NOP;
>>>>>> break;
>
>>> What about 0x49 0x90, which is xchg (XCHG r8,rAX) ?
>
> I've made that:
>
> case 0x90:
> if (rex_b) /* XCHG %r8, %rax */
> break;
>
> if (prefix == 0xf3) /* REP NOP := PAUSE */
> break;
>
> insn->type = INSN_NOP;
> break;
>
>
Sounds good.
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
alex.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] objtool/x86: Fix NOP decode
2025-09-25 12:43 ` Peter Zijlstra
2025-09-25 13:04 ` Alexandre Chartre
@ 2025-09-25 14:11 ` Peter Zijlstra
1 sibling, 0 replies; 19+ messages in thread
From: Peter Zijlstra @ 2025-09-25 14:11 UTC (permalink / raw)
To: Andrew Cooper; +Cc: alexandre.chartre, jpoimboe, linux-kernel, x86
On Thu, Sep 25, 2025 at 02:43:32PM +0200, Peter Zijlstra wrote:
> But yes.. I happen to have an insn_is_nop() function that can be used on
> userspace, and that certainly wants to be taught about these... x86 is
> such a pain :/
This is the delta I ended up with for my insn_is_nop() function to
support *VEX*/REX2.
I'll post the whole thing later.
--- a/arch/x86/include/asm/insn.h
+++ b/arch/x86/include/asm/insn.h
@@ -138,6 +138,10 @@ struct insn {
#define X86_VEX_V(vex) (((vex) & 0x78) >> 3) /* VEX3 Byte2, VEX2 Byte1 */
#define X86_VEX_P(vex) ((vex) & 0x03) /* VEX3 Byte2, VEX2 Byte1 */
#define X86_VEX_M_MAX 0x1f /* VEX3.M Maximum value */
+/* EVEX bit fields */
+#define X86_EVEX_R4(vex) ((vex) & 0x10) /* EVEX Byte1 */
+#define X86_EVEX_B4(vex) ((vex) & 0x08) /* EVEX Byte1 */
+#define X86_EVEX_X4(vex) ((vex) & 0x04) /* EVEX Byte2 */
/* XOP bit fields */
#define X86_XOP_R(xop) ((xop) & 0x80) /* XOP Byte2 */
#define X86_XOP_X(xop) ((xop) & 0x40) /* XOP Byte2 */
--- a/arch/x86/lib/insn-eval.c
+++ b/arch/x86/lib/insn-eval.c
@@ -1689,33 +1689,62 @@ enum insn_mmio_type insn_decode_mmio(str
*/
bool insn_is_nop(struct insn *insn)
{
- u8 rex, rex_b = 0, rex_x = 0, rex_r = 0, rex_w = 0;
+ u8 b3 = 0, x3 = 0, r3 = 0, w = 0;
+ u8 b4 = 0, x4 = 0, r4 = 0;
u8 modrm, modrm_mod, modrm_reg, modrm_rm;
u8 sib = 0, sib_scale, sib_index, sib_base;
insn_byte_t p;
+ u8 nrex, rex;
int i;
- if (insn->rex_prefix.nbytes) {
- rex = insn->rex_prefix.bytes[0];
- rex_w = !!X86_REX_W(rex);
- rex_r = !!X86_REX_R(rex);
- rex_x = !!X86_REX_X(rex);
- rex_b = !!X86_REX_B(rex);
+ if ((nrex = insn->rex_prefix.nbytes)) {
+ rex = insn->rex_prefix.bytes[nrex-1];
+
+ w = !!X86_REX_W(rex);
+ r3 = !!X86_REX_R(rex);
+ x3 = !!X86_REX_X(rex);
+ b3 = !!X86_REX_B(rex);
+ if (nrex > 1) {
+ r4 = !!X86_REX2_R(rex);
+ x4 = !!X86_REX2_X(rex);
+ b4 = !!X86_REX2_B(rex);
+ }
+
+ } else switch (insn->vex_prefix.nbytes) {
+ case 2: /* VEX2 */
+ r3 = !X86_VEX_R(insn->vex_prefix.bytes[1]);
+ break;
+ case 3: /* VEX3 */
+ r3 = !X86_VEX_R(insn->vex_prefix.bytes[1]);
+ x3 = !X86_VEX_X(insn->vex_prefix.bytes[1]);
+ b3 = !X86_VEX_B(insn->vex_prefix.bytes[1]);
+ w = !!X86_VEX_W(insn->vex_prefix.bytes[2]);
+ break;
+ case 4: /* EVEX */
+ r3 = !X86_VEX_R(insn->vex_prefix.bytes[1]);
+ x3 = !X86_VEX_X(insn->vex_prefix.bytes[1]);
+ b3 = !X86_VEX_B(insn->vex_prefix.bytes[1]);
+ w = !!X86_VEX_W(insn->vex_prefix.bytes[2]);
+ r4 = !X86_EVEX_R4(insn->vex_prefix.bytes[1]);
+ b4 = !!X86_EVEX_B4(insn->vex_prefix.bytes[1]);
+ x4 = !X86_EVEX_X4(insn->vex_prefix.bytes[2]);
+ break;
+ default: break;
}
if (insn->modrm.nbytes) {
modrm = insn->modrm.bytes[0];
modrm_mod = X86_MODRM_MOD(modrm);
- modrm_reg = X86_MODRM_REG(modrm) + 8*rex_r;
- modrm_rm = X86_MODRM_RM(modrm) + 8*rex_b;
+ modrm_reg = X86_MODRM_REG(modrm) + 8*r3 + 16*r4;
+ modrm_rm = X86_MODRM_RM(modrm) + 8*b3 + 16*b4;
modrm = 1;
}
if (insn->sib.nbytes) {
sib = insn->sib.bytes[0];
sib_scale = X86_SIB_SCALE(sib);
- sib_index = X86_SIB_INDEX(sib) + 8*rex_x;
- sib_base = X86_SIB_BASE(sib) + 8*rex_b;
+ sib_index = X86_SIB_INDEX(sib) + 8*x3 + 16*x4;
+ sib_base = X86_SIB_BASE(sib) + 8*b3 + 16*b4;
sib = 1;
modrm_rm = sib_base;
@@ -1729,7 +1758,7 @@ bool insn_is_nop(struct insn *insn)
if (modrm_mod != 3) /* register-direct */
return false;
- if (insn->x86_64 && !rex_w) /* native size */
+ if (insn->x86_64 && !w) /* native size */
return false;
for_each_insn_prefix(insn, i, p) {
@@ -1743,7 +1772,7 @@ bool insn_is_nop(struct insn *insn)
if (modrm_mod == 0 || modrm_mod == 3) /* register-indirect with disp */
return false;
- if (insn->x86_64 && !rex_w) /* native size */
+ if (insn->x86_64 && !w) /* native size */
return false;
if (insn->displacement.value != 0)
@@ -1760,7 +1789,7 @@ bool insn_is_nop(struct insn *insn)
return modrm_reg == modrm_rm; /* LEA 0(%reg), %reg */
case 0x90: /* NOP */
- if (rex_b) /* XCHG %r8,%rax */
+ if (b3 || b4) /* XCHG %r8,%rax */
return false;
for_each_insn_prefix(insn, i, p) {
^ permalink raw reply [flat|nested] 19+ messages in thread
* [tip: objtool/core] objtool/x86: Fix NOP decode
2025-09-24 13:45 ` [PATCH 3/3] objtool/x86: Fix NOP decode Peter Zijlstra
2025-09-24 17:34 ` Alexandre Chartre
@ 2025-10-14 11:47 ` tip-bot2 for Peter Zijlstra
1 sibling, 0 replies; 19+ messages in thread
From: tip-bot2 for Peter Zijlstra @ 2025-10-14 11:47 UTC (permalink / raw)
To: linux-tip-commits; +Cc: Peter Zijlstra (Intel), x86, linux-kernel
The following commit has been merged into the objtool/core branch of tip:
Commit-ID: 044f721ccd33103349eebbb960825584bc6d8e23
Gitweb: https://git.kernel.org/tip/044f721ccd33103349eebbb960825584bc6d8e23
Author: Peter Zijlstra <peterz@infradead.org>
AuthorDate: Wed, 24 Sep 2025 15:27:03 +02:00
Committer: Peter Zijlstra <peterz@infradead.org>
CommitterDate: Tue, 14 Oct 2025 13:43:11 +02:00
objtool/x86: Fix NOP decode
For x86_64 the kernel consistently uses 2 instructions for all NOPs:
90 - NOP
0f 1f /0 - NOPL
Notably:
- REP NOP is PAUSE, not a NOP instruction.
- 0f {0c...0f} is reserved space,
except for 0f 0d /1, which is PREFETCHW, not a NOP.
- 0f {19,1c...1f} is reserved space,
except for 0f 1f /0, which is NOPL.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
tools/objtool/arch/x86/decode.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decode.c
index ef6e96d..204e2ad 100644
--- a/tools/objtool/arch/x86/decode.c
+++ b/tools/objtool/arch/x86/decode.c
@@ -494,6 +494,12 @@ int arch_decode_instruction(struct objtool_file *file, const struct section *sec
break;
case 0x90:
+ if (rex_b) /* XCHG %r8, %rax */
+ break;
+
+ if (prefix == 0xf3) /* REP NOP := PAUSE */
+ break;
+
insn->type = INSN_NOP;
break;
@@ -547,13 +553,14 @@ int arch_decode_instruction(struct objtool_file *file, const struct section *sec
} else if (op2 == 0x0b || op2 == 0xb9) {
- /* ud2 */
+ /* ud2, ud1 */
insn->type = INSN_BUG;
- } else if (op2 == 0x0d || op2 == 0x1f) {
+ } else if (op2 == 0x1f) {
- /* nopl/nopw */
- insn->type = INSN_NOP;
+ /* 0f 1f /0 := NOPL */
+ if (modrm_reg == 0)
+ insn->type = INSN_NOP;
} else if (op2 == 0x1e) {
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [tip: objtool/core] objtool/x86: Add UDB support
2025-09-24 13:45 ` [PATCH 2/3] objtool/x86: Add UDB support Peter Zijlstra
2025-09-25 9:56 ` Alexandre Chartre
@ 2025-10-14 11:47 ` tip-bot2 for Peter Zijlstra
1 sibling, 0 replies; 19+ messages in thread
From: tip-bot2 for Peter Zijlstra @ 2025-10-14 11:47 UTC (permalink / raw)
To: linux-tip-commits
Cc: Peter Zijlstra (Intel), Alexandre Chartre, x86, linux-kernel
The following commit has been merged into the objtool/core branch of tip:
Commit-ID: 76e1851a1bc28e760d6acc7a54ec9dce05717028
Gitweb: https://git.kernel.org/tip/76e1851a1bc28e760d6acc7a54ec9dce05717028
Author: Peter Zijlstra <peterz@infradead.org>
AuthorDate: Wed, 24 Sep 2025 15:25:27 +02:00
Committer: Peter Zijlstra <peterz@infradead.org>
CommitterDate: Tue, 14 Oct 2025 13:43:11 +02:00
objtool/x86: Add UDB support
Per commit 85a2d4a890dc ("x86,ibt: Use UDB instead of 0xEA"), make
sure objtool also recognises UDB as a #UD instruction.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
---
tools/objtool/arch/x86/decode.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decode.c
index ce16fb2..ef6e96d 100644
--- a/tools/objtool/arch/x86/decode.c
+++ b/tools/objtool/arch/x86/decode.c
@@ -683,6 +683,10 @@ int arch_decode_instruction(struct objtool_file *file, const struct section *sec
insn->type = INSN_SYSRET;
break;
+ case 0xd6: /* udb */
+ insn->type = INSN_BUG;
+ break;
+
case 0xe0: /* loopne */
case 0xe1: /* loope */
case 0xe2: /* loop */
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [tip: objtool/core] objtool/x86: Remove 0xea hack
2025-09-24 13:45 ` [PATCH 1/3] objtool/x86: Remove 0xea hack Peter Zijlstra
2025-09-25 9:55 ` Alexandre Chartre
@ 2025-10-14 11:47 ` tip-bot2 for Peter Zijlstra
1 sibling, 0 replies; 19+ messages in thread
From: tip-bot2 for Peter Zijlstra @ 2025-10-14 11:47 UTC (permalink / raw)
To: linux-tip-commits
Cc: Peter Zijlstra (Intel), Alexandre Chartre, x86, linux-kernel
The following commit has been merged into the objtool/core branch of tip:
Commit-ID: c5df4e1ab8c00c4dc13094fa44e219bc48d910f4
Gitweb: https://git.kernel.org/tip/c5df4e1ab8c00c4dc13094fa44e219bc48d910f4
Author: Peter Zijlstra <peterz@infradead.org>
AuthorDate: Wed, 24 Sep 2025 15:22:46 +02:00
Committer: Peter Zijlstra <peterz@infradead.org>
CommitterDate: Tue, 14 Oct 2025 13:43:10 +02:00
objtool/x86: Remove 0xea hack
Was properly fixed in the decoder with commit 4b626015e1bf ("x86/insn:
Stop decoding i64 instructions in x86-64 mode at opcode")
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
---
tools/objtool/arch/x86/decode.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decode.c
index 0ad5cc7..ce16fb2 100644
--- a/tools/objtool/arch/x86/decode.c
+++ b/tools/objtool/arch/x86/decode.c
@@ -189,15 +189,6 @@ int arch_decode_instruction(struct objtool_file *file, const struct section *sec
op2 = ins.opcode.bytes[1];
op3 = ins.opcode.bytes[2];
- /*
- * XXX hack, decoder is buggered and thinks 0xea is 7 bytes long.
- */
- if (op1 == 0xea) {
- insn->len = 1;
- insn->type = INSN_BUG;
- return 0;
- }
-
if (ins.rex_prefix.nbytes) {
rex = ins.rex_prefix.bytes[0];
rex_w = X86_REX_W(rex) >> 3;
^ permalink raw reply related [flat|nested] 19+ messages in thread
end of thread, other threads:[~2025-10-14 11:48 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-09-24 13:45 [PATCH 0/3] objtool: Few x86 decoder updates Peter Zijlstra
2025-09-24 13:45 ` [PATCH 1/3] objtool/x86: Remove 0xea hack Peter Zijlstra
2025-09-25 9:55 ` Alexandre Chartre
2025-10-14 11:47 ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
2025-09-24 13:45 ` [PATCH 2/3] objtool/x86: Add UDB support Peter Zijlstra
2025-09-25 9:56 ` Alexandre Chartre
2025-10-14 11:47 ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
2025-09-24 13:45 ` [PATCH 3/3] objtool/x86: Fix NOP decode Peter Zijlstra
2025-09-24 17:34 ` Alexandre Chartre
2025-09-24 18:41 ` Peter Zijlstra
2025-09-25 9:55 ` Alexandre Chartre
2025-09-25 10:03 ` Peter Zijlstra
2025-09-25 10:42 ` Peter Zijlstra
2025-09-25 11:29 ` Andrew Cooper
2025-09-25 12:43 ` Peter Zijlstra
2025-09-25 13:04 ` Alexandre Chartre
2025-09-25 14:11 ` Peter Zijlstra
2025-09-25 13:05 ` Alexandre Chartre
2025-10-14 11:47 ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox