Re: [PATCH bpf v2 1/2] bpf: Skip detached progs in trampoline images that are still in use

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Wed Sep 16, 2026 at 7:52 AM UTC, Florent Revest wrote:
> On Wed Sep 16, 2026 at 5:29 AM UTC, Alexei Starovoitov wrote:
> > On Tue, Sep 15, 2026 at 11:39 AM Florent Revest
> > <florent.revest@linux.dev> wrote:
> > >
> > >
> > > Ah yeah, I tried to address that in the cover letter. Basically, if we patch
> > > all the nops, tasks running in the old image could skip some progs that are
> > > still attached. For fexit, that's already what happens with ip_after_call but
> > > for fmod_ret it would be new and this would cause for example an LSM prog's
> > > verdict to get skipped when another prog gets attached to the same hook. That's
> > > why I thought that patching only the detached prog's nop would be better and
> > > needed these extra pointers. But it's a bit of an edge case and I don't have a
> > > strong opinion on it.
> >
> > Hmm. Not sure I agree with your reasoning.
> > fmod_ret progs are called _before_ orig_call.
> > So fentry+fmod_ret are in the same category.
> > Adding/removing a prog to the trampoline causes regeneration
> > of the trampoline.
> > So cpus may execute different numbers of progs already.
> > The race is inevitable.
> > With 'patch all nops in old tramp' approach the only
> > additional race is some of the fentry/fmod_ret progs
> > will get skipped in old tramp.
> >
> > If the concern of a tiny window where old tramp is started
> > to be destroyed, then fentry prog is called and we patched
> > another fentry, but tramp will continue and execute orig_call,
> > then, yes, I see the issue, but it's a lot more subtle.
> > If I understood the concern correctly then let's add
> > another 'jump over the call' nop in addition to
> > 'patch nops in front of all progs' and
> > let's patch 'jump over the call' _first_.
> > This way fentry/fmod_ret progs can never miss
> > execution of orig_call. They can be invoked "unncessarily".
> > They may execute though orig_call will not fire.
> > but that's an acceptable race. Better than not executing
> > fmod_ret while letting orig_call to go through.
> >
> > This is still simpler implementation than link-list all all extra book keeping.
>
> My concern wasn't orig_call running but rather progs that are still attached
> getting skipped. Say, fentry progs A and B are attached to a function and a
> task is sleeping in A. Someone attaches C, the old image gets all its nops
> patched, the task wakes up and skips B even though B was never detached.

so ? the orig call will also be patched and will be skipped.
So no observable difference from B pov.

> But it's a narrow window and it needs an attach/detach on that function to race
> with, so if you're OK with that behavior I'll respin v3 with your simpler
> version.

I don't think above scenario is anything to be concerned about.
So yeah. let's go with simpler solution.