Re: [TECH TOPIC] Rust for Linux

[Greg KH <greg@kroah.com>]

On Thu, Jul 08, 2021 at 09:38:01AM -0700, Andy Lutomirski wrote:
> On Thu, Jul 8, 2021 at 7:58 AM Greg KH <greg@kroah.com> wrote:
> >
> > On Thu, Jul 08, 2021 at 03:55:31PM +0200, Miguel Ojeda wrote:
> > >     On Thu, Jul 8, 2021 at 8:11 AM Greg KH <greg@kroah.com> wrote:
> > > >
> > > > Thanks for the detailed explainations, it seems rust can "get away" with
> > > > some things with regards to reference counts that the kernel can not.
> > > > Userspace has it easy, but note that now that rust is not in userspace,
> > > > dealing with multiple cpus/threads is going to be interesting for the
> > > > language.
> > >
> > > Regarding parallelism, userspace deals with the same problems, so I do
> > > not see fundamental issues coming up there. The language was designed
> > > with parallelism in mind and is a definite improvement over both C and
> > > C++ in that regard.
> >
> > Ok, great, then how would you handle the kref issue where you need an
> > external lock to properly handle the reference counting logic in Rust?
> > Why is C so "bad" here that we require a lock but Rust would not?
> 
> Can you point at a specific example in the kernel tree?

Easy ones to see are any callers of kref_put_mutex() and
kref_put_lock().  There's also the klist.h usage that removes the need
for using those calls as there is a different lock involved, and other
"bigger" locks that the driver core holds when dealing with kobjects so
it "knows" it can just call kref_put().

> The
> lock-and-then-put model is, at the very least, unusual, and the kref
> docs talk about it like it's common and self-explanatory as to when
> it's needed.  I have personally never encountered a need for this, and
> I'd like to know exactly what type of use case you're thinking of.

Look at the above examples for details, I can't remember them all at the
moment.  Last time I looked into it, it took me and two graduate
students with a whiteboard an hour to verify if we needed the lock or
not.  I was wrong and it turns out we did :)

It mostly is needed when you need to return a pointer to a reference
counted object from some sort of lookup as it was stored in a list or
something.  Which for kernel objects, is quite common.

thanks,

greg k-h