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.
