Re: [PATCH 2/3] rust: sync: add SetOnce::try_get_or_populate()

["Alexandre Courbot" <acourbot@nvidia.com>]

On Thu Jul 30, 2026 at 6:11 PM JST, Alice Ryhl wrote:
> On Wed, Jul 29, 2026 at 11:05:55PM +0900, Alexandre Courbot wrote:
>> On Wed Jul 22, 2026 at 6:16 PM JST, Alice Ryhl wrote:
>> > +    where
>> > +        B: lock::Backend,
>> > +        F: FnOnce() -> Result<T, E>,
>> > +    {
>> > +        if let Some(value) = self.as_ref() {
>> > +            return Ok(value);
>> > +        }
>> > +
>> > +        let mut to_insert = f()?;
>> 
>> This means that `f` can run more than once for a given `SetOnce`, which
>> can lead to problems depending on `f`'s' side-effects.
>> 
>> In the GEM shmem case, we would create a second `SGTableMap`, and since
>> `SGTableMap` assumes it is the sole owner, the last instance to drop
>> would create a use-after-free.
>> 
>> Now this sounds more like a problem with `SGTableMap`, but if we cannot
>> avoid calling `f` at least twice then I think it would help if this was
>> documented.
>
> Hmm ... this is the behavior I want in Binder. Actually creating the
> value is an allocation, but my lock is a spinlock so I cannot invoke f()
> under the lock. This means that each caller will make their own
> allocation, and then we throw away any extras if there are concurrent
> callers.
>
> If GEM shmem wants f() invoked under the lock, then that's just a
> different operation than the one Binder wants.
>
> Do you think we should add both?

Possibly... but this would introduce a potential footgun that sleeps
while holding a spinlock, unless we limit the run-f-under-lock version
to work only with mutexes.

Maybe the proper solution is to fix `SGTableMap` so it supports multiple
instantiations. It is, after all, a bit footgunny on its own.

In any case, the current versions should warn users about the fact that
`f` can be called more than once imho.