bpf: fix error handling for invoke_tailcall_if()

[julianwiedmann]

invoke_tailcall_if() either inlines the target function, or calls it via
tail-call. In the inline variant, the return causes us to skip over any
subsequent error handling (eg drop notification) in the caller.

Rework the macro so that it properly assigns the ret value.

Also fix up one user that didn't handle returned errors.

[julianwiedmann]

/test

[julianwiedmann]

Bit of a funky fail in the runtime tests (#26150), re-running.

[julianwiedmann]

/test-runtime

[julianwiedmann]

/test

[julianwiedmann]

Picked up @aspsk's suggestion on how to build the macro, rebased. Also fixed up one user of the macro.

[nbusseneau]

@julianwiedmann Backporting the changes in this PR to v1.13 yields conflicts as they depend on changes made in #23831, which was not backported to v1.13. I'm not competent enough in BPF to fully understand what's going on, can you double-check if it's OK to backport #23831 to v1.13?

[julianwiedmann]

@julianwiedmann Backporting the changes in this PR to v1.13 yields conflicts as they depend on changes made in #23831, which was not backported to v1.13. I'm not competent enough in BPF to fully understand what's going on, can you double-check if it's OK to backport #23831 to v1.13?

Yep, v1.13 has less occurences of invoke_tailcall_if(). It's fine to ignore the non-existent ones.

But I see @tklauser has already decided how to progress, I'll queue up a backport PR then 😁 .

[tklauser]

Was just about to write a reply 😄 Also happy to incorporate the patch in a 1.13 backport this week if it's reasonably easy. But I guess @julianwiedmann will have more context doing it.