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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 5 Dec 2020 01:37:14 +0100 From: Daniel Borkmann <daniel@...earbox.net> To: Roman Gushchin <guro@...com>, Alexei Starovoitov <alexei.starovoitov@...il.com> Cc: bpf <bpf@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>, Network Development <netdev@...r.kernel.org>, Andrii Nakryiko <andrii@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, linux-mm <linux-mm@...ck.org>, LKML <linux-kernel@...r.kernel.org>, Kernel Team <kernel-team@...com> Subject: Re: [PATCH bpf-next v9 00/34] bpf: switch to memcg-based memory accounting 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@...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 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).
Powered by blists - more mailing lists