* [PATCH] x86/sev: Disable GCOV on noinstr object
@ 2025-11-17 11:11 Brendan Jackman
2025-11-17 11:40 ` Ard Biesheuvel
0 siblings, 1 reply; 6+ messages in thread
From: Brendan Jackman @ 2025-11-17 11:11 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Nathan Chancellor, Nick Desaulniers,
Bill Wendling, Justin Stitt, Ard Biesheuvel
Cc: linux-kernel, llvm, Brendan Jackman
With Debian clang version 19.1.7 (3+build5) there are calls to
kasan_check_write() from __sev_es_nmi_complete, which violates noinstr.
Fix it by disabling GCOV for the noinstr object, as has been done for
previous such instrumentation issues.
Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
Details:
- ❯❯ clang --version
Debian clang version 19.1.7 (3+build5)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm-19/bin
- Compiling from tip/master at 6f85aad74a70d
- Kernel config:
https://gist.githubusercontent.com/bjackman/bbfdf4ec2e1dfd0e18657174f0537e2c/raw/a88dcc6567d14c69445e7928a7d5dfc23ca9f619/gistfile0.txt
Note I also get this error:
vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x3b: relocation to !ENDBR: machine_kexec_prepare+0x810
That one's a total mystery to me. I guess it's better to "fix" the SEV
one independently rather than waiting until I know how to fix them both.
---
arch/x86/coco/sev/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/coco/sev/Makefile b/arch/x86/coco/sev/Makefile
index 3b8ae214a6a64de6bb208eb3b7c8bf12007ccc2c..d2ceae587b6c30b2fb17209a7426e7893dea988c 100644
--- a/arch/x86/coco/sev/Makefile
+++ b/arch/x86/coco/sev/Makefile
@@ -8,3 +8,6 @@ UBSAN_SANITIZE_noinstr.o := n
# GCC may fail to respect __no_sanitize_address or __no_kcsan when inlining
KASAN_SANITIZE_noinstr.o := n
KCSAN_SANITIZE_noinstr.o := n
+
+# Clang 19 and older may fail to respect __no_sanitize_address when inlining
+GCOV_PROFILE_noinstr.o := n
---
base-commit: 6f85aad74a70d17919a64ecd93037aa51c08698d
change-id: 20251117-b4-sev-gcov-objtool-2f6cd197cd9c
Best regards,
--
Brendan Jackman <jackmanb@google.com>
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] x86/sev: Disable GCOV on noinstr object
2025-11-17 11:11 [PATCH] x86/sev: Disable GCOV on noinstr object Brendan Jackman
@ 2025-11-17 11:40 ` Ard Biesheuvel
2025-11-17 11:51 ` Ard Biesheuvel
0 siblings, 1 reply; 6+ messages in thread
From: Ard Biesheuvel @ 2025-11-17 11:40 UTC (permalink / raw)
To: Brendan Jackman
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Nathan Chancellor, Nick Desaulniers,
Bill Wendling, Justin Stitt, linux-kernel, llvm
On Mon, 17 Nov 2025 at 12:11, Brendan Jackman <jackmanb@google.com> wrote:
>
> With Debian clang version 19.1.7 (3+build5) there are calls to
> kasan_check_write() from __sev_es_nmi_complete, which violates noinstr.
> Fix it by disabling GCOV for the noinstr object, as has been done for
> previous such instrumentation issues.
>
> Signed-off-by: Brendan Jackman <jackmanb@google.com>
> ---
> Details:
>
> - ❯❯ clang --version
> Debian clang version 19.1.7 (3+build5)
> Target: x86_64-pc-linux-gnu
> Thread model: posix
> InstalledDir: /usr/lib/llvm-19/bin
>
> - Compiling from tip/master at 6f85aad74a70d
>
> - Kernel config:
>
> https://gist.githubusercontent.com/bjackman/bbfdf4ec2e1dfd0e18657174f0537e2c/raw/a88dcc6567d14c69445e7928a7d5dfc23ca9f619/gistfile0.txt
>
> Note I also get this error:
>
> vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x3b: relocation to !ENDBR: machine_kexec_prepare+0x810
>
> That one's a total mystery to me. I guess it's better to "fix" the SEV
> one independently rather than waiting until I know how to fix them both.
> ---
> arch/x86/coco/sev/Makefile | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/x86/coco/sev/Makefile b/arch/x86/coco/sev/Makefile
> index 3b8ae214a6a64de6bb208eb3b7c8bf12007ccc2c..d2ceae587b6c30b2fb17209a7426e7893dea988c 100644
> --- a/arch/x86/coco/sev/Makefile
> +++ b/arch/x86/coco/sev/Makefile
> @@ -8,3 +8,6 @@ UBSAN_SANITIZE_noinstr.o := n
> # GCC may fail to respect __no_sanitize_address or __no_kcsan when inlining
> KASAN_SANITIZE_noinstr.o := n
> KCSAN_SANITIZE_noinstr.o := n
> +
> +# Clang 19 and older may fail to respect __no_sanitize_address when inlining
> +GCOV_PROFILE_noinstr.o := n
>
After Thomas dug into this issue a while ago, I meant to follow up
with a fix, or at least something to start the discussion.
TL;DR there is nothing wrong with either compiler (as far as this
issue is concerned)
The issue is that KASAN/KCSAN enabled builds use a version of
set_bit() that unconditionally inserts a call to
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] x86/sev: Disable GCOV on noinstr object
2025-11-17 11:40 ` Ard Biesheuvel
@ 2025-11-17 11:51 ` Ard Biesheuvel
2025-11-17 12:37 ` Brendan Jackman
0 siblings, 1 reply; 6+ messages in thread
From: Ard Biesheuvel @ 2025-11-17 11:51 UTC (permalink / raw)
To: Brendan Jackman
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Nathan Chancellor, Nick Desaulniers,
Bill Wendling, Justin Stitt, linux-kernel, llvm
On Mon, 17 Nov 2025 at 12:40, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Mon, 17 Nov 2025 at 12:11, Brendan Jackman <jackmanb@google.com> wrote:
> >
> > With Debian clang version 19.1.7 (3+build5) there are calls to
> > kasan_check_write() from __sev_es_nmi_complete, which violates noinstr.
> > Fix it by disabling GCOV for the noinstr object, as has been done for
> > previous such instrumentation issues.
> >
> > Signed-off-by: Brendan Jackman <jackmanb@google.com>
> > ---
> > Details:
> >
> > - ❯❯ clang --version
> > Debian clang version 19.1.7 (3+build5)
> > Target: x86_64-pc-linux-gnu
> > Thread model: posix
> > InstalledDir: /usr/lib/llvm-19/bin
> >
> > - Compiling from tip/master at 6f85aad74a70d
> >
> > - Kernel config:
> >
> > https://gist.githubusercontent.com/bjackman/bbfdf4ec2e1dfd0e18657174f0537e2c/raw/a88dcc6567d14c69445e7928a7d5dfc23ca9f619/gistfile0.txt
> >
> > Note I also get this error:
> >
> > vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x3b: relocation to !ENDBR: machine_kexec_prepare+0x810
> >
> > That one's a total mystery to me. I guess it's better to "fix" the SEV
> > one independently rather than waiting until I know how to fix them both.
> > ---
> > arch/x86/coco/sev/Makefile | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/x86/coco/sev/Makefile b/arch/x86/coco/sev/Makefile
> > index 3b8ae214a6a64de6bb208eb3b7c8bf12007ccc2c..d2ceae587b6c30b2fb17209a7426e7893dea988c 100644
> > --- a/arch/x86/coco/sev/Makefile
> > +++ b/arch/x86/coco/sev/Makefile
> > @@ -8,3 +8,6 @@ UBSAN_SANITIZE_noinstr.o := n
> > # GCC may fail to respect __no_sanitize_address or __no_kcsan when inlining
> > KASAN_SANITIZE_noinstr.o := n
> > KCSAN_SANITIZE_noinstr.o := n
> > +
> > +# Clang 19 and older may fail to respect __no_sanitize_address when inlining
> > +GCOV_PROFILE_noinstr.o := n
> >
>
> After Thomas dug into this issue a while ago, I meant to follow up
> with a fix, or at least something to start the discussion.
>
> TL;DR there is nothing wrong with either compiler (as far as this
> issue is concerned)
>
> The issue is that KASAN/KCSAN enabled builds use a version of
> set_bit() that unconditionally inserts a call to
instrument_atomic_write(), which calls the KASAN/KCSAN intrinsics
directly, and these are usually only called by compiler generated
code.
This completely defeats the noinstr per-function annotation, given
that each compilation unit only incorporates a single version of
set_bit(), which is the instrumented version unless instrumentation is
disabled for the entire file.
For the short term, we could avoid this by using arch___set_bit()
directly in the SEV code that triggers this issue today. But for the
longer term, we should get write of those explicit calls to
instrumentation intrinsics, as this is fundamentally incompatible with
per-function overrides.
https://lore.kernel.org/all/8734aqulch.ffs@tglx/T/#u
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] x86/sev: Disable GCOV on noinstr object
2025-11-17 11:51 ` Ard Biesheuvel
@ 2025-11-17 12:37 ` Brendan Jackman
2025-11-20 11:41 ` Brendan Jackman
0 siblings, 1 reply; 6+ messages in thread
From: Brendan Jackman @ 2025-11-17 12:37 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Nathan Chancellor, Nick Desaulniers,
Bill Wendling, Justin Stitt, linux-kernel, llvm
On Mon, 17 Nov 2025 at 12:52, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Mon, 17 Nov 2025 at 12:40, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Mon, 17 Nov 2025 at 12:11, Brendan Jackman <jackmanb@google.com> wrote:
> > >
> > > With Debian clang version 19.1.7 (3+build5) there are calls to
> > > kasan_check_write() from __sev_es_nmi_complete, which violates noinstr.
> > > Fix it by disabling GCOV for the noinstr object, as has been done for
> > > previous such instrumentation issues.
> > >
> > > Signed-off-by: Brendan Jackman <jackmanb@google.com>
> > > ---
> > > Details:
> > >
> > > - ❯❯ clang --version
> > > Debian clang version 19.1.7 (3+build5)
> > > Target: x86_64-pc-linux-gnu
> > > Thread model: posix
> > > InstalledDir: /usr/lib/llvm-19/bin
> > >
> > > - Compiling from tip/master at 6f85aad74a70d
> > >
> > > - Kernel config:
> > >
> > > https://gist.githubusercontent.com/bjackman/bbfdf4ec2e1dfd0e18657174f0537e2c/raw/a88dcc6567d14c69445e7928a7d5dfc23ca9f619/gistfile0.txt
> > >
> > > Note I also get this error:
> > >
> > > vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x3b: relocation to !ENDBR: machine_kexec_prepare+0x810
> > >
> > > That one's a total mystery to me. I guess it's better to "fix" the SEV
> > > one independently rather than waiting until I know how to fix them both.
> > > ---
> > > arch/x86/coco/sev/Makefile | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/arch/x86/coco/sev/Makefile b/arch/x86/coco/sev/Makefile
> > > index 3b8ae214a6a64de6bb208eb3b7c8bf12007ccc2c..d2ceae587b6c30b2fb17209a7426e7893dea988c 100644
> > > --- a/arch/x86/coco/sev/Makefile
> > > +++ b/arch/x86/coco/sev/Makefile
> > > @@ -8,3 +8,6 @@ UBSAN_SANITIZE_noinstr.o := n
> > > # GCC may fail to respect __no_sanitize_address or __no_kcsan when inlining
> > > KASAN_SANITIZE_noinstr.o := n
> > > KCSAN_SANITIZE_noinstr.o := n
> > > +
> > > +# Clang 19 and older may fail to respect __no_sanitize_address when inlining
> > > +GCOV_PROFILE_noinstr.o := n
> > >
> >
> > After Thomas dug into this issue a while ago, I meant to follow up
> > with a fix, or at least something to start the discussion.
> >
> > TL;DR there is nothing wrong with either compiler (as far as this
> > issue is concerned)
> >
> > The issue is that KASAN/KCSAN enabled builds use a version of
> > set_bit() that unconditionally inserts a call to
>
> instrument_atomic_write(), which calls the KASAN/KCSAN intrinsics
> directly, and these are usually only called by compiler generated
> code.
>
> This completely defeats the noinstr per-function annotation, given
> that each compilation unit only incorporates a single version of
> set_bit(), which is the instrumented version unless instrumentation is
> disabled for the entire file.
>
> For the short term, we could avoid this by using arch___set_bit()
> directly in the SEV code that triggers this issue today. But for the
> longer term, we should get write of those explicit calls to
> instrumentation intrinsics, as this is fundamentally incompatible with
> per-function overrides.
>
> https://lore.kernel.org/all/8734aqulch.ffs@tglx/T/#u
Ah, yes thank you I think you are right. My GCOV "fix" seems to be
bogus, it probably just hides the issue with incidental changes.
[Dropping verbose notes so I can remember this next time I come to the
thread...]
I was reading disasm and it appeared that the __sev_es_nmi_complete()
-> kasan_check_write() issue corresponded to the __builtin_memset() in
vc_ghcb_invalidate().
But yeah, why should GCOV cause a kasan_check_write() to be injected,
that doesn't really make sense.
So probably rather than compiler instrumentation of the
__builtin_memset() I am seeing the __set_bit() in the
ghcb_set_sw_exit_code() that comes right afterwards.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] x86/sev: Disable GCOV on noinstr object
2025-11-17 12:37 ` Brendan Jackman
@ 2025-11-20 11:41 ` Brendan Jackman
2025-11-20 15:47 ` Ard Biesheuvel
0 siblings, 1 reply; 6+ messages in thread
From: Brendan Jackman @ 2025-11-20 11:41 UTC (permalink / raw)
To: Brendan Jackman, Ard Biesheuvel
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Nathan Chancellor, Nick Desaulniers,
Bill Wendling, Justin Stitt, linux-kernel, llvm
On Mon Nov 17, 2025 at 12:37 PM UTC, Brendan Jackman wrote:
> On Mon, 17 Nov 2025 at 12:52, Ard Biesheuvel <ardb@kernel.org> wrote:
>>
>> On Mon, 17 Nov 2025 at 12:40, Ard Biesheuvel <ardb@kernel.org> wrote:
>> >
>> > On Mon, 17 Nov 2025 at 12:11, Brendan Jackman <jackmanb@google.com> wrote:
>> > >
>> > > With Debian clang version 19.1.7 (3+build5) there are calls to
>> > > kasan_check_write() from __sev_es_nmi_complete, which violates noinstr.
>> > > Fix it by disabling GCOV for the noinstr object, as has been done for
>> > > previous such instrumentation issues.
>> > >
>> > > Signed-off-by: Brendan Jackman <jackmanb@google.com>
>> > > ---
>> > > Details:
>> > >
>> > > - ❯❯ clang --version
>> > > Debian clang version 19.1.7 (3+build5)
>> > > Target: x86_64-pc-linux-gnu
>> > > Thread model: posix
>> > > InstalledDir: /usr/lib/llvm-19/bin
>> > >
>> > > - Compiling from tip/master at 6f85aad74a70d
>> > >
>> > > - Kernel config:
>> > >
>> > > https://gist.githubusercontent.com/bjackman/bbfdf4ec2e1dfd0e18657174f0537e2c/raw/a88dcc6567d14c69445e7928a7d5dfc23ca9f619/gistfile0.txt
>> > >
>> > > Note I also get this error:
>> > >
>> > > vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x3b: relocation to !ENDBR: machine_kexec_prepare+0x810
>> > >
>> > > That one's a total mystery to me. I guess it's better to "fix" the SEV
>> > > one independently rather than waiting until I know how to fix them both.
>> > > ---
>> > > arch/x86/coco/sev/Makefile | 3 +++
>> > > 1 file changed, 3 insertions(+)
>> > >
>> > > diff --git a/arch/x86/coco/sev/Makefile b/arch/x86/coco/sev/Makefile
>> > > index 3b8ae214a6a64de6bb208eb3b7c8bf12007ccc2c..d2ceae587b6c30b2fb17209a7426e7893dea988c 100644
>> > > --- a/arch/x86/coco/sev/Makefile
>> > > +++ b/arch/x86/coco/sev/Makefile
>> > > @@ -8,3 +8,6 @@ UBSAN_SANITIZE_noinstr.o := n
>> > > # GCC may fail to respect __no_sanitize_address or __no_kcsan when inlining
>> > > KASAN_SANITIZE_noinstr.o := n
>> > > KCSAN_SANITIZE_noinstr.o := n
>> > > +
>> > > +# Clang 19 and older may fail to respect __no_sanitize_address when inlining
>> > > +GCOV_PROFILE_noinstr.o := n
>> > >
>> >
>> > After Thomas dug into this issue a while ago, I meant to follow up
>> > with a fix, or at least something to start the discussion.
>> >
>> > TL;DR there is nothing wrong with either compiler (as far as this
>> > issue is concerned)
>> >
>> > The issue is that KASAN/KCSAN enabled builds use a version of
>> > set_bit() that unconditionally inserts a call to
>>
>> instrument_atomic_write(), which calls the KASAN/KCSAN intrinsics
>> directly, and these are usually only called by compiler generated
>> code.
>>
>> This completely defeats the noinstr per-function annotation, given
>> that each compilation unit only incorporates a single version of
>> set_bit(), which is the instrumented version unless instrumentation is
>> disabled for the entire file.
>>
>> For the short term, we could avoid this by using arch___set_bit()
>> directly in the SEV code that triggers this issue today. But for the
>> longer term, we should get write of those explicit calls to
>> instrumentation intrinsics, as this is fundamentally incompatible with
>> per-function overrides.
>>
>> https://lore.kernel.org/all/8734aqulch.ffs@tglx/T/#u
>
> Ah, yes thank you I think you are right. My GCOV "fix" seems to be
> bogus, it probably just hides the issue with incidental changes.
On the other hand, I guess the intermediate workaround of just disabling
it at the compilation unit still makes sense here, right?
i.e. my patch is still dumb but should we start by just doing
K{A,C}ASAN_SANITIZE_noinstr.o := n instead?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] x86/sev: Disable GCOV on noinstr object
2025-11-20 11:41 ` Brendan Jackman
@ 2025-11-20 15:47 ` Ard Biesheuvel
0 siblings, 0 replies; 6+ messages in thread
From: Ard Biesheuvel @ 2025-11-20 15:47 UTC (permalink / raw)
To: Brendan Jackman
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Nathan Chancellor, Nick Desaulniers,
Bill Wendling, Justin Stitt, linux-kernel, llvm
On Thu, 20 Nov 2025 at 12:41, Brendan Jackman <jackmanb@google.com> wrote:
>
> On Mon Nov 17, 2025 at 12:37 PM UTC, Brendan Jackman wrote:
> > On Mon, 17 Nov 2025 at 12:52, Ard Biesheuvel <ardb@kernel.org> wrote:
> >>
> >> On Mon, 17 Nov 2025 at 12:40, Ard Biesheuvel <ardb@kernel.org> wrote:
> >> >
> >> > On Mon, 17 Nov 2025 at 12:11, Brendan Jackman <jackmanb@google.com> wrote:
> >> > >
> >> > > With Debian clang version 19.1.7 (3+build5) there are calls to
> >> > > kasan_check_write() from __sev_es_nmi_complete, which violates noinstr.
> >> > > Fix it by disabling GCOV for the noinstr object, as has been done for
> >> > > previous such instrumentation issues.
> >> > >
> >> > > Signed-off-by: Brendan Jackman <jackmanb@google.com>
> >> > > ---
> >> > > Details:
> >> > >
> >> > > - ❯❯ clang --version
> >> > > Debian clang version 19.1.7 (3+build5)
> >> > > Target: x86_64-pc-linux-gnu
> >> > > Thread model: posix
> >> > > InstalledDir: /usr/lib/llvm-19/bin
> >> > >
> >> > > - Compiling from tip/master at 6f85aad74a70d
> >> > >
> >> > > - Kernel config:
> >> > >
> >> > > https://gist.githubusercontent.com/bjackman/bbfdf4ec2e1dfd0e18657174f0537e2c/raw/a88dcc6567d14c69445e7928a7d5dfc23ca9f619/gistfile0.txt
> >> > >
> >> > > Note I also get this error:
> >> > >
> >> > > vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x3b: relocation to !ENDBR: machine_kexec_prepare+0x810
> >> > >
> >> > > That one's a total mystery to me. I guess it's better to "fix" the SEV
> >> > > one independently rather than waiting until I know how to fix them both.
> >> > > ---
> >> > > arch/x86/coco/sev/Makefile | 3 +++
> >> > > 1 file changed, 3 insertions(+)
> >> > >
> >> > > diff --git a/arch/x86/coco/sev/Makefile b/arch/x86/coco/sev/Makefile
> >> > > index 3b8ae214a6a64de6bb208eb3b7c8bf12007ccc2c..d2ceae587b6c30b2fb17209a7426e7893dea988c 100644
> >> > > --- a/arch/x86/coco/sev/Makefile
> >> > > +++ b/arch/x86/coco/sev/Makefile
> >> > > @@ -8,3 +8,6 @@ UBSAN_SANITIZE_noinstr.o := n
> >> > > # GCC may fail to respect __no_sanitize_address or __no_kcsan when inlining
> >> > > KASAN_SANITIZE_noinstr.o := n
> >> > > KCSAN_SANITIZE_noinstr.o := n
> >> > > +
> >> > > +# Clang 19 and older may fail to respect __no_sanitize_address when inlining
> >> > > +GCOV_PROFILE_noinstr.o := n
> >> > >
> >> >
> >> > After Thomas dug into this issue a while ago, I meant to follow up
> >> > with a fix, or at least something to start the discussion.
> >> >
> >> > TL;DR there is nothing wrong with either compiler (as far as this
> >> > issue is concerned)
> >> >
> >> > The issue is that KASAN/KCSAN enabled builds use a version of
> >> > set_bit() that unconditionally inserts a call to
> >>
> >> instrument_atomic_write(), which calls the KASAN/KCSAN intrinsics
> >> directly, and these are usually only called by compiler generated
> >> code.
> >>
> >> This completely defeats the noinstr per-function annotation, given
> >> that each compilation unit only incorporates a single version of
> >> set_bit(), which is the instrumented version unless instrumentation is
> >> disabled for the entire file.
> >>
> >> For the short term, we could avoid this by using arch___set_bit()
> >> directly in the SEV code that triggers this issue today. But for the
> >> longer term, we should get write of those explicit calls to
> >> instrumentation intrinsics, as this is fundamentally incompatible with
> >> per-function overrides.
> >>
> >> https://lore.kernel.org/all/8734aqulch.ffs@tglx/T/#u
> >
> > Ah, yes thank you I think you are right. My GCOV "fix" seems to be
> > bogus, it probably just hides the issue with incidental changes.
>
> On the other hand, I guess the intermediate workaround of just disabling
> it at the compilation unit still makes sense here, right?
>
> i.e. my patch is still dumb but should we start by just doing
> K{A,C}ASAN_SANITIZE_noinstr.o := n instead?
Disabling per file results in the non-instrumented header to be
#include'd, and so we never call the instrument_read/write explicitly.
So yes, this is a reasonable short-term fix.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2025-11-20 15:47 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-11-17 11:11 [PATCH] x86/sev: Disable GCOV on noinstr object Brendan Jackman
2025-11-17 11:40 ` Ard Biesheuvel
2025-11-17 11:51 ` Ard Biesheuvel
2025-11-17 12:37 ` Brendan Jackman
2025-11-20 11:41 ` Brendan Jackman
2025-11-20 15:47 ` Ard Biesheuvel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).