fix(bpf): Access __state from task_struct

[dave-tucker]

In older kernels prev_state isn't passed as part of the context of the
function. Therefore it's better to access prev_task-->_state directly.

The field was renamed from state to __state in Kernel 5.14.
Given that we need to support Kernel 5.12+ we include the
bpf_core_read.h file such that we can use the bpf_core_field_exists
function that allows us to see which field is present in task struct
and return the correct value.

[github-actions]

🤖 SeineSailor

Here is a concise summary of the pull request changes:

Summary: The fix(bpf): Access __state from task_struct pull request introduces changes to access prev_task->__state directly in older kernel versions where prev_state isn't passed as part of the function context.

Key Modifications:

1. New helper function: A new get_task_state helper function is introduced to facilitate accessing task structures.
2. New header file: A new bpf_core_read.h header file is added to provide a standardized way of accessing task structures.

Impact on Codebase:

• The changes are internal and do not affect the external interface or behavior of the code.
• The modifications ensure compatibility with older kernel versions where prev_state is not passed as part of the function context.

Observations and Suggestions:

• The changes seem to be well-contained and do not introduce any breaking changes to the codebase.
• It would be beneficial to include additional tests to ensure the new get_task_state function works correctly in different kernel versions.
• Consider adding documentation to the bpf_core_read.h header file to explain its purpose and usage.

Overall, the pull request appears to be a well-structured and targeted fix to ensure compatibility with older kernel versions.

[sthaha]

Is it fixed / defined what the size of int is ?

[dave-tucker]

Yes. https://github.com/sustainable-computing-io/kepler/blob/main/bpfassets/libbpf/src/kepler.bpf.h#L8

[dave-tucker]

Also, these fields are BTF relocated - which will perform the necessary checks around int size and signedness at program load time.

[sthaha]

Thanks Dave.
Related question ... shouldn't we use unsigned int or u32 for pid as well?

[marceloamaral]

Shouldn't we use BPF_CORE_READ() to read the pointers in a safe manner?

[dave-tucker]

@sthaha I'm just using whatever is used in task_struct in the kernel - see https://elixir.bootlin.com/linux/latest/source/include/linux/sched.h#L977

if you follow the links from pid_t down to a concrete type you get to https://elixir.bootlin.com/linux/latest/source/include/uapi/asm-generic/posix_types.h#L28

@marceloamaral no you don't need to use BPF_CORE_READ in tp_btf programs.
https://mozillazg.com/2022/06/ebpf-libbpf-btf-powered-enabled-raw-tracepoint-common-questions-en.html#hidthe-difference-between-btf-raw-tracepoint-and-raw-tracepoint

[sthaha]

Thanks a lot for clarifications, @dave-tucker 🙏

[marceloamaral]

/lgtm