[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZpHOQoyEE7Rl1ky8@LQ3V64L9R2>
Date: Fri, 12 Jul 2024 17:45:54 -0700
From: Joe Damato <jdamato@...tly.com>
To: Kyle Huey <me@...ehuey.com>
Cc: Jiri Olsa <olsajiri@...il.com>, linux-kernel@...r.kernel.org,
bpf@...r.kernel.org, netdev@...r.kernel.org, acme@...nel.org,
andrii.nakryiko@...il.com, elver@...gle.com, khuey@...ehuey.com,
mingo@...nel.org, namhyung@...nel.org, peterz@...radead.org,
robert@...llahan.org, yonghong.song@...ux.dev,
mkarsten@...terloo.ca, kuba@...nel.org
Subject: Re: [bpf?] [net-next ?] [RESEND] possible bpf overflow/output bug
introduced in 6.10rc1 ?
On Fri, Jul 12, 2024 at 04:30:31PM -0700, Kyle Huey wrote:
> Joe, can you test this?
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 8f908f077935..f0d7119585dc 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -9666,6 +9666,8 @@ static inline void
> perf_event_free_bpf_handler(struct perf_event *event)
> * Generic event overflow handling, sampling.
> */
>
> +static bool perf_event_is_tracing(struct perf_event *event);
> +
> static int __perf_event_overflow(struct perf_event *event,
> int throttle, struct perf_sample_data *data,
> struct pt_regs *regs)
> @@ -9682,7 +9684,9 @@ static int __perf_event_overflow(struct perf_event *event,
>
> ret = __perf_event_account_interrupt(event, throttle);
>
> - if (event->prog && !bpf_overflow_handler(event, data, regs))
> + if (event->prog &&
> + !perf_event_is_tracing(event) &&
> + !bpf_overflow_handler(event, data, regs))
> return ret;
>
> /*
> @@ -10612,6 +10616,11 @@ void perf_event_free_bpf_prog(struct perf_event *event)
>
> #else
>
> +static inline bool perf_event_is_tracing(struct perf_event *event)
> +{
> + return false;
> +}
> +
> static inline void perf_tp_register(void)
> {
> }
>
Thank you!
I've applied the above patch on top of commit 338a93cf4a18 ("net:
mctp-i2c: invalidate flows immediately on TX errors"), which seems
to be latest on net-next/main.
I built and booted that kernel on my mlx5 test machine and re-ran
the same bpftrace invocation:
bpftrace -e 'tracepoint:napi:napi_poll { @[args->work] = count(); }'
I then scp-ed a 100MiB zero filled file to the target 48 times back
to back (e.g. scp zeroes target:~/ && scp zeroes target:~/ && ... )
and the bpftrace output seems reasonable; there are no negative
numbers and the values output *look* reasonable to me.
The patch seems reasonable, as well, with the major caveat that I've
only hacked on drivers and networking stuff and know absolutely
nothing about bpf internals.
All that said:
Tested-by: Joe Damato <jdamato@...tly.com>
Powered by blists - more mailing lists