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

[Alexei Starovoitov]

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.