Re: [PATCH bpf-next v2 8/8] selftests/bpf: add tests to validate KASAN on JIT programs

["Alexis Lothoré" <alexis.lothore@bootlin.com>]

On Thu Jun 4, 2026 at 11:45 PM CEST, bot+bpf-ci wrote:

[...]

> The Sashiko AI review on the RFC v1 8/8 posting raised a concern here that
> does not seem to have been addressed in v2:
>
>   https://lore.kernel.org/bpf/20260425065049.BEC63C2BCB0@smtp.kernel.org
>
> The original question was:
>
>   KASAN operates in single-shot mode by default. After the first subtest
>   triggers a report, will subsequent reports be suppressed, causing the
>   remaining subtests to fail? Also, since BPF CI runs with panic_on_warn=1,
>   will the first KASAN splat invoke check_panic_on_warn() and immediately
>   panic the CI runner?
>
> KASAN runs in single-shot mode by default. mm/kasan/report.c suppresses
> reports after the first one unless kasan_multi_shot is set.
>
> This loop runs roughly 50 subtests, and each one expects a fresh KASAN
> report emitted via the JIT-inserted __asan_load/__asan_store calls that go
> through kasan_report().
>
> Under default single-shot KASAN, would the subtests after the first one see
> no report and fail the positive assertions?
>
> Separately, BPF CI runs with panic_on_warn=1 (config.ppc64el still sets
> panic_on_warn=1). Would the first KASAN splat reach check_panic_on_warn()
> and panic the runner?
>
> Nothing in v2 appears to enable kasan_multi_shot or guard against
> panic_on_warn. Was this intended to be handled somewhere?

Hoping to silence this one on the next revision: CI has been updated
separately to enable kasan_multi_shot, and so all subtests in v2
properly triggered the reports individually. The commit is lacking
documentation about this need though.

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com