On Sat, 9 Aug 2025, 12:13 Paolo Bonzini, <pbonz...@redhat.com> wrote:
>
>
> Il sab 9 ago 2025, 09:00 Zhao Liu <zhao1....@intel.com> ha scritto:
>
>> > pub fn get<'g>(&self, _: &'g RcuGuard) -> Option<&'g T> {
>> > unsafe {
>> > self.raw_get().as_ref()
>> > }
>> > }
>> > }
>> >
>> > Using this is a bit ugly, because you need transmute, but it's isolated:
>> >
>> > impl AddressSpace {
>> > pub fn get_flatview(&self, rcu: &'g Guard) -> &'g FlatView {
>>
>> IIUC, this lifetime is using the "branded type" pattern as ParentInit.
>>
>
> No, it's much simpler (that one uses the combination of for<'identity> and
> PhantomData as explained in the comment). It says that the lifetime of the
> returned reference cannot exceed the guard. It's just like
>
> pub fn get_item(&self, array: &'g [u8]) -> &'g u8 {
> &array[self.0]
> }
>
> Except that the guard is only there to limit the lifetime and not to hold
> data.
>
> In addition, about rcu_read_lock_held(), I thought at C side, there're
>> so many comments are saying "Called within RCU critical section" but
>> without any check.
>>
>> So I wonder whether we should do some check for RCU critical section,
>> just like bql check via `assert!(bql_locked())`. Maybe we can have a
>> Rcu debug feature to cover all these checks.
>>
>
> In Rust you would just pass a &RcuGuard into the function (or store it in
> a struct) for a zero-cost assertion that you are in the RCU critical
> section.
>
Agreed. You could put debug_asserts for sanity check for good measure.
Paolo
>
>
>> Thanks,
>> Zhao
>>
>>
>>
