A first look at Rust in the 6.1 kernel [LWN.net]

A first look at Rust in the 6.1 kernel

Posted Oct 14, 2022 16:58 UTC (Fri) by NYKevin (subscriber, #129325)
In reply to: A first look at Rust in the 6.1 kernel by rsidd
Parent article: A first look at Rust in the 6.1 kernel

In general (not specific to the kernel), that is never supposed to happen. By the time drop() gets called, your object should not be owned by anyone and nobody should have any outstanding references to it, or else the borrow checker has not done its job correctly.

A first look at Rust in the 6.1 kernel

Posted Oct 14, 2022 23:41 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

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.