Re: HASH_OF_MAPS inner map allocation from BPF

[Borna Cafuk <borna.cafuk@sartura.hr>]

On Sat, Sep 5, 2020 at 12:47 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Fri, Sep 4, 2020 at 7:57 AM Borna Cafuk <borna.cafuk@sartura.hr> 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.

No, it wasn't me who asked that question, but it seemed close enough to
my issue. My use case calls for modifying the syscount example from BCC[1].

The idea is to have an outer map where the keys are PIDs, and inner maps where
the keys are system call numbers. This would enable tracking the number of
syscalls made by each process and the makeup of those calls for all processes
simultaneously.

[1] https://github.com/iovisor/bcc/blob/master/libbpf-tools/syscount.bpf.c


>
> 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.