netdev - Re: [PATCH bpf-next v3 3/6] bpf: allow for map-in-map with dynamic inner array map entries

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 9 Oct 2020 14:04:13 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     ast@...nel.org, john.fastabend@...il.com, yhs@...com,
        netdev@...r.kernel.org, bpf@...r.kernel.org,
        Andrii Nakryiko <andrii.nakryiko@...il.com>
Subject: Re: [PATCH bpf-next v3 3/6] bpf: allow for map-in-map with dynamic
 inner array map entries

On Fri, Oct 09, 2020 at 10:42:42PM +0200, Daniel Borkmann wrote:
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index b97bc5abb3b8..593963e40956 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -435,6 +435,11 @@ enum {
>  
>  /* Share perf_event among processes */
>  	BPF_F_PRESERVE_ELEMS	= (1U << 11),
> +
> +/* Do not inline (array) map lookups so the array map can be used for
> + * map in map with dynamic max entries.
> + */
> +	BPF_F_NO_INLINE		= (1U << 12),
>  };

I'm worried about this one.
It exposes internal detail into uapi.
Most users are not even aware of that map_lookup_elem() can be 'inlined'.

How about renaming the flag into BPF_F_INNER_MAP ?
This way if we change the implementation later it will still be sane from uapi pov.
The comment above the flag can say:
/* Create a map that is suitable to be an inner map with dynamic max entries  */

Or some other name ?
May be tomorrow we decide to simply load max_entries value in array_map_gen_lookup().
The progs will become a bit slower, but it could be fine if we also do another
optimization at the same time. Like the verifier can detect that 'key' is const
and optimize it even further. Than slower gen_lookup for inner and all arrays
will be mitigated by ultra fast lookup when !F_INNER_MAP and key is const.
For F_INNER_MAP and key is const we could still do better inlining.