On Mon, 12 Feb 2024 at 21:48, Matt Bobrowski <mattbobrowski@xxxxxxxxxx> wrote: > > [...] > > Now having said this, I'm wondering whether anyone here has considered > possibly solving this iterator based problem a little more > generically? That is, by exposing a set of kfuncs that allow you to > iterate over a list_head, hlist_head, rbtree, etc, independent of an > underlying in-kernel type and similar to your *list_for_each*() based > helpers that you'd typically find for each of these in-kernel generic > data structures. If so, what were your findings when exploring this > problem space? > I think I agree with Song that it might be unavoidable to introduce separate kfuncs to iterate over separate types (due to locking/RCU requirements, and other minor reasons in how the iterator is supposed to be initialized). I think you can use some C11 tricks to make this convenient when writing programs though. It's a bit like how iterators work in C++ (the real implementation is behind the class methods begin, end, operator++), and a templated function could dispatch to the right ones by monomorphization on call with different types. In C, you could use _Generic to dispatch to the right kfunc based on the type of the struct on the stack. The only downside is that you need to keep updating the macro with each new iterator. Here is a godbolt link demonstrating the idea of a range-for loop like in C++, copied out and simplified from a BPF program I have which is not public yet. https://godbolt.org/z/TWjP636Pv The idea that Alexei linked to (using a number iterator with high 1M limit to iterate over in-kernel untrusted/rdonly ptr_to_btf_id) can also be accommodated into this. > /M >
