From: Greg KH <greg@kroah.com>
To: Wedson Almeida Filho <wedsonaf@google.com>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Julia Lawall <julia.lawall@inria.fr>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Linus Walleij <linus.walleij@linaro.org>,
Roland Dreier <roland@kernel.org>,
ksummit@lists.linux.dev
Subject: Re: [TECH TOPIC] Rust for Linux
Date: Wed, 7 Jul 2021 19:20:44 +0200 [thread overview]
Message-ID: <YOXibDV8mHT1e6ec@kroah.com> (raw)
In-Reply-To: <YOXd9WoafgBr1Nkv@google.com>
On Wed, Jul 07, 2021 at 06:01:41PM +0100, Wedson Almeida Filho wrote:
> On Wed, Jul 07, 2021 at 05:44:41PM +0200, Greg KH wrote:
> > On Wed, Jul 07, 2021 at 05:15:01PM +0200, Miguel Ojeda wrote:
> > > For instance, we have a `Ref` type that is similar to `Arc` but reuses
> > > the `refcount_t` from C and introduces saturation instead of aborting
> > > [3]
> > >
> > > [3] https://github.com/Rust-for-Linux/linux/blob/rust/rust/kernel/sync/arc.rs
> >
> > This is interesting code in that I think you are missing the part where
> > you still need a lock on the object to prevent one thread from grabbing
> > a reference while another one is dropping the last reference. Or am I
> > missing something?
>
> You are missing something :)
>
> > The code here:
> >
> > fn drop(&mut self) {
> > // SAFETY: By the type invariant, there is necessarily a reference to the object. We cannot
> > // touch `refcount` after it's decremented to a non-zero value because another thread/CPU
> > // may concurrently decrement it to zero and free it. It is ok to have a raw pointer to
> > // freed/invalid memory as long as it is never dereferenced.
> > let refcount = unsafe { self.ptr.as_ref() }.refcount.get();
> >
> > // INVARIANT: If the refcount reaches zero, there are no other instances of `Ref`, and
> > // this instance is being dropped, so the broken invariant is not observable.
> > // SAFETY: Also by the type invariant, we are allowed to decrement the refcount.
> > let is_zero = unsafe { rust_helper_refcount_dec_and_test(refcount) };
> > if is_zero {
> > // The count reached zero, we must free the memory.
> > //
> > // SAFETY: The pointer was initialised from the result of `Box::leak`.
> > unsafe { Box::from_raw(self.ptr.as_ptr()) };
> > }
> > }
> >
> > Has a lot of interesting comments, and maybe just because I know nothing
> > about Rust, but why on the first line of the comment is there always
> > guaranteed a reference to the object at this point in time?
>
> It's an invariant of the `Ref<T>` type: if a `Ref<T>` exists, there necessarily
> is a non-zero reference count. You cannot have a `Ref<T>` with a zero refcount.
What enforces that? Where is the lock on the "back end" for `Ref<T>`
that one CPU from grabbing a reference at the same time the "last"
reference is dropped on a different CPU?
Does Rust provide "architecture-specific" locks like this somehow that
are "built in"? If so, what happens when we need to fix those locks?
Does that get fixed in the compiler, not the kernel code?
> `drop` is called when a `Ref<T>` is about to be destroyed. Since it is about to
> be destroyed, it still exists, therefore the ref-count is necessarily non-zero.
"about to", yes, but what keeps someone else from grabbing it?
> > And yes
> > it's ok to have a pointer to memory that is not dereferenced, but is
> > that what is happening here?
>
> `refcount` is a raw pointer. When it is declared and initialised, it points to
> valid memory. The comment is saying that we should be careful with the case
> where another thread ends up freeing the object (after this thread has
> decremented its share of the count); and that we're not violating any Rust
> aliasing rules by having this raw pointer (as long as we don't dereference it).
>
> > I feel you are trying to duplicate the logic of a "struct kref" here,
>
> `struct kref` would give us the ability to specify a `release` function when
> calling `refcount_dec_and_test`, but we don't need this round-trip to C code
> because we know at compile-time what the `release` function is: it's the `drop`
> implementation for the wrapped type (`T` in `Ref<T>`).
That's not what I meant by bringing up a kref. I was trying to ask
where the "real" lock here is. It has to be somewhere...
> > and that requires a lock to work properly. Where is the lock here?
>
> We don't need a lock. Once the refcount reaches zero, we know that nothing else
> has pointers to the memory block; the lifetime rules guarantee that if there is
> a reference to a `Ref<T>`, then it cannot outlive the `Ref<T>` itself.
Even with multiple CPUs? What enforces these lifetime rules?
thanks,
greg k-h
next prev parent reply other threads:[~2021-07-07 17:20 UTC|newest]
Thread overview: 201+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-25 22:09 [TECH TOPIC] Rust for Linux Miguel Ojeda
2021-07-05 23:51 ` Linus Walleij
2021-07-06 4:30 ` Leon Romanovsky
2021-07-06 9:55 ` Linus Walleij
2021-07-06 10:16 ` Geert Uytterhoeven
2021-07-06 17:59 ` Linus Walleij
2021-07-06 18:36 ` Miguel Ojeda
2021-07-06 19:12 ` Linus Walleij
2021-07-06 21:32 ` Miguel Ojeda
2021-07-07 14:10 ` Arnd Bergmann
2021-07-07 15:28 ` Miguel Ojeda
2021-07-07 15:50 ` Andrew Lunn
2021-07-07 16:34 ` Miguel Ojeda
2021-07-07 16:55 ` Arnd Bergmann
2021-07-07 17:54 ` Miguel Ojeda
2021-07-06 10:22 ` Leon Romanovsky
2021-07-06 14:30 ` Miguel Ojeda
2021-07-06 14:32 ` Miguel Ojeda
2021-07-06 15:03 ` Sasha Levin
2021-07-06 15:33 ` Miguel Ojeda
2021-07-06 15:42 ` Laurent Pinchart
2021-07-06 16:09 ` Mike Rapoport
2021-07-06 18:29 ` Miguel Ojeda
2021-07-06 18:38 ` Laurent Pinchart
2021-07-06 19:45 ` Steven Rostedt
2021-07-06 19:59 ` Miguel Ojeda
2021-07-06 18:53 ` Sasha Levin
2021-07-06 21:50 ` Miguel Ojeda
2021-07-07 4:57 ` Leon Romanovsky
2021-07-07 13:39 ` Alexandre Belloni
2021-07-07 13:50 ` Miguel Ojeda
2021-07-06 18:26 ` Linus Walleij
2021-07-06 19:11 ` Miguel Ojeda
2021-07-06 19:13 ` Johannes Berg
2021-07-06 19:43 ` Miguel Ojeda
2021-07-06 10:20 ` James Bottomley
2021-07-06 14:55 ` Miguel Ojeda
2021-07-06 15:01 ` Sasha Levin
2021-07-06 15:36 ` Miguel Ojeda
2021-07-09 10:02 ` Marco Elver
2021-07-09 16:02 ` Miguel Ojeda
2021-07-06 18:09 ` Linus Walleij
2021-07-06 14:24 ` Miguel Ojeda
2021-07-06 14:33 ` Laurent Pinchart
2021-07-06 14:56 ` Leon Romanovsky
2021-07-06 15:29 ` Miguel Ojeda
2021-07-07 4:38 ` Leon Romanovsky
2021-07-06 20:00 ` Roland Dreier
2021-07-06 20:36 ` Linus Walleij
2021-07-06 22:00 ` Laurent Pinchart
2021-07-07 7:27 ` Julia Lawall
2021-07-07 7:45 ` Greg KH
2021-07-07 7:52 ` James Bottomley
2021-07-07 13:49 ` Miguel Ojeda
2021-07-07 14:08 ` James Bottomley
2021-07-07 15:15 ` Miguel Ojeda
2021-07-07 15:44 ` Greg KH
2021-07-07 17:01 ` Wedson Almeida Filho
2021-07-07 17:20 ` Greg KH [this message]
2021-07-07 19:19 ` Wedson Almeida Filho
2021-07-07 20:38 ` Jan Kara
2021-07-07 23:09 ` Wedson Almeida Filho
2021-07-08 6:11 ` Greg KH
2021-07-08 13:36 ` Wedson Almeida Filho
2021-07-08 18:51 ` Greg KH
2021-07-08 19:31 ` Andy Lutomirski
2021-07-08 19:35 ` Geert Uytterhoeven
2021-07-08 21:56 ` Andy Lutomirski
2021-07-08 19:49 ` Linus Walleij
2021-07-08 20:34 ` Miguel Ojeda
2021-07-08 22:13 ` Linus Walleij
2021-07-09 7:24 ` Geert Uytterhoeven
2021-07-19 12:24 ` Wedson Almeida Filho
2021-07-19 13:15 ` Wedson Almeida Filho
2021-07-19 14:02 ` Arnd Bergmann
2021-07-19 14:13 ` Linus Walleij
2021-07-19 21:32 ` Arnd Bergmann
2021-07-19 21:33 ` Arnd Bergmann
2021-07-20 1:46 ` Miguel Ojeda
2021-07-20 6:43 ` Johannes Berg
2021-07-19 14:43 ` Geert Uytterhoeven
2021-07-19 18:24 ` Miguel Ojeda
2021-07-19 18:47 ` Steven Rostedt
2021-07-19 14:54 ` Miguel Ojeda
2021-07-19 17:32 ` Wedson Almeida Filho
2021-07-19 21:31 ` Arnd Bergmann
2021-07-19 17:37 ` Miguel Ojeda
2021-07-19 16:02 ` Vegard Nossum
2021-07-19 17:45 ` Miguel Ojeda
2021-07-19 17:54 ` Miguel Ojeda
2021-07-19 18:06 ` Wedson Almeida Filho
2021-07-19 19:37 ` Laurent Pinchart
2021-07-19 21:09 ` Wedson Almeida Filho
2021-07-20 23:54 ` Laurent Pinchart
2021-07-21 1:33 ` Andy Lutomirski
2021-07-21 1:42 ` Laurent Pinchart
2021-07-21 13:54 ` Linus Walleij
2021-07-21 14:13 ` Wedson Almeida Filho
2021-07-21 14:19 ` Linus Walleij
2021-07-22 11:33 ` Wedson Almeida Filho
2021-07-23 0:45 ` Linus Walleij
2021-07-21 4:39 ` Wedson Almeida Filho
2021-07-23 1:04 ` Laurent Pinchart
2021-07-21 4:23 ` Wedson Almeida Filho
2021-07-23 1:13 ` Laurent Pinchart
2021-07-19 22:57 ` Alexandre Belloni
2021-07-20 7:15 ` Miguel Ojeda
2021-07-20 9:39 ` Alexandre Belloni
2021-07-20 12:10 ` Miguel Ojeda
2021-07-19 13:53 ` Linus Walleij
2021-07-19 14:42 ` Wedson Almeida Filho
2021-07-19 22:16 ` Linus Walleij
2021-07-20 1:20 ` Wedson Almeida Filho
2021-07-20 13:21 ` Andrew Lunn
2021-07-20 13:38 ` Miguel Ojeda
2021-07-20 14:04 ` Andrew Lunn
2021-07-20 13:55 ` Greg KH
2021-07-20 1:21 ` Miguel Ojeda
2021-07-20 16:00 ` Mark Brown
2021-07-20 22:42 ` Linus Walleij
2021-07-19 14:43 ` Miguel Ojeda
2021-07-19 15:15 ` Andrew Lunn
2021-07-19 15:43 ` Miguel Ojeda
2021-07-09 7:03 ` Viresh Kumar
2021-07-09 17:06 ` Mark Brown
2021-07-09 17:43 ` Miguel Ojeda
2021-07-10 9:53 ` Jonathan Cameron
2021-07-10 20:09 ` Kees Cook
2021-07-08 13:55 ` Miguel Ojeda
2021-07-08 14:58 ` Greg KH
2021-07-08 15:02 ` Mark Brown
2021-07-08 16:38 ` Andy Lutomirski
2021-07-08 18:01 ` Greg KH
2021-07-08 18:00 ` Miguel Ojeda
2021-07-08 18:44 ` Greg KH
2021-07-08 23:09 ` Miguel Ojeda
2021-07-08 7:20 ` Geert Uytterhoeven
2021-07-08 13:41 ` Wedson Almeida Filho
2021-07-08 13:43 ` Geert Uytterhoeven
2021-07-08 13:54 ` Wedson Almeida Filho
2021-07-08 14:16 ` Geert Uytterhoeven
2021-07-08 14:24 ` Wedson Almeida Filho
2021-07-09 7:04 ` Jerome Glisse
2021-07-08 14:04 ` Miguel Ojeda
2021-07-08 14:18 ` Geert Uytterhoeven
2021-07-08 14:28 ` Miguel Ojeda
2021-07-08 14:33 ` Geert Uytterhoeven
2021-07-08 14:35 ` Miguel Ojeda
2021-07-09 11:55 ` Geert Uytterhoeven
2021-07-08 16:07 ` Andy Lutomirski
2021-07-07 20:58 ` Miguel Ojeda
2021-07-07 21:47 ` Laurent Pinchart
2021-07-07 22:44 ` Miguel Ojeda
2021-07-07 17:01 ` Miguel Ojeda
2021-07-07 10:50 ` Mark Brown
2021-07-07 10:56 ` Julia Lawall
2021-07-07 11:27 ` James Bottomley
2021-07-07 11:34 ` James Bottomley
2021-07-07 12:20 ` Greg KH
2021-07-07 12:38 ` James Bottomley
2021-07-07 12:45 ` Greg KH
2021-07-07 17:17 ` Laurent Pinchart
2021-07-08 6:49 ` cdev/devm_* issues (was Re: [TECH TOPIC] Rust for Linux) Greg KH
2021-07-08 8:23 ` Laurent Pinchart
2021-07-08 23:06 ` Linus Walleij
2021-07-09 0:02 ` Dan Williams
2021-07-09 16:53 ` Wedson Almeida Filho
2021-07-13 8:59 ` Linus Walleij
[not found] ` <CAHp75VfW7PxAyU=eYPNWFU_oUY=aStz-4W5gX87KSo402YhMXQ@mail.gmail.com>
2021-07-21 13:46 ` Linus Walleij
2021-07-21 15:49 ` Andy Shevchenko
2021-07-10 7:09 ` Dan Carpenter
2021-07-12 13:42 ` Jason Gunthorpe
2021-07-15 9:54 ` Daniel Vetter
2021-07-21 9:08 ` Dan Carpenter
2021-07-22 9:56 ` Daniel Vetter
2021-07-22 10:09 ` Dan Carpenter
2021-07-08 9:08 ` [TECH TOPIC] Rust for Linux Mauro Carvalho Chehab
2021-07-10 16:42 ` Laurent Pinchart
2021-07-10 17:18 ` Andy Lutomirski
2021-07-07 15:17 ` Mark Brown
2021-07-06 21:45 ` Bart Van Assche
2021-07-06 23:08 ` Stephen Hemminger
2021-07-07 2:41 ` Bart Van Assche
2021-07-07 18:57 ` Linus Torvalds
2021-07-07 20:32 ` Bart Van Assche
2021-07-07 20:39 ` Linus Torvalds
2021-07-07 21:40 ` Laurent Pinchart
2021-07-08 7:22 ` Geert Uytterhoeven
2021-07-07 21:02 ` Laurent Pinchart
2021-07-07 22:11 ` Miguel Ojeda
2021-07-07 22:43 ` Laurent Pinchart
2021-07-07 23:21 ` Miguel Ojeda
2021-07-07 23:40 ` Laurent Pinchart
2021-07-08 0:27 ` Miguel Ojeda
2021-07-08 0:56 ` Laurent Pinchart
2021-07-08 6:26 ` Alexey Dobriyan
2021-07-06 19:05 ` Bart Van Assche
2021-07-06 19:27 ` Miguel Ojeda
2021-07-07 15:48 ` Steven Rostedt
2021-07-07 16:44 ` Miguel Ojeda
2023-08-07 10:03 Miguel Ojeda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YOXibDV8mHT1e6ec@kroah.com \
--to=greg@kroah.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=julia.lawall@inria.fr \
--cc=ksummit@lists.linux.dev \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linus.walleij@linaro.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=roland@kernel.org \
--cc=wedsonaf@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).