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