Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20201201215900.3569844-1-guro@fb.com> <CAADnVQJThW0_5jJ=0ejjc3jh+w9_qzctqfZ-GvJrNQcKiaGYEQ@mail.gmail.com>
 <20201203032645.GB1568874@carbon.DHCP.thefacebook.com> <6abdd146-c584-9c66-261d-d7d39ff3f499@iogearbox.net>
In-Reply-To: <6abdd146-c584-9c66-261d-d7d39ff3f499@iogearbox.net>
From:   Andrii Nakryiko <andrii.nakryiko@gmail.com>
Date:   Mon, 7 Dec 2020 18:53:33 -0800
Message-ID: <CAEf4BzYe1SDnWBzAP_U7NtUhu_cWa0EEMLv+d-q3YTFvP+y3og@mail.gmail.com>
Subject: Re: [PATCH bpf-next v9 00/34] bpf: switch to memcg-based memory accounting
To:     Daniel Borkmann <daniel@iogearbox.net>
Cc:     Roman Gushchin <guro@fb.com>,
        Alexei Starovoitov <alexei.starovoitov@gmail.com>,
        bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
        Network Development <netdev@vger.kernel.org>,
        Andrii Nakryiko <andrii@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        linux-mm <linux-mm@kvack.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Kernel Team <kernel-team@fb.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Dec 4, 2020 at 4:37 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> 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@fb.com> 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

I think the initial version was emitting 0 for memlock, so that was a
pretty simple way to prove stuff. But I think it was changed at the
last minute to emit some non-zero "estimate" of memory used or
something like that?

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