Re: [PATCH bpf-next v4 03/16] bpf: Add verifier diagnostic event log

[Eduard Zingerman <eddyz87@gmail.com>]

On Thu, 2026-08-13 at 01:33 +0200, Kumar Kartikeya Dwivedi wrote:

...

>  kernel/bpf/diagnostics.c | 108 +++++++++++++++++++++++++++++++++++++++
>  kernel/bpf/diagnostics.h |   3 ++
>  kernel/bpf/verifier.c    |  21 ++++++++
>  3 files changed, 132 insertions(+)
> 
> diff --git a/kernel/bpf/diagnostics.c b/kernel/bpf/diagnostics.c
> index 77dcffb9adee..0e0aa3a7106c 100644
> --- a/kernel/bpf/diagnostics.c
> +++ b/kernel/bpf/diagnostics.c
> @@ -34,8 +34,24 @@
>  #define BPF_DIAG_REG_TMP_LEN 192
>  #define BPF_DIAG_FMT_CHUNK_SIZE 1024
>  #define BPF_DIAG_FMT_BUF_SIZE 256
> +#define BPF_DIAG_EVENT_LOG_MAX_SIZE (1U << 20)

Q: did you observe the drops in practice?
   I'm curious what would be a practical limit here.
   As it stands the events buffer is 7K entries, seem to be low.

...

> +void bpf_diag_event_log_reset(struct bpf_verifier_env *env, u32 pos)
> +{
> +	struct bpf_diag *diag = env->diag;
> +	struct bpf_diag_log *log;
> +	u32 end;
> +
> +	if (!diag)
> +		return;
> +
> +	log = &diag->log;
> +	end = log->cnt;
> +	if (WARN_ON_ONCE(pos > end))
> +		pos = end;
> +
> +	log->cnt = pos;

Should this reset 'dropped' as well? 'capped'?
If not, do we need an exact count for 'dropped'?

> +}
> +

...