Re: [TECH TOPIC] Rust for Linux

Laurent Pinchart
2021-07-06T22:00:50Z

On Tue, Jul 06, 2021 at 10:36:14PM +0200, Linus Walleij wrote:
> On Tue, Jul 6, 2021 at 10:00 PM Roland Dreier wrote:
>
> > One area I see where Rust could make a big improvement for drivers is
> > in using RAII for error paths. Drivers often have a lot of code like
> >
> > if (something())
> > return err;
> >
> > if (something_else())
> > goto undo_something;
> >
> > if (a_third_thing())
> > goto undo_two_things;
> >
> > and so on, which is difficult to get right in the first place and even
> > harder to keep correct in the face of changes.
>
> Yes.
>
> > "devres" / devm_xxx was an attempt to deal with this in C, but it only
> > solves some cases of this and has not received a lot of adoption (we
> > can argue about the reasons).
>
> Really? From my point of view that is adopted all over the map.
> I add new users all the time and use it as much as I can when
> writing new drivers.
>
> $ git grep devm_ | wc -l
> 26112
>
> Dmitry in the input subsystem even insist to use it for e.g. powering
> down and disabling regulators on remove(), like recently in
> drivers/input/touchscreen/cy8ctma140.c
>
> /* Called from the registered devm action */
> static void cy8ctma140_power_off_action(void *d)
> {
> struct cy8ctma140 *ts = d;
>
> cy8ctma140_power_down(ts);
> }
> (...)
> error = devm_add_action_or_reset(dev, cy8ctma140_power_off_action, ts);
> if (error) {
> dev_err(dev, "failed to install power off handler\n");
> return error;
> }
>
> I think it's a formidable success, people just need to learn to do it more.

devres is interesting and has good use cases, but the devm_k*alloc() are
a nightmare. They're used through drivers without any consideration of
life time management of the allocated memory, to allocate data
structures that can be accessed in userspace-controlled code paths.
Open a device node, keep it open, unplug the device, close the device
node, and in many cases you'll find that the kernel can crash :-( When
the first line of the probe function of a driver that exposes a chardev
if a devm_kzalloc(), it's usually a sign that something is wrong.

I wonder if we could also benefit from the gcc cleanup attribute
(https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-cleanup-variable-attribute).
I don't know if it's supported by the other compilers we care about
though.

> But if an easier path to learn better behaviours is to shuffle the whole
> chessboard and replace it with drivers written in Rust, I don't know?
> Maybe?

--
Regards,

Laurent Pinchart