Switch from bpf_get_stackid() to bpf_get_stack()

[bobrik]

To use bpf_get_stack() we need a newer kernel.

Getting rid of bpf_get_stackid() also lets us get rid of the 16MiB map:

$ sudo bpftool map show name kernel_stackmap
31557211: stack_trace  name kernel_stackmap  flags 0x0
        key 4B  value 1016B  max_entries 16384  memlock 17039648B
        pids ebpf-profiler(3973147)

Plus the costs of reading the map for every sample with kernel compoments.

Instead of saving the stack id into the map, we now save the actual kernel frames into the same list of frames where all other frames go.

See: #1257.

[bobrik]

I saw two approaches to this:

1. Save the kernel stack as an array of u64 addresses and do specialized parsing in userspace. It's kind of similar to how stack id was turned into actual frames.
2. Produce proper kernel frames and do no specialized parsing in userspace. Kernel is just another kind of an interpreter.

I think the second approach is nicer, so I opted for that. I can be persuaded otherwise.

This doesn't work on v5.4. I'm not sure what the status of dropping support for that.

I have this running in production and it looks right compared to #1257:

[fabled]

Thanks for working on this! Added some comments on the frame data format.

[bobrik]

I updated to push kernel frames as a list of u64 at the beginning of frame_data directly via bpf_get_stack(). This is the approach number 1 from here. It's a bit more work for userspace to separate and stitch them with the rest of the frames, but it is less data copied from the kernel and it's easier on the verifier.

I'll deploy this internally to make sure everything looks right.

[fabled]

Thanks so much! Looks very neat and clean. Few minor clean up comments still.

[bobrik]

I incorporated all 3 suggestions.

[fabled]

Thanks! lgtm! @florianl @christos68k can either of you take a second review?

[florianl]

Works fine and thanks for the work!