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

[Florent Revest]

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@xxxxxxxxx> 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.

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.