From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 045583DEFE7 for ; Fri, 31 Jul 2026 12:52:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.70 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785502350; cv=none; b=cTuUgz9XpC8b8j1zP9UL8+LoNLHmTcliJd1iwo4OTgFWRyGHAoJJ6ro1fYdbYn9FW4AatfNWWB+p0N0sKylnkv/Qh+pJDVoNm6SqFWt7F0Oi9G80//rTlMxPXWL2dNHalnST+pA032DzSnLGPgbcWLU0xatxQSdNh3l1B8ELldQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785502350; c=relaxed/simple; bh=It7kZwaRx0Ep9+u4doLaOtpLhDjb1kbYQ4dRYkS+gjE=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=n/D8SnakilM9f89fdHbdGR6JBA2fXJ9MvgA6uSvPiLjRzKP41xoXwzskQbxUCkv9gO0BBmvalGAyF7c/S8aYZNwpfgDBaMkDaExfowpfKCMiBfjXoZWGPXCeN1jyJgH52pbwUvvyW+lzE5T78ZSFxXTNI2ZeyKPuyuc8iXdN6YE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=V3m77j6q; arc=none smtp.client-ip=209.85.208.70 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="V3m77j6q" Received: by mail-ed1-f70.google.com with SMTP id 4fb4d7f45d1cf-6984787eeddso941863a12.1 for ; Fri, 31 Jul 2026 05:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1785502347; x=1786107147; darn=vger.kernel.org; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=l9F+eXGUPJ1CqPpVTZLneozqshrotXXIxuj3EVO2s6o=; b=V3m77j6qEVlpVZIB7mSWb+RSZ5jlxVc7nYZ8GuXk7egJcy2OEGtUZo9X1E5CZlZnwx WtG0eH3VBrE8hPuxfj2urBE9JnWTI5za0zROZnWUVEgEkWfxUzj7caiKK9rsAxtGZAiz 59VcTBizjDexs2rVVEMBsujrmheeHoCx+RDbUrTucz11c4pdCrYpp617xiTARW3a5rRx C94U7R6dbTd+fp1zKO6Qnxrs+5bo6MITffgR8sk14w3EA6y5J4qOL5xJu2LggaHasc5i OBmtkEh2JAz1riW631QBlNgDcdZF0I7pFk08Zn3s7M2tgP9wxAVRAY/00DAG/dfnoXiK Lf2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785502347; x=1786107147; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=l9F+eXGUPJ1CqPpVTZLneozqshrotXXIxuj3EVO2s6o=; b=pnqOvHpCUm2QPgk2ObkwY4vgTd1SD7cn9H/YQRU88TvubmQAQZJUNPF0neZiXJV7KY wnj8rG4gwPnAgN5nN21k9E5upzfD9RrKRv4NyKciGZk5D59XTi44APfPkib3cJIjx6hd 8a0ZliKRKOiJQjlyK6AmalPcAZgyDZzcHvd/0/JhxYwfiNLHyd4RDMjiXe8equO8dLcV lob3YdRYbsZZiALWObwf+NSmTGobAgMqdMitUAAcEnlLireguL6nCl8hpUUV4jl0BHCl FuDdbWX04fQ+DjDQlKf8VNt8PgSbFXsPKEUV3U9+C05bV5coVow39dpMQKfxCVEgwpD4 hiMA== X-Forwarded-Encrypted: i=1; AHgh+Rr4/0Ty71dzGTxZvv3Jg6PzAfxvRHGHaOF89EaYY0mR3Xg3go1PvlCzMO4X5Tl1w1DPapm0/BNh3Mde2Mg=@vger.kernel.org X-Gm-Message-State: AOJu0Yy85krkfRbsFfPWwLgg0GqfS6843Txu1BORCiGty12S8vVzeqVj pH90FQU900jpfLKSFmiU+aS8SUiyFtctXCqtVnUB+IteKrCZATlL10Rv3QwwvoJXhOU91ELEbXX FGsn5eT0NL0ga0AhvqQ== X-Received: from wmhn21.prod.google.com ([2002:a05:600c:3055:b0:493:dccc:9e0c]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a17:907:c0f:b0:c19:5a94:4121 with SMTP id a640c23a62f3a-c1fd1e12753mr109416966b.6.1785502346913; Fri, 31 Jul 2026 05:52:26 -0700 (PDT) Date: Fri, 31 Jul 2026 12:52:26 +0000 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260722-setonce-populate-v1-0-fa7455c26c42@google.com> <20260722-setonce-populate-v1-2-fa7455c26c42@google.com> Message-ID: Subject: Re: [PATCH 2/3] rust: sync: add SetOnce::try_get_or_populate() From: Alice Ryhl To: Alexandre Courbot Cc: Lyude Paul , Boqun Feng , Gary Guo , Daniel Almeida , "Onur =?utf-8?B?w5Z6a2Fu?=" , Greg Kroah-Hartman , Carlos Llamas , Luis Chamberlain , Petr Pavlu , Daniel Gomez , Sami Tolvanen , Aaron Tomlin , Miguel Ojeda , "=?utf-8?B?QmrDtnJu?= Roy Baron" , Benno Lossin , Andreas Hindborg , Trevor Gross , Danilo Krummrich , Tamir Duberstein , linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org Content-Type: text/plain; charset="utf-8" On Thu, Jul 30, 2026 at 11:48:15PM +0900, Alexandre Courbot wrote: > 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, > >> > + { > >> > + 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. We could extend the naming scheme: * try_get_or_populate_once() only invokes f() once, under lock * try_get_or_populate_racy() may invoke f() multiple times Though the _once naming isn't amazing since it still may invoke f() multiple times if it fails. On failure, the next initializer gets to try again. Thoughts? Alice