Hi, I've been working with the CRIU project to enable CRIU to checkpoint and restore BPF map files. (https://github.com/checkpoint-restore/criu/issues/777). A key component of the solution involves dumping the data contained in BPF maps. However, I have been unable to do this due to the following reason - as far as I'm aware, Linux does not provide an interface to directly retrieve the key-value pairs stored in a BPF map without prior knowledge about the nature of data stored in it. To explain what I mean by 'without prior information about the data stored', let's take the example of a BPF map that stores key-value pairs in the form of a hash table (BPF_MAP_TYPE_HASH). The only way to iterate through all the key-value pairs in this map is to use BPF_MAP_GET_NEXT_KEY. However, if I start with a lookup key that exists in the map, I will only be able to iterate through the key-value pairs that occur after this key. Therefore, I must start with a lookup key that does not already exist in the map, so that BPF_MAP_GET_NEXT_KEY returns the map's first key. However, information about the nature of data stored in the map is only available to the application programmer, and it will hence be difficult for CRIU to guess a key that does not exist in the map. I would therefore like to discuss the possibility of extending Linux's BPF API to provide easier access to the data contained in BPF maps, in a manner that works for all types of maps and is potentially future-proof for other kinds of maps that may be added. As I currently understand, this problem stems from the fact that reading and writing to a BPF map's kernel buffer is only possible using the BPF system call. Therefore, functionality that allows reading from and writing to the map in a manner that is agnostic to the nature of data stored in it (similar to tee and splice for pipes) would enable checkpointing and restoring BPF map data. Do let me know if anything I have written is factually incorrect and also if there is something I can explain more clearly. I look forward to hearing the kernel community's thoughts on this. Thank you, Abhishek Vijeev.
