From: Alice Ryhl <aliceryhl@google.com>
To: "Liam R. Howlett" <Liam.Howlett@oracle.com>,
"Alice Ryhl" <aliceryhl@google.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Matthew Wilcox" <willy@infradead.org>,
"Lorenzo Stoakes" <lorenzo.stoakes@oracle.com>,
"Vlastimil Babka" <vbabka@suse.cz>,
"John Hubbard" <jhubbard@nvidia.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Arnd Bergmann" <arnd@arndb.de>, "Jann Horn" <jannh@google.com>,
"Suren Baghdasaryan" <surenb@google.com>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v13 2/8] mm: rust: add vm_area_struct methods that require read access
Date: Wed, 5 Feb 2025 13:10:16 +0100 [thread overview]
Message-ID: <CAH5fLgh2Y0rG5ntpdiK-ycn9eBvrSXekxPsjDaYWuHBDUYNppw@mail.gmail.com> (raw)
In-Reply-To: <ebwiebbxomsjamv2uk6gnpg2uzjpqw25llvcz7njadklfi66nk@ab5uyq4bvwlb>
On Tue, Feb 4, 2025 at 4:46 PM Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
> > > > > > + let vma = unsafe { bindings::vma_lookup(self.mm.as_raw(), vma_addr) };
> > > > > > +
> > > > > > + if vma.is_null() {
> > > > > > + None
> > > > > > + } else {
> > > > > > + // SAFETY: We just checked that a vma was found, so the pointer is valid. Furthermore,
> > > > > > + // the returned area will borrow from this read lock guard, so it can only be used
> > > > > > + // while the mmap read lock is still held.
> > > > >
> > > > > So We have complicated the locking of the vmas with rcu and per-vma
> > > > > locking recently. We are now able to look up and use a vma under the
> > > > > rcu read lock. Does this translate to rust model?
> > > > >
> > > > > I believe this is true in recent version of binder as well?
> > > >
> > > > Yes. The safety requirements of VmAreaRef is that you must hold the
> > > > mmap read lock *or* the vma read lock while you have a VmAreaRef
> > > > reference. This particular method achieves that requirement by holding
> > > > the mmap read lock. But there is also a Rust lock_vma_under_rcu(), see
> > > > patch 4 for that.
> > >
> > > Right, okay. Thanks. You can get the reference by only holding the rcu
> > > read lock, but you should hold the vma lock to ensure that the vma
> > > itself (and not just the pointer) is safe to use.
> >
> > Hmm... To modify the vma, you must hold the mmap *and* vma write lock,
> > so holding the mmap read lock prevents mutations?
>
> Sorry, I think I confused things with my answer. Your code is fine.
> The phrasing of the "only be used while the mmap read lock is still
> held" made me wonder about further clarification on the locking here
> (because the locking is confusing).
>
> Yes, mmap read lock means there are no writers that can modify the vma.
> Essentially, you are using the lock to ensure the entire vma space isn't
> changed during your operation - which is heavier than just locking one
> vma.
I could extend the safety comment like this:
SAFETY: We just checked that a vma was found, so the pointer is valid.
Furthermore, the returned area will borrow from this read lock guard,
so it can only be used while the mmap read lock is still held. This
ensures that there are no writers because writers must hold both the
mmap and vma write lock.
Alice
next prev parent reply other threads:[~2025-02-05 12:11 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-03 12:14 [PATCH v13 0/8] Rust support for mm_struct, vm_area_struct, and mmap Alice Ryhl
2025-02-03 12:14 ` [PATCH v13 1/8] mm: rust: add abstraction for struct mm_struct Alice Ryhl
2025-02-03 12:14 ` [PATCH v13 2/8] mm: rust: add vm_area_struct methods that require read access Alice Ryhl
2025-02-03 15:44 ` Liam R. Howlett
2025-02-04 12:45 ` Alice Ryhl
2025-02-04 14:55 ` Liam R. Howlett
2025-02-04 15:05 ` Alice Ryhl
2025-02-04 15:46 ` Liam R. Howlett
2025-02-05 12:10 ` Alice Ryhl [this message]
2025-02-05 14:37 ` Liam R. Howlett
2025-02-05 15:24 ` Alice Ryhl
2025-02-05 19:09 ` Liam R. Howlett
2025-02-05 19:12 ` Alice Ryhl
2025-02-05 19:22 ` Liam R. Howlett
2025-02-05 19:26 ` Alice Ryhl
2025-02-04 12:46 ` Alice Ryhl
2025-02-04 14:58 ` Liam R. Howlett
2025-02-03 12:14 ` [PATCH v13 3/8] mm: rust: add vm_insert_page Alice Ryhl
2025-02-03 12:14 ` [PATCH v13 4/8] mm: rust: add lock_vma_under_rcu Alice Ryhl
2025-02-03 12:14 ` [PATCH v13 5/8] mm: rust: add mmput_async support Alice Ryhl
2025-02-03 12:14 ` [PATCH v13 6/8] mm: rust: add VmAreaNew for f_ops->mmap() Alice Ryhl
2025-02-03 12:14 ` [PATCH v13 7/8] rust: miscdevice: add mmap support Alice Ryhl
2025-02-03 12:14 ` [PATCH v13 8/8] task: rust: rework how current is accessed Alice Ryhl
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=CAH5fLgh2Y0rG5ntpdiK-ycn9eBvrSXekxPsjDaYWuHBDUYNppw@mail.gmail.com \
--to=aliceryhl@google.com \
--cc=Liam.Howlett@oracle.com \
--cc=a.hindborg@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alex.gaynor@gmail.com \
--cc=arnd@arndb.de \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=jannh@google.com \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=surenb@google.com \
--cc=tmgross@umich.edu \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/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