> diff --git a/tools/testing/selftests/bpf/bpf_experimental.h
> b/tools/testing/selftests/bpf/bpf_experimental.h
> index a39576c8ba..87706a213a 100644
> --- a/tools/testing/selftests/bpf/bpf_experimental.h
> +++ b/tools/testing/selftests/bpf/bpf_experimental.h
> @@ -628,7 +628,7 @@ static inline int get_preempt_count(void)
> #elif defined(bpf_target_arm64)
> return bpf_get_current_task_btf()->thread_info.preempt.count;
> #endif
> - return 0;
> + return -1;
> }
Returning -1 here causes incorrect behavior in all the bpf_in_* helper
functions that call get_preempt_count(). Since -1 is 0xFFFFFFFF in
twos complement, the bitmask operations in the callers produce non-zero
results:
bpf_in_nmi(): -1 & NMI_MASK = 0x00F00000 (non-zero)
bpf_in_hardirq(): -1 & HARDIRQ_MASK = 0x000F0000 (non-zero)
bpf_in_interrupt(): returns non-zero (falsely indicates interrupt ctx)
bpf_in_serving_softirq(): returns non-zero
bpf_in_task(): returns 0 (falsely indicates NOT in task context)
Previously with return 0, these functions would return 0 on unsupported
architectures. Now they return false positives indicating the system is
in NMI/hardirq/softirq context when it may not be.
Should the callers be updated to check for -1 before performing the
bitmask operations? For example:
static inline int bpf_in_nmi(void)
{
int pcnt = get_preempt_count();
if (pcnt < 0)
return -1; /* or 0? */
return pcnt & NMI_MASK;
}
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/21466700415
AI-authorship-score: low
AI-authorship-explanation: Simple one-line change with clear human-authored
commit message following standard kernel conventions.
issues-found: 1
issue-severity-score: low
issue-severity-explanation: Incomplete API change causes bpf_in_* functions to
return false positives on unsupported architectures, but this only affects
selftest code on non-x86/arm64 systems.
