Exceptions in BPF

Posted Jul 22, 2023 4:24 UTC (Sat) by wahern (subscriber, #37304)
In reply to: Exceptions in BPF by walters
Parent article: Exceptions in BPF

> If you’re talking about Rust code using std certainty there can be a lot of implicit OOM panics. But kernel Rust doesn’t use std.

True, kernel Rust has its own standard library, but most of it seems to be littered with '#[cfg(not(no_global_oom_handling))]' just like the userspace std library.

Exceptions in BPF

Posted Jul 22, 2023 18:28 UTC (Sat) by walters (subscriber, #7396) [Link]

> True, kernel Rust has its own standard library, but most of it seems to be littered with '#[cfg(not(no_global_oom_handling))]' just like the userspace std library.

(We're now a bit past my relatively superficial knowledge of Linux kernel Rust but...)

I'm pretty sure that's because they don't want a long term fork of alloc.rs and vec.rs etc. The upstream Rust project has this config option I'm pretty sure *precisely* to help enable usage of the upstream battle-tested collections while disabling the APIs that will implicitly panic on OOM.

And the Linux build system does pass "--cfg no_global_oom_handling". And the example Rust code does use try_push() not push(), etc.

Or to say this simply: kernel Rust does not have implicit panics on OOM.

What would certainly be interesting to try to evaluate is how many possible panics there are in any nontrivial kernel Rust code. The classic example is somevec[offset]. I'd expect the number is greater than zero. But are there "a lot"? Are there enough where it *actually* feels like "panic if any of a large number of things goes wrong" is true? I'm doubtful.