From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 1A0671F419B; Mon, 30 Jun 2025 11:19:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751282346; cv=none; b=Rn2vsWJKrYlafnSLE+wvOfD1Z9oLKbT2iAVmrdZbBJLPRZti++WOHmPDoFBFnyb8N/rZu92Cf2LZxZ3Nycc8GEVs2tmZJ1eZflpO5BdVBaUfm7CmULYBtfjL7OyTeD8whX+a1Vdx2V6aS+sDLyeH3hcUuaTVCCyHbFa+VLA/iYk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751282346; c=relaxed/simple; bh=bIpgmPc0b9EDJv5uYq+XPXXxnqq2jlRbVDbZ7cCRdNY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=rmuamDiUgRpNeCB1P8sOMG8yAemi/RxxyCX/X8uuAN9D5sJZTPo68ZbJK2dVVOTS+105VDw+tHIegE250ZoHJevsPjECltY0ILV/x0YbdMEUze6EXYrIbxg0kwClTkCX1NbJNHfFeElr/fVja+S4qXzMQHnD4gqyDvMdtcJj0HA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kf8eheID; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kf8eheID" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 252FEC4CEE3; Mon, 30 Jun 2025 11:19:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751282345; bh=bIpgmPc0b9EDJv5uYq+XPXXxnqq2jlRbVDbZ7cCRdNY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=kf8eheID+HbtQNViBTZdMnfh46M5zDwW4hrciZ2nqmYkjJgSgB/IRja6MfrIue0re vzi/mCxqv51nkQ/jXoxJGslxFjz288XftiQTGncQbwbHxkE3SZuHba6z1OsNneHrky 7b8UmG1yF0eQ44o1nDm2zPozg2+J3BqdxaFouGK6s06SJh9XYT527l1qohMcSAiS/Y YTgP71PC1zz0PF9km5sT1l3c6DQj9O4BTImKlLmLgTmf+xI51wDrkCPGAN7LCGzO+l t3tlmvlAJVAGRAkh18CvOBnxlghbgpU50aFePVsELZcxyY24IctuLnhMHCQAEADUjN CD7XbmpJ/8Dng== From: Andreas Hindborg To: "Benno Lossin" Cc: "Miguel Ojeda" , "Alex Gaynor" , "Boqun Feng" , "Gary Guo" , =?utf-8?Q?Bj=C3=B6rn?= Roy Baron , "Alice Ryhl" , "Masahiro Yamada" , "Nathan Chancellor" , "Luis Chamberlain" , "Danilo Krummrich" , "Nicolas Schier" , "Trevor Gross" , "Adam Bratschi-Kaye" , , , , "Petr Pavlu" , "Sami Tolvanen" , "Daniel Gomez" , "Simona Vetter" , "Greg KH" , "Fiona Behrens" , "Daniel Almeida" , Subject: Re: [PATCH v13 2/6] rust: introduce module_param module In-Reply-To: (Benno Lossin's message of "Fri, 27 Jun 2025 10:23:16 +0200") References: <20250612-module-params-v3-v13-0-bc219cd1a3f8@kernel.org> <20250612-module-params-v3-v13-2-bc219cd1a3f8@kernel.org> <87ikkq648o.fsf@kernel.org> <877c126bce.fsf@kernel.org> <87v7om4jhq.fsf@kernel.org> <878qlh4aj1.fsf@kernel.org> <87plepzke5.fsf@kernel.org> User-Agent: mu4e 1.12.9; emacs 30.1 Date: Mon, 30 Jun 2025 13:18:50 +0200 Message-ID: <87wm8txysl.fsf@kernel.org> Precedence: bulk X-Mailing-List: linux-modules@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain "Benno Lossin" writes: > On Fri Jun 27, 2025 at 9:57 AM CEST, Andreas Hindborg wrote: >> Andreas Hindborg writes: >>> "Benno Lossin" writes: >>>> That's good to know, then let's try to go for something simple. >>>> >>>> I don't think that we can just use a `Mutex`, because we don't have a >>>> way to create it at const time... I guess we could have >>>> >>>> impl Mutex >>>> /// # Safety >>>> /// >>>> /// The returned value needs to be pinned and then `init` needs >>>> /// to be called before any other methods are called on this. >>>> pub unsafe const fn const_new() -> Self; >>>> >>>> pub unsafe fn init(&self); >>>> } >>>> >>>> But that seems like a bad idea, because where would we call the `init` >>>> function? That also needs to be synchronized... >>> >>> Ah, that is unfortunate. The init function will not run before this, so >>> we would need a `Once` or an atomic anyway to initialize the lock. >>> >>> I am not sure if we are allowed to sleep during this, I would have to >>> check. But then we could use a spin lock. >>> >>> We will need the locking anyway, when we want to enable sysfs write >>> access to the parameters. >>> >>>> >>>> Maybe we can just like you said use an atomic bool? >>> >>> Sigh, I will have to check how far that series has come. >>> >> >> I think I am going to build some kind of `Once` feature on top of >> Boqun's atomic series [1], so that we can initialize a lock in these >> statics. We can't use `global_lock!`, because that depends on module >> init to initialize the lock before first use. > > Sounds good, though we probably don't want to name it `Once`. Since it > is something that will be populated in the future, but not by some > random accessor, but rather a specific populator. > > So maybe: > > pub struct Delayed { > dummy: T, > real: Opaque, > populated: Atomic, // or Atomic > writing: Atomic, // or Atomic > } > > impl Delayed { > pub fn new(dummy: T) -> Self { > Self { > dummy, > real: Opaque::uninit(), > populated: Atomic::new(false), > writing: Atomic::new(false), > } > } > > pub fn get(&self) -> &T { > if self.populated.load(Acquire) { > unsafe { &*self.real.get() } > } else { > // maybe print a warning here? > // or maybe let the user configure this in `new()`? > &self.dummy > } > } > > pub fn populate(&self, value: T) { > if self.writing.cmpxchg(false, true, Release) { > unsafe { *self.real.get() = value }; > self.populated.store(true, Release); > } else { > pr_warn!("`Delayed<{}>` written to twice!\n", core::any::type_name::()); > } > } > } > > (no idea if the orderings are correct, I always have to think way to > much about that... especially since our atomics seem to only take one > ordering in compare_exchange?) > >> As far as I can tell, atomics may not land in v6.17, so this series >> will probably not be ready for merge until v6.18 at the earliest. > > Yeah, sorry about that :( Actually, perhaps we could aim at merging this code without this synchronization? The lack of synchronization is only a problem if we support custom parsing. This patch set does not allow custom parsing code, so it does not suffer this issue. Best regards, Andreas Hindborg