Changes to `aya-log-ebpf` made it impossible(?) to define our own `Error` type

[thomaseizinger]

We currently do the following: https://github.com/firezone/firezone/blob/1581042d10054c461d0986caeefdca4f19d1ae09/rust/relay/ebpf-turn-router/src/try_handle_turn/error.rs#L28-L61

I wanted to update aya today and noticed that this trait got removed. After reading through the new source code, I noticed that there is now Argument but that trait is sealed.

Is there a way how I can define my own error type and log that using aya?

[tamird]

Sounds like you can have a trait method that returns a &'static str and log that in the usual way?

[thomaseizinger]

Sounds like you can have a trait method that returns a &'static str and log that in the usual way?

That is what I am doing now yeah. It doesn't quite work as smoothly unfortunately because the verifier complains about stack size and the size of the return value. If I drop the return code from xdp_adjust_tail it works. That is a bit of a shame as we've found that quite useful during debugging.

I think it does highlight a bigger issue still: It would be nice to be able to just implement fmt::Display and use that the same way it works in userspace. I don't know the details of aya-log-ebpf though so I am not sure that is possible.

[tamird]

I'm surprised to hear stack size is a problem. It's not possible to make use of Display impls unfortunately because aya-log-ebpf needs more information than that trait exposes.

[thomaseizinger]

I'm surprised to hear stack size is a problem. It's not possible to make use of Display impls unfortunately because aya-log-ebpf needs more information than that trait exposes.

I was surprised too. It is almost as if it didn't like the longer strings. I tried to naively inline these into the bigger match and return a &'static str but that triggered the verifier. Removing the inner match and simply dropping the handling of the return code appeared to have fixed it.

[tamird]

My best guess is you were already close to the stack limit and the string headers pushed you over the limit. It's also possible the logging implementation uses more stack than it used to. It would be good to measure and optimize this. cc @ajwerner @vadorovsky in case y'all have ideas.

[thomaseizinger]

I don't think we are close to the stack size limit? Do you know of tools that I could analyze that with?

[tamird]

https://chatgpt.com/s/t_68d24720864081918ede0214fc384353

[thomaseizinger]

Turns out we are actually pretty close, 480 bytes.