Weird error " FnSeqWrite for program type Tracing not supported"

[Andreagit97]

Describe the bug

In my program I would like to use BPF iters progs (more in detail SEC("iter/task")). I'm correctly able to load iter progrs without issues but now I would like to add some checks to ensure that the running kernel supports iterators so i added the following code:

	if err := features.HaveProgramType(ebpf.Tracing); err != nil {
		if errors.Is(err, ebpf.ErrNotSupported) {
			fmt.Printf("1: %v\n", err)
		} else {
			fmt.Printf("2: %v\n", err)
		}
		return err
	}

	if err := features.HaveProgramHelper(ebpf.Tracing, asm.FnSeqWrite); err != nil {
		if errors.Is(err, ebpf.ErrNotSupported) {
			fmt.Printf("3: %v\n", err) // < --- fails here see the log below
		} else {
			fmt.Printf("4: %v\n", err)
		}
		return err
	}

       ...

And I obtain the following error:

3: FnSeqWrite for program type Tracing not supported

This is weird because I'm actually using bpf_seq_write helper in my bpf c program and before I added this check it ran without issues.
Is this the intended behavior?

Moreover, If I understood correctly features.HaveProgramType(ebpf.Tracing) tries to probe the attach type ebpf.AttachTraceFEntry that is different from ebpf.AttachTraceIter. Is there a way to check directly the ebpf.AttachTraceIter attach type?

go version

go version go1.18.1 linux/amd64

uname -a

Linux 5.19.0-45-generic #46~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Jun 7 15:06:04 UTC 20 x86_64 x86_64 x86_64 GNU/Linux

cat /etc/issue

Ubuntu 22.04.2 LTS

cilium/ebpf library version

v0.10.0

Expected behavior

Probably features.HaveProgramHelper(ebpf.Tracing, asm.FnSeqWrite); should return nil or maybe I misunderstood its usage. Thank you in advance!

[lmb]

cc @rgo3

[rgo3]

Hello @Andreagit97!

The current behaviour of HaveProgramHelper(ebpf.Tracing, asm.FnSeqWrite) is a bug as it is returning a false negative. Previous to c7ba7f0 calling HaveProgramHelper(ebpf.Tracing, ...) would result in no feature probe for Tracing. Now that we have a probe for program type Tracing, this part of HaveProgramHelper(ebpf.Tracing, ...) will pass but we don't actually create a valid probe for any possible program type/helper combination which yields the false negative.

I'll spend some more time to investigate other options but the output of bpftool feature probe doesn't give hopeful results:

eBPF helpers supported for program type tracing:
	Could not determine which helpers are available
eBPF helpers supported for program type struct_ops:
	Could not determine which helpers are available
eBPF helpers supported for program type ext:
	Could not determine which helpers are available
eBPF helpers supported for program type lsm:
	Could not determine which helpers are available

I'm afraid that creating a generalized helper probe for certain program types (StructOps, Tracing, Extension, LSM) might be quite hard/cumbersome if available helpers depend on the attach type as well. In that case the easiest solution for now could be fixing the bug by returning an inconclusive result telling the caller that we are not able to probe helpers for those program types.

Wrt to HaveProgramType(ebpf.Tracing), there is currently no API to check different attach types, e.g. ebpf.AttachTraceIter. HaveProgramType is really only responsible to ensure a program type is available in the kernel, regardless of the attach type.

[Andreagit97]

I'm afraid that creating a generalized helper probe for certain program types (StructOps, Tracing, Extension, LSM) might be quite hard/cumbersome if available helpers depend on the attach type as well. In that case the easiest solution for now could be fixing the bug by returning an inconclusive result telling the caller that we are not able to probe helpers for those program types.

It seems a reasonable fix! thank you

Wrt to HaveProgramType(ebpf.Tracing), there is currently no API to check different attach types, e.g. ebpf.AttachTraceIter. HaveProgramType is really only responsible to ensure a program type is available in the kernel, regardless of the attach type.

Got it! thank you for the explanation