Re: C aggregate passing (Rust kernel policy)

[Kent Overstreet]

On Wed, Feb 26, 2025 at 06:11:53PM +0100, Miguel Ojeda wrote:
> On Wed, Feb 26, 2025 at 3:26 PM James Bottomley
> <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Wed, 2025-02-26 at 14:53 +0100, Miguel Ojeda wrote:
> > > On Wed, Feb 26, 2025 at 2:03 PM Ventura Jack
> > > <venturajack85@xxxxxxxxx> wrote:
> > [...]
> > > > Exception/unwind safety may be another subject that increases
> > > > the difficulty of writing unsafe Rust.
> > >
> > > Note that Rust panics in the kernel do not unwind.
> >
> > I presume someone is working on this, right?  While rust isn't
> > pervasive enough yet for this to cause a problem, dumping a backtrace
> > is one of the key things we need to diagnose how something went wrong,
> > particularly for user bug reports where they can't seem to bisect.
> 
> Ventura Jack was talking about "exception safety", referring to the
> complexity of having to take into account additional execution exit
> paths that run destructors in the middle of doing something else and
> the possibility of those exceptions getting caught. This does affect
> Rust when built with the unwinding "panic mode", similar to C++.
> 
> In the kernel, we build Rust in its aborting "panic mode", which
> simplifies reasoning about it, because destructors do not run and you
> cannot catch exceptions (you could still cause mischief, though,
> because it does not necessarily kill the kernel entirely, since it
> maps to `BUG()` currently).
> 
> In other words, Ventura Jack and my message were not referring to
> walking the frames for backtraces.
> 
> I hope that clarifies.

However, if Rust in the kernel does get full unwinding, that opens up
interesting possibilities - Rust with "no unsafe, whitelisted list of
dependencies" could potentially replace BPF with something _much_ more
ergonomic and practical.