[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231201090636.2179663-1-aliceryhl@google.com>
Date: Fri, 1 Dec 2023 09:06:35 +0000
From: Alice Ryhl <aliceryhl@...gle.com>
To: benno.lossin@...ton.me, brauner@...nel.org
Cc: a.hindborg@...sung.com, alex.gaynor@...il.com,
aliceryhl@...gle.com, arve@...roid.com, bjorn3_gh@...tonmail.com,
boqun.feng@...il.com, cmllamas@...gle.com,
dan.j.williams@...el.com, dxu@...uu.xyz, gary@...yguo.net,
gregkh@...uxfoundation.org, joel@...lfernandes.org,
keescook@...omium.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, maco@...roid.com, ojeda@...nel.org,
peterz@...radead.org, rust-for-linux@...r.kernel.org,
surenb@...gle.com, tglx@...utronix.de, tkjos@...roid.com,
viro@...iv.linux.org.uk, wedsonaf@...il.com, willy@...radead.org
Subject: Re: [PATCH 2/7] rust: cred: add Rust abstraction for `struct cred`
Benno Lossin <benno.lossin@...ton.me> writes:
> On 11/29/23 13:51, Alice Ryhl wrote:
>> + /// Returns the credentials of the task that originally opened the file.
>> + pub fn cred(&self) -> &Credential {
>> + // This `read_volatile` is intended to correspond to a READ_ONCE call.
>> + //
>> + // SAFETY: The file is valid because the shared reference guarantees a nonzero refcount.
>> + //
>> + // TODO: Replace with `read_once` when available on the Rust side.
>> + let ptr = unsafe { core::ptr::addr_of!((*self.0.get()).f_cred).read_volatile() };
>> +
>> + // SAFETY: The signature of this function ensures that the caller will only access the
>> + // returned credential while the file is still valid, and the credential must stay valid
>> + // while the file is valid.
>
> About the last part of this safety comment, is this a guarantee from the
> C side? If yes, then I would phrase it that way:
>
> ... while the file is still valid, and the C side ensures that the
> credentials stay valid while the file is valid.
Yes, that's my intention with this code.
But I guess this is a good question for Christian Brauner to confirm:
If I read the credential from the `f_cred` field, is it guaranteed that
the pointer remains valid for at least as long as the file?
Or should I do some dance along the lines of "lock file, increment
refcount on credential, unlock file"?
Alice
Powered by blists - more mailing lists