On Fri, Sep 4, 2020 at 7:57 AM Borna Cafuk <borna.cafuk@xxxxxxxxxx> wrote: > > Hello everyone, > > Judging by [0], the inner maps in BPF_MAP_TYPE_HASH_OF_MAPS can only be created > from the userspace. This seems quite limiting in regard to what can be done > with them. > > Are there any plans to allow for creating the inner maps from BPF programs? > > [0] https://stackoverflow.com/a/63391528 Did you ask that question or your use case is different? Creating a new map for map_in_map from bpf prog can be implemented. bpf_map_update_elem() is doing memory allocation for map elements. In such a case calling this helper on map_in_map can, in theory, create a new inner map and insert it into the outer map. But if your use case it what stackoverflow says: " SEC("lsm/sb_alloc_security") int BPF_PROG(sb_alloc_security, struct super_block *sb) { uuid_t key = sb->s_uuid; // use super block UUID as key to the outer_map // If key does not exist in outer_map, // create a new inner map and insert it // into the outer_map with the key } " Then it would be more efficient, faster, easier to use if you could extend the kernel with per-sb local storage. We already have socket- and inode- local storage. Other kernel data structures will fit the same infra. You wouldn't need to hook into sb_alloc_security either. >From other lsm hooks you'll ask for super_block-local_stoarge and scratch memory will be allocated on demand and automatically freed with sb.
