For the most part, the kernel doesn't provide generic string processing helpers. Most helpers are there to form the basis for specific eBPF integration points (the majority are packet and socket handling tools).
The kernel provides quite a few string processing helpers; I'm not sure why they're not documented. Perhaps the purpose of the document is to highlight bpf specific functionality rather than underlying runtime helpers?
And my point in highlighting them in this discussion was to get one to consider how of trap outs to the kernel are sort of fundamental. You get 4096 instructions to execute before you're cut off by the kernel (albeit statically). Given that, say, PATH_MAX is 32768, then you simply don't have enough compute time available to process certain strings you'd expect some bpf filters to be able to handle.
So basically I just wanted to hit home that some raw computation expected of bpf is incompatible with it's current verification model and at the very least extremely deep changes to bpf would need to occur to get rid of helpers.
They are semantically simple string operations whose computational complexity scales with string length.
Near unbound string lengths would exhaust the time (somewhat aproximated by instruction) budget of eBPF applications doing even a single one.
I think the point was not to show "there are a lot of helper functions" but rather to point out "the (undocumented) helper functions that exist are problematic"
There are others listed in the thread. The specific quantity of 'quite a few' is orthogonal to the core point and was intentionally left vague in what now appears to be a misguided attempt to keep the comment concise and focused.
You can see them listed here: https://elixir.bootlin.com/linux/latest/source/kernel/bpf/he...
And my point in highlighting them in this discussion was to get one to consider how of trap outs to the kernel are sort of fundamental. You get 4096 instructions to execute before you're cut off by the kernel (albeit statically). Given that, say, PATH_MAX is 32768, then you simply don't have enough compute time available to process certain strings you'd expect some bpf filters to be able to handle.
So basically I just wanted to hit home that some raw computation expected of bpf is incompatible with it's current verification model and at the very least extremely deep changes to bpf would need to occur to get rid of helpers.