> diff --git a/tools/testing/selftests/bpf/prog_tests/kasan.c
> b/tools/testing/selftests/bpf/prog_tests/kasan.c
> new file mode 100644
> index 000000000000..0000000000000
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/kasan.c
> @@ -0,0 +1,356 @@
[ ... ]
> + ctx->klog_fd = open_kernel_logs();
> + if (!ASSERT_OK_FD(ctx->klog_fd, "open kernel logs"))
> + goto destroy;
[ ... ]
> + for (i = 0; i < ARRAY_SIZE(tests); i++) {
> + test = &tests[i];
> + run_subtest(ctx, test);
> + }
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/[email protected]
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?
> diff --git a/tools/testing/selftests/bpf/progs/kasan.c
> b/tools/testing/selftests/bpf/progs/kasan.c
> new file mode 100644
> index 000000000000..670318a956a4
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/kasan.c
> @@ -0,0 +1,382 @@
[ ... ]
> +SEC("tcx/ingress")
> +int stx_on_stack(struct __sk_buff *skb)
> +{
> + struct kasan_write_val val;
> +
> + bpf_kfunc_kasan_poison(&val, sizeof(struct kasan_write_val));
> + switch (access_size) {
> + case 1:
> + val.data_1 = access_size;
> + break;
> + case 2:
> + val.data_2 = access_size;
> + break;
> + case 4:
> + val.data_4 = access_size;
> + break;
> + case 8:
> + val.data_8 = access_size;
> + break;
> + }
> + bpf_kfunc_kasan_poison(&val, sizeof(struct kasan_write_val));
This isn't a bug, but should this second call be
bpf_kfunc_kasan_unpoison() rather than bpf_kfunc_kasan_poison()?
Every other program in this file (st_on_stack, st_not_on_stack, ldx_*,
simple_atomic_*, load_acquire_*, store_release_*) calls
bpf_kfunc_kasan_unpoison() after the access, and stx_not_on_stack below
repeats the same poison-twice pattern.
> + return 0;
> +}
[ ... ]
> +SEC("tcx/ingress")
> +int stx_not_on_stack(struct __sk_buff *skb)
> +{
[ ... ]
> + bpf_kfunc_kasan_poison(val, sizeof(struct kasan_write_val));
> + switch (access_size) {
> + case 1:
> + val->data_1 = access_size;
> + break;
[ ... ]
> + }
> + bpf_kfunc_kasan_poison(val, sizeof(struct kasan_write_val));
Same question here as in stx_on_stack: the second call is
bpf_kfunc_kasan_poison() where the other programs use
bpf_kfunc_kasan_unpoison().
The intended store still happens while the memory is poisoned, so the
expected KASAN report is still generated and the positive assertion still
passes. The effect is that the leftover poison stays on the test_map slab
value (and on the stack region for stx_on_stack) until the next subtest
re-poisons and unpoisons the same region. Was poisoning a second time here
intentional?
> + return 0;
> +}
---
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/26978380520
