Re: [RFC PATCH 15/16] selftests/membarrier: Check the memory barriers of each thread

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

> [Severity: Medium]
> Does setting setup_broken = true before bpf_object__load() and
> bpf_program__attach() cause main() to fail instead of skipping when the
> kernel lacks required BPF features?
>
> A kernel with CONFIG_DEBUG_INFO_BTF=y and CONFIG_PROC_KCORE=y can still
> lack CONFIG_BPF_EVENTS=y (needed to load kprobe/tracing programs and
> BPF_MAP_TYPE_TASK_STORAGE) or have BPF JIT disabled (needed to attach
> tp_btf/sched_switch).

Yes for CONFIG_BPF_EVENTS. The same holds for CONFIG_KPROBE_EVENTS,
which the kprobes of the test need. The test should skip in both cases.

The BPF JIT is not needed. The sched_switch program is attached as a raw
tracepoint, which does not use a BPF trampoline. I built a kernel
without CONFIG_BPF_JIT: the test attaches and all 13 test cases pass.

Planned fix for the next round: bpf_setup() checks both options before
it treats an error as a failure. It probes the kprobe program type with
libbpf_probe_bpf_prog_type(), and it looks for the kprobe PMU in sysfs.
I tested this on a kernel without each option: the test is skipped.

> [Severity: Medium]
> Does calling pin_to_cpu(target->cpu) before map_counters() miss the
> lazy-TLB context switch in global_expedited_lazy_tlb?

[...]

> As a result, sched_switch never sets OWES_BARRIER or increments
> MBT_SCHED_IN for that lazy-TLB switch.  Calling map_counters() before
> pin_to_cpu(target->cpu) registers the thread in task_slot before it
> migrates back to cpus[1].

Yes. The target moves back to its CPU before it has a counter slot. The
BPF program does not see that switch, so the barrier which the scheduler
owes the target there is not checked.

The checks of each call start after the registration, so they are not
affected. Without the fix of patch 1, the test case still fails.

Planned fix for the next round: run_target() calls map_counters() before
pin_to_cpu().

> [Severity: Low]
> Can zeroing shared->next_slot in reset_shared() let an exiting task from a
> finished test case clobber the BPF counters of a new thread in the next
> test case?

[...]

> Preserving shared->next_slot across reset_shared() avoids reusing counter
> slots across test cases.

Yes, this window exists. I did not reproduce it.

Planned fix for the next round: reset_shared() keeps next_slot. The 13
test cases use about 270 of the 512 slots at most.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com