From: Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>
To: Jiri Olsa <olsajiri@gmail.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, andrii@kernel.org,
daniel@iogearbox.net, kafai@meta.com, kernel-team@meta.com,
Mykyta Yatsenko <yatsenko@meta.com>
Subject: Re: [PATCH bpf-next] selftests/bpf: increase verifier log limit in veristat
Date: Mon, 21 Oct 2024 21:34:24 +0100 [thread overview]
Message-ID: <04056da1-a477-4dce-8466-04eef9428384@gmail.com> (raw)
In-Reply-To: <ZxaE_C_Im9-I8OSa@krava>
On 21/10/2024 17:44, Jiri Olsa wrote:
> On Mon, Oct 21, 2024 at 03:16:16PM +0100, Mykyta Yatsenko wrote:
>> From: Mykyta Yatsenko <yatsenko@meta.com>
>>
>> The current default buffer size of 16MB allocated by veristat is no
>> longer sufficient to hold the verifier logs of some production BPF
>> programs. To address this issue, we need to increase the verifier log
>> limit.
>> Commit 7a9f5c65abcc ("bpf: increase verifier log limit") has already
>> increased the supported buffer size by the kernel, but veristat users
>> need to explicitly pass a log size argument to use the bigger log.
>>
>> This patch adds a function to detect the maximum verifier log size
>> supported by the kernel and uses that by default in veristat.
>> This ensures that veristat can handle larger verifier logs without
>> requiring users to manually specify the log size.
>>
>> Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com>
>> ---
>> tools/testing/selftests/bpf/veristat.c | 40 +++++++++++++++++++++++++-
>> 1 file changed, 39 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/testing/selftests/bpf/veristat.c b/tools/testing/selftests/bpf/veristat.c
>> index c8efd44590d9..1d0708839f4b 100644
>> --- a/tools/testing/selftests/bpf/veristat.c
>> +++ b/tools/testing/selftests/bpf/veristat.c
>> @@ -16,10 +16,12 @@
>> #include <sys/stat.h>
>> #include <bpf/libbpf.h>
>> #include <bpf/btf.h>
>> +#include <bpf/bpf.h>
>> #include <libelf.h>
>> #include <gelf.h>
>> #include <float.h>
>> #include <math.h>
>> +#include <linux/filter.h>
>>
>> #ifndef ARRAY_SIZE
>> #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
>> @@ -1109,6 +1111,42 @@ static void fixup_obj(struct bpf_object *obj, struct bpf_program *prog, const ch
>> return;
>> }
>>
>> +static int max_verifier_log_size(void)
>> +{
>> + const int big_log_size = UINT_MAX >> 2;
>> + const int small_log_size = UINT_MAX >> 8;
>> + struct bpf_insn insns[] = {
>> + BPF_MOV64_IMM(BPF_REG_0, 0),
>> + BPF_EXIT_INSN(),
>> + };
>> + int ret, insn_cnt = ARRAY_SIZE(insns);
>> + char *log_buf;
>> + static int log_size;
>> +
>> + if (log_size != 0)
>> + return log_size;
>> +
>> + log_size = small_log_size;
>> + log_buf = malloc(big_log_size);
> IIUC this would try to use 1GB by default? seems to agresive.. could we perhaps
> do that gradually and double the size on each failed load attempt?
>
> jirka
Yes, this allocates 1GB by default, I expect this is not a big of a
problem if verifier
does not touch all that memory.
I tried doing gradual allocation initially, but that requires more
significant rework
of the code.
Thanks for looking into this patch!
>
>> +
>> + if (!log_buf)
>> + return log_size;
>> +
>> + LIBBPF_OPTS(bpf_prog_load_opts, opts,
>> + .log_buf = log_buf,
>> + .log_size = big_log_size,
>> + .log_level = 2
>> + );
>> + ret = bpf_prog_load(BPF_PROG_TYPE_SOCKET_FILTER, NULL, "GPL", insns, insn_cnt, &opts);
>> + free(log_buf);
>> +
>> + if (ret > 0) {
>> + log_size = big_log_size;
>> + close(ret);
>> + }
>> + return log_size;
>> +}
>> +
>> static int process_prog(const char *filename, struct bpf_object *obj, struct bpf_program *prog)
>> {
>> const char *base_filename = basename(strdupa(filename));
>> @@ -1132,7 +1170,7 @@ static int process_prog(const char *filename, struct bpf_object *obj, struct bpf
>> memset(stats, 0, sizeof(*stats));
>>
>> if (env.verbose || env.top_src_lines > 0) {
>> - buf_sz = env.log_size ? env.log_size : 16 * 1024 * 1024;
>> + buf_sz = env.log_size ? env.log_size : max_verifier_log_size();
>> buf = malloc(buf_sz);
>> if (!buf)
>> return -ENOMEM;
>> --
>> 2.47.0
>>
>>
prev parent reply other threads:[~2024-10-21 20:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-21 14:16 [PATCH bpf-next] selftests/bpf: increase verifier log limit in veristat Mykyta Yatsenko
2024-10-21 16:44 ` Jiri Olsa
2024-10-21 20:14 ` Andrii Nakryiko
2024-10-21 20:38 ` Mykyta Yatsenko
2024-10-21 20:44 ` Eduard Zingerman
2024-10-21 20:34 ` Mykyta Yatsenko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=04056da1-a477-4dce-8466-04eef9428384@gmail.com \
--to=mykyta.yatsenko5@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kafai@meta.com \
--cc=kernel-team@meta.com \
--cc=olsajiri@gmail.com \
--cc=yatsenko@meta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.