On 22/11/2024 09:55, Alice Ryhl wrote:
On Thu, Nov 21, 2024 at 9:18 PM Jann Horn <jannh@xxxxxxxxxx> wrote:
On Wed, Nov 20, 2024 at 11:56 PM Abdiel Janulgue
<abdiel.janulgue@xxxxxxxxx> wrote:
On 19/11/2024 19:07, Jann Horn wrote:
+ pub fn page_slice_to_page<'a>(page: &PageSlice) -> Result<&'a Self>
Sorry, can you explain to me what the semantics of this are? Does this
create a Page reference that is not lifetime-bound to the PageSlice?
This creates a Page reference that is tied to the lifetime of the `C
struct page` behind the PageSlice buffer. Basically, it's just a cast
from the struct page pointer and does not own that resource.
How is the Page reference tied to the lifetime of the C "struct page"?
I asked some Rust experts to explain to me what this method signature
expands to, and they added the following to the Rust docs:
https://github.com/rust-lang/reference/blob/master/src/lifetime-elision.md
```
fn other_args1<'a>(arg: &str) -> &'a str; // elided
fn other_args2<'a, 'b>(arg: &'b str) -> &'a str; // expanded
```
Basically, my understanding is that since you are explicitly
specifying that the result should have lifetime 'a, but you are not
specifying the lifetime of the parameter, the parameter is given a
separate, unrelated lifetime by the compiler? Am I misunderstanding
how this works, or is that a typo in the method signature?
No, you are correct. The signature is wrong and lets the caller pick
any lifetime they want, with no relation to the lifetime of the
underlying `struct page`.
But that could be put in the invariant that the PageSlice buffer must
last at least the lifetime `'a`?
From a C perspective, what are the lifetime requirements of vmalloc_to_page?
If I'm not mistaken, that should be the lifetime of the vmalloc'd buffer
right?
