Re: [PATCH bpf-next v4 00/20] bpf: Run exception cleanup landing pads when bpf_throw() unwinds

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

On Wed Sep 23, 2026 at 10:00 PM UTC, Eduard Zingerman wrote:
> On Wed, 2026-09-23 at 21:34 +0000, Alexei Starovoitov wrote:
>
> ...
>
>> Sorry, all I hear is a knee jerk reaction to a lot of slop.
>> yes. a lot of it is not needed, but invoke approach is no go.
>> As I said couple time [ip_start, ip_end] is not a single call insn.
>> libbpf patches do a bunch of unnecessary copy paste,
>> but that's because we didn't do insn_array support cleanly.
>> From libbpf pov bpf_cleanup section shouldn't be any different as
>> "one more section with pointers to instructions".
>> 
>> Sorry, we're not doing new 16-byte insn. We can chat about it
>> during the meeting, but I feel it will be a waste of time.
>
> If you simply don't like 16-byte instructions, then yes,
> nothing to talk about.
>
>> New insn doesn't reduce amount of slop.
>
> It literally and demonstrably does, I listed the actions that are not
> necessary with this encoding in the previous email. No matter which
> llm you use more actions needed == more code.
>
>> Ed's example 1k vs 2k is a counter example.
>> This is just one llm vs another. Both sucked and both slop.
>> Just different amount of it.
>
> Fwiw, it was not a one-shot. The verifier part is curated.
> The jit part is whatever codex decided to do with the original series.
> I stand by the complexity reduction claim.

I don't measure complexity in number of lines.
There is also llvm part that you're forgetting about
and dragging that new insn all the way.