Re: [RFC PATCH v2 0/6] kcov: per-task dataflow extraction at kernel function boundaries

Hi Peter,

> On Fri, Jun 12, 2026 at 09:37:40AM +0200, Yunseong Kim wrote:
>> Hi Peter,
>>
>>> On Wed, Jun 03, 2026 at 07:43:27PM +0200, Yunseong Kim wrote:
>>>> CONFIG_KCOV_DATAFLOW_INSTRUMENT_ALL instruments every function in the
>>>> kernel. 
>>>
>>> Well, I would hope it would very much not instrument noinstr functions.
>>
>> Thank you for your guidance. I updated the default
>> CONFIG_KCOV_DATAFLOW_NO_INLINE to n.
> 
> That's not really the point. The compiler extension *must* respect
> noinstr. If there it no function attribute to suppress this kcov stuff,
> then its an absolute non-starter.

Thank you again, for pointing that out.

I've been using the same mechanism that KCOV (trace-pc) already relies on.
trace-args/ret shares the identical code path and attribute check.

LLVM side:

noinstr functions are never instrumented because the existing
NoSanitizeCoverage attribute check at the top of the function-level pass
covers all SanCov instrumentation types including trace-args/ret.

  1. Marked functions as noinstr expands to __no_sanitize_coverage, emits
   __attribute__((no_sanitize("coverage")))

  2. Clang translates that to Attribute::NoSanitizeCoverage

  3. llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp

     if (F.hasFnAttribute(Attribute::NoSanitizeCoverage))

     https://github.com/llvm/llvm-project/commit/280333021e95#diff-1b024748b036cfd10a7c3dfc7e9c53b0f752b27d7ea193939c59b2de60f69a70R445

  4. skips ALL instrumentation including trace-args/trace-ret

Dobule check with objtool:

Even KCOV_DATAFLOW_NO_INLINE enabled kernel:

  $ for fn in ct_nmi_enter ct_nmi_exit exc_nmi syscall_enter_from_user_mode; do
      count=$(objdump -d vmlinux --disassemble=$fn | grep -c sanitizer_cov)
      echo "$fn: $count sanitizer calls"
    done
  
  ct_nmi_enter: 0 sanitizer calls
  ct_nmi_exit: 0 sanitizer calls
  exc_nmi: 0 sanitizer calls
  syscall_enter_from_user_mode: 0 sanitizer calls

If Rust noinstr functions are added in the future, they would use                          
#[no_sanitize(coverage)]. This maps to the same Attribute::NoSanitizeCoverage                                                          
LLVM attribute, yielding the exact same check and result.


Best regards,
Yunseong