[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1cb1a118-7cc2-4ba5-bf56-b51bfd84cd63@gmail.com>
Date: Fri, 22 Nov 2024 10:09:50 +0200
From: Abdiel Janulgue <abdiel.janulgue@...il.com>
To: Jann Horn <jannh@...gle.com>
Cc: rust-for-linux@...r.kernel.org, Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>,
Gary Guo <gary@...yguo.net>, Björn Roy Baron
<bjorn3_gh@...tonmail.com>, Benno Lossin <benno.lossin@...ton.me>,
Andreas Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>,
Trevor Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>,
Wedson Almeida Filho <wedsonaf@...il.com>,
Valentin Obst <kernel@...entinobst.de>,
open list <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"open list:MEMORY MANAGEMENT" <linux-mm@...ck.org>, airlied@...hat.com
Subject: Re: [PATCH v3 2/2] rust: page: Extend support to existing struct page
mappings
On 21/11/2024 22:17, Jann Horn wrote:
>
> Does Rust also prevent safe code from invoking inc_ref() on the
> returned Page reference? Normally, the AlwaysRefCounted trait means
> that safe code can create an owned reference from a shared reference,
> right?
While it is possible for someone to *manually* convert the Page
reference returned in page_slice_to_page() to a refcounted Page (one
could wrap it in an ARef). However, by design, page_slice_to_page()
explicitly returns just an ordinary Page reference. We could add an
invariant in page_slice_to_page() to warn against such usage just in case.
Anyway seems like the consensus from the other thread is to avoid
refcounting the rust Page abstraction. If we go with that, then that
moots this issue.
Regards,
Abdiel
Powered by blists - more mailing lists