A first look at Rust in the 6.1 kernel

> or else the borrow checker has not done its job correctly.

(Or, more prosaically, someone has violated the safety rules in an unsafe block or in native C code or something along those lines. "Unsafe" doesn't mean "I can do whatever I want," it means "the compiler isn't checking everything here, so I have to be careful.")

In particular, although core::ops::Drop::drop(&mut self) *looks* like a pretty ordinary safe trait function it is actually magic the compiler cares about - Rust calls such magic a "langitem" as in "language item". If you made your own my::Drop trait with a drop(&mut self) function anybody can implement that on their types if they want, and anybody can call that drop() method on values of those types, yet it won't de-allocate anything, won't happen automatically, it just has a misleading name, like the artwork "An Oak Tree". But the langitem deliberately cannot be called by people explicitly (that's a compile error), and it will get called automatically by the language when items of that type are about to be destroyed.

So logically this code happens because the kernel is destroying this value, if Linux actually keeps the value alive that's a kernel bug, it's logically OK if the kernel can't or won't clean up the RAM used for the module, but it definitely can't expect that the Vec still works for example since Rust will have recursively called Drop::drop on the Vec inside this type (and so on) and the Vec is presumably delegating to some kernel allocator to get suitable blocks of memory which it will then give back when destroyed.