Re: [PATCH 0/3] rust: sync: add SetOnce::try_get_or_populate()
"Alexandre Courbot" <[email protected]> Wed, 29 Jul 2026 23:12:04 +0900
| Newsgroups | org.kernel.vger.linux-modules,org.kernel.vger.linux-kernel,org.kernel.vger.rust-for-linux |
|---|---|
| Message-ID | <[email protected]> |
On Wed Jul 22, 2026 at 6:16 PM JST, Alice Ryhl wrote: > The SetOnce::populate() method does not internally synchronize callers > that fail to populate the value with the successful call. This means > that naive loops using as_ref() and populate() can lead to spinning on > the initialization, which is best avoided. Thus, provide a helper that > avoids this issue using a user-provided lock. > > One potential alternative is to change populate() so that the failing > caller actually does synchronize with the successful call to populate(). > However, this is somewhat tricky: > > * There are users of SetOnce that construct it in const context, and we > currently don't have the ability to do that for most locks, so we > cannot easily add a lock to SetOnce. > * Just spinning on the atomic is undesirable unless we disable > preemption in the success path. If we do disable preemption, then that > raises complications for handling the PREEMPT_RT case. > * It also raises questions about deadlocks if populate() is called from > irqs. > > By using a user-provided lock, we do not have to worry about these > issues inside SetOnce. > > This series is based on char-misc-next. > > Signed-off-by: Alice Ryhl <[email protected]> If would be nice if the series could also include a patch updating the GEM shmem module, which is another potential user of `try_get_or_populate` - in particular since the current implementation doesn't seem to be a perfect match yet (see my comments on patch 2) so it would be an opportunity to refine it.