Exceptions in BPF

Posted Jul 21, 2023 16:25 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
Parent article: Exceptions in BPF

Guys, really? You are now adding freaking exceptions.

This is not just "feature creep", it's a "feature runaway train at 100mph".

Exceptions in BPF

Posted Jul 21, 2023 16:55 UTC (Fri) by adobriyan (subscriber, #30858) [Link]

Superficially kuint devs did exceptions first:

struct kunit_try_catch {
/* private: internal use only. */
struct kunit *test;
struct completion *try_completion;
int try_result;
kunit_try_catch_func_t try;
kunit_try_catch_func_t catch;
void *context;
};

Exceptions in BPF

Posted Jul 21, 2023 20:00 UTC (Fri) by Smon (guest, #104795) [Link] (2 responses)

Couldn't a compiler simulate this already with existing functionality?

Exceptions in BPF

Posted Jul 22, 2023 16:00 UTC (Sat) by NYKevin (subscriber, #129325) [Link] (1 responses)

Maybe. Sort of. With a lot of effort.

The problem is that you need to return all the way up the stack, and therefore you need to return some kind of "we're bailing out" status code to indicate the problem to the caller. But you probably already have return values at many of those call sites, so now you need to transform those return values in some way, probably into an option type or tagged union (or some equivalent). In principle that should be possible, but I don't know if BPF makes it straightforward or performant.

Exceptions in BPF

Posted Jul 24, 2023 4:13 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

One of the bragging points of BPF was "but it always returns a value!", and that's why it's apparently better than WASM.

With the addition of exceptions, this guarantee is lost.

Not that it mattered either way in practice, but still. BPF is now just adding features without even considering their impact on the overall BPF model.

Exceptions in BPF

Posted Jul 22, 2023 8:42 UTC (Sat) by jezuch (subscriber, #52988) [Link] (6 responses)

Maybe this thould be renamed as "panic", because it's doing the same thing as panic in Rust. These are no generic exceptions.

Exceptions in BPF

Posted Jul 22, 2023 9:15 UTC (Sat) by softball (guest, #160655) [Link] (3 responses)

A core difference is: BPF looks to treat throws as success-by-default (rc 0), Rust panics are failure-by-default. Rust panics have to be caught explicitly. My experience with Rust is limited so far, but catching panics seems rare and unidiomatic: there's already featureful error handling available (Result type), so any panics are usually serious enough to not be handlable.

Exceptions in BPF

Posted Jul 23, 2023 7:35 UTC (Sun) by xi0n (subscriber, #138144) [Link] (2 responses)

Panics in idiomatic Rust are only caught to prevent them from crossing an FFI boundary, i.e. escaping a Rust callback that’s been called from C. Otherwise, programs can set a global panic handler if the standard one is inadequate, but that is only really used for embedded and other no_std environments.

This saying, the mechanism proposed here is so close to Rust panics (and Go panics) that NOT calling it such will only lead to confusion, esp. when “exception” is such an overloaded term already.

Exceptions in BPF

Posted Jul 25, 2023 6:59 UTC (Tue) by taladar (subscriber, #68407) [Link]

Setting a custom panic handler is also frequently used in situations where the panic should be logged before exiting.

Exceptions in BPF

Posted Nov 5, 2023 13:03 UTC (Sun) by ibukanov (subscriber, #3942) [Link]

Go panics are exactly the exceptions. They can be caught at arbitrary points and can pass arbitrary values across the stack.

Exceptions in BPF

Posted Jul 22, 2023 12:07 UTC (Sat) by dezgeg (subscriber, #92243) [Link] (1 responses)

Sounds it would be too confusing when 'Kernel panic' is already a thing

Exceptions in BPF

Posted Jul 23, 2023 18:48 UTC (Sun) by rqosa (subscriber, #24136) [Link]

Maybe naming it "error" (or something like that) would be a reasonable choice that isn't too similar to those 2 other terms?

(Java uses the word "error" in a similar sense in java.lang.Error's name — i.e. for "serious problems that a reasonable application should not try to catch".)