Re: [PATCH 2/7] rust: cred: add Rust abstraction for `struct cred`

From: Alice Ryhl
Date: Fri Dec 01 2023 - 04:06:47 EST


Benno Lossin <benno.lossin@xxxxxxxxx> 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