On Tue, 9 May 2023 08:24:29 -0700 Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > On Mon, May 8, 2023 at 9:38 AM Beau Belgrave <beaub@xxxxxxxxxxxxxxxxxxx> wrote: > > > > Programs that utilize user_events today only get the event payloads via > > perf or ftrace when writing event data. When BPF programs are attached > > to tracepoints created by user_events the BPF programs do not get run > > even though the attach succeeds. This causes confusion by the users of > > the programs, as they expect the data to be available via BPF programs > > they write. We have several projects that have hit this and requested > > BPF program support when publishing data via user_events from their > > user processes in production. > > > > Swap out perf_trace_buf_submit() for perf_trace_run_bpf_submit() to > > ensure BPF programs that are attached are run in addition to writing to > > perf or ftrace buffers. This requires no changes to the BPF infrastructure > > and only utilizes the GPL exported function that modules and other > > components may use for the same purpose. This keeps user_events consistent > > with how other kernel, modules, and probes expose tracepoint data to allow > > attachment of a BPF program. > > Sorry, I have to keep my Nack here. > > I see no practical use case for bpf progs to be connected to user events. That's not a technical reason. Obviously they have a use case. This is only connecting to BPF through the API. It makes no changes to BPF itself, so I'm not sure your NACK has jurisdiction here. Their alternative is to to do it with an external module as the only connections to BPF it uses is via an EXPORT_SYMBOL_GPL() function! Again, what is your technical reason for nacking this? It's like me nacking a user of ftrace because I don't see a use case for it. That's not a valid reason to issue a nack. > > There must be a different way to solve your user needs > and this is not bpf. Why not use BPF? -- Steve
