[+lists, format=plain text] On Sat, Sep 5, 2020 at 4:48 PM KP Singh <kpsingh@xxxxxxxxxx> wrote: > > > > On Sat, Sep 5, 2020 at 12:47 AM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: >> >> 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 >> } >> " > > > Indeed, if you want to associate some information with super_block objects > in LSM programs, local storage fits better. > > It would help if you can shed some more light on your use case. > >> Then it would be more efficient, faster, easier to use if you could >> extend the kernel with per-sb local storage. > > > Now that we have generalized local storage, this should not be much work. > > Please have a look at > https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/kernel/bpf/bpf_inode_storage.c > > and the example in: > > https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/tools/testing/selftests/bpf/progs/local_storage.c#n121 > > We will need something similar for super_block as well. > > - KP > >> 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.
