On Thu, Jul 13, 2023 at 08:02:22AM +0530, Kumar Kartikeya Dwivedi wrote: > This series implements the _first_ part of the runtime and verifier > support needed to enable BPF exceptions. Exceptions thrown from programs > are processed as an immediate exit from the program, which unwinds all > the active stack frames until the main stack frame, and returns to the > BPF program's caller. The ability to perform this unwinding safely > allows the program to test conditions that are always true at runtime > but which the verifier has no visibility into. > > Thus, it also reduces verification effort by safely terminating > redundant paths that can be taken within a program. > > The patches to perform runtime resource cleanup during the > frame-by-frame unwinding will be posted as a follow-up to this set. > > It must be noted that exceptions are not an error handling mechanism for > unlikely runtime conditions, but a way to safely terminate the execution > of a program in presence of conditions that should never occur at > runtime. They are meant to serve higher-level primitives such as program > assertions. Sure, that makes sense. > > As such, a program can only install an exception handler once for the > lifetime of a BPF program, and this handler cannot be changed at > runtime. The purpose of the handler is to simply interpret the cookie > value supplied by the bpf_throw call, and execute user-defined logic > corresponding to it. The primary purpose of allowing a handler is to > control the return value of the program. The default handler returns 0 > when from the program when an exception is thrown. > > Fixing the handler for the lifetime of the program eliminates tricky and > expensive handling in case of runtime changes of the handler callback > when programs begin to nest, where it becomes more complex to save and > restore the active handler at runtime. > > The following kfuncs are introduced: > > // Throw a BPF exception, terminating the execution of the program. > // > // @cookie: The cookie that is passed to the exception callback. Without > // an exception callback set by the user, the programs returns > // 0 when an exception is thrown. > void bpf_throw(u64 cookie); If developers are only supposed to use higher level primitives, then why expose a kfunc for it? The above description makes it sound like this should be an implementation detail. [...] Thanks, Daniel
