Re: [PATCH bpf-next v9 00/34] bpf: switch to memcg-based memory accounting

[Daniel Borkmann]

On 12/3/20 4:26 AM, Roman Gushchin wrote:
> On Wed, Dec 02, 2020 at 06:54:46PM -0800, Alexei Starovoitov wrote:
> > On Tue, Dec 1, 2020 at 1:59 PM Roman Gushchin <guro@xxxxxx> wrote:
> > > 5) Cryptic -EPERM is returned on exceeding the limit. Libbpf even had
> > >     a function to "explain" this case for users.
> > ...
> > > v9:
> > >    - always charge the saved memory cgroup, by Daniel, Toke and Alexei
> > >    - added bpf_map_kzalloc()
> > >    - rebase and minor fixes
> >
> > This looks great. Applied.
>
> Thanks!
>
> > Please follow up with a change to libbpf's pr_perm_msg().
> > That helpful warning should stay for old kernels, but it would be
> > misleading for new kernels.
> > libbpf probably needs a feature check to make this warning conditional.
>
> I think we've discussed it several months ago and at that time we didn't
> find a good way to check this feature. I'll think again, but if somebody
> has any ideas here, I'll appreciate a lot.

Hm, bit tricky, agree .. given we only throw the warning in pr_perm_msg() for
non-root and thus probing options are also limited, otherwise just probing for
a helper that was added in this same cycle would have been good enough as a
simple heuristic. I wonder if it would make sense to add some hint inside the
bpf_{prog,map}_show_fdinfo() to indicate that accounting with memcg is enabled
for the prog/map one way or another? Not just for the sake of pr_perm_msg(), but
in general for apps to stop messing with rlimit at this point. Maybe also bpftool
feature probe could be extended to indicate that as well (e.g. the json output
can be fed into Go natively).