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