From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 22D87261B71 for ; Fri, 29 May 2026 17:32:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780075927; cv=none; b=TiOLx4N8mVfO+c+5FKg6NdswW6/C84YNXg51wKJeXVf+NSW44NvkdlNnZtRWBfuCPvwObI0S6Fa9BQVUmvg41ITIjRZ1beQ5bdQ7BbNZapXwIK7TTTUOB0Kc4rf29KzW/6A0Tcy5R8HoHECt0X59DxwMmikwbbB4EGe5V+/emK8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780075927; c=relaxed/simple; bh=4ascWv024QgcC6IIJp+HFw9zJp1YUZCmnnf6TYBt4fg=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=L078dSrn4SL59H4FKSRRzA4coN8XrKkpea9VRE57gbfTDyZpvm0jpsSfQQXZ11x1Rv3IG/WSUNZfhidlCLLju5J0YvfV5zBHbrJnqz43QlRN2e2lntEIpZx1hyDV/oB3X/C1yUmwpU5OXo+mFDnjCrspxjQZpPrw3zA7vuJNEF4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=PWWWJSIP; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="PWWWJSIP" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1780075925; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=TCbzlCqjTBRG2TfsDWMEQYTU39QbHkvS+53/vDLXzes=; b=PWWWJSIPwPX3QtvkOEHpvFwpoVmAmTF09qwn3hP6fibtl8yUayijv1bFKd14KgtLMHqXG8 irHE2x/O60oMBZhgGGVnxJQxDzoBjEtKVlF3nufQce0z+WAes7CMtffczwSzJvXWGvkdcf BsWbp8i/gwpEKPdwUfDljbMe0yGsV+A= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-288-zB3bBx82Og2lTujoFF8v1w-1; Fri, 29 May 2026 13:31:59 -0400 X-MC-Unique: zB3bBx82Og2lTujoFF8v1w-1 X-Mimecast-MFC-AGG-ID: zB3bBx82Og2lTujoFF8v1w_1780075916 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 3AA2218002E3; Fri, 29 May 2026 17:31:56 +0000 (UTC) Received: from GoldenWind.redhat.com (unknown [10.22.89.101]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 50C6E30001BB; Fri, 29 May 2026 17:31:54 +0000 (UTC) From: Lyude Paul To: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org Cc: "Gary Guo" , "Ingo Molnar" , "Miguel Ojeda" , "Alice Ryhl" , "Tamir Duberstein" , "Boqun Feng" , "Peter Zijlstra" , "Benno Lossin" , "Will Deacon" , "Lyude Paul" Subject: [PATCH v2 0/2] rust: sync: Introduce LazyInit Date: Fri, 29 May 2026 13:30:40 -0400 Message-ID: <20260529173137.303717-1-lyude@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 While trying to write up some SGTable bindings for the GEM shmem helpers, I discovered that SetOnce is actually quite difficult to make use of in a number of situations. For one: there is (upstream) currently no way to use it with fallible initializers. Even with some of the work being done to add support for this from Gary Guo and Alvin Sun: https://lore.kernel.org/rust-for-linux/20260326-b4-tyr-debugfs-v1-1-074badd18716@linux.dev/ We're still left with the issue that if two callers race on trying to call init(), there's no actual way for either of them to block until the thread they raced with is done initializing the contents of the container. LazyInit is my proposed solution to this issue. It provides a container which protects the initialization of its contents, without protecting access to its contents (implying of course, that its contents have to provide their own thread synchronization). Lyude Paul (2): rust: sync: lock: Add Lock::get_mut_pinned() rust: sync: Introduce LazyInit rust/kernel/sync.rs | 2 + rust/kernel/sync/lazy_init.rs | 352 ++++++++++++++++++++++++++++++++++ rust/kernel/sync/lock.rs | 11 ++ 3 files changed, 365 insertions(+) create mode 100644 rust/kernel/sync/lazy_init.rs base-commit: 0e42ec83d46ab8877d38d37493328ed7d1a24de8 -- 2.54.0