Follow up on "Are BPF programs preemptible?"

[anjmao]

Hi, I saw this mailing list https://lore.kernel.org/bpf/CAMy7=ZWPc279vnKK6L1fssp5h7cb6cqS9_EuMNbfVBg_ixmTrQ@mail.gmail.com/T/

Would be awesome if you could give some insights regarding this issue and impact on tracee?
I looked at tracee ebpf code and it seems that it hasn't been fixed or I'm missing something?
I would be really helpful to clarify this, since ebpf documentation around preemption is misleading in some places.

[yanivagman]

Actually we implemented a couple of changes in response to the post I made and the subsequent feedback received on the mailing list. After making these two changes, we no longer encountered the previously observed issue. Specifically:

1. We introduced a dedicated buffer for network events (which can preempt other events): https://github.com/aquasecurity/tracee/blob/main/pkg/ebpf/c/tracee.bpf.c#L5797
2. We removed the 'sched_process_free' event because it could potentially corrupt the buffer used by other events, as it can be called from softirq context: https://github.com/aquasecurity/tracee/blob/main/pkg/ebpf/c/tracee.bpf.c#L1388

[anjmao]

Thanks. So does it mean there are some specific cases only for preemption of other programs like network event and sched_process_free?

Let's say I have such program for syscall, I would think that the same program can preempt it's execution and modify event data map value before submit (concurrent syscalls)

SEC("raw_tracepoint/trace_sys_enter")
int trace_sys_enter(struct bpf_raw_tracepoint_args *ctx)
{
    program_data_t p = {};
    p->event = bpf_map_lookup_elem(&event_data_map, &zero);
    p->event.context.task.host_tid = 9;

    events_perf_submit(&p, RAW_SYS_ENTER, 0);
    return 0;
}