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 7B498274B2D; Tue, 1 Jul 2025 14:15:06 +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=1751379306; cv=none; b=nNxdeoN/oRqwUpgKP0AMnblAkthz01Q8DU1ARLsla6JU3wzdn5lnJCnknOtV8Ja/uXcI9dqRhV1F+v5DAwKK6PWOKpkmW6eO6+7CQIXckYgZhrAoaJKPdKvualeQtuOm09f0PnY4C8xBBslCzkxQLruk7DyTKNeG1yby3wc78hY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751379306; c=relaxed/simple; bh=d3jbnlo0yloagQLxKasfaTIoGVOeJedPwxIAjOz5ETo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=rJO6J8r4V+ixTTNYRWEKI/r8USlydvY2J0ZgOAEqw4wueuAd4Q1v0cz1hsO6/CQ/DNnMoos+o10bNmzPDN3dYzm4XF8GyQUzfx3CC/CuYevGeF+HfyGVde4Mr0is+U506eHfhcBeDwc9R83I1mcW31tT4y2+JNocJyYVyq0c01Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tvz7jciY; 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="tvz7jciY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67CFBC4CEEB; Tue, 1 Jul 2025 14:15:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751379306; bh=d3jbnlo0yloagQLxKasfaTIoGVOeJedPwxIAjOz5ETo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=tvz7jciYq7khZaH8OSLQc9tcx4gOsIr7mTHkNRuVVM5/o/JSdziFciDB9OshdCA63 4fYz3Mat6l7P86IuypHKtnQJi1G/pIjKy6xpafQBN8X7f4bW3NxIudOpDw6im9hILP c3Egrvoje0aDf2pNV2fUM4an31rDWNXpOWi/OkP28kSt3zEREJ+jBoFw4rb/Ur1Ah2 tqBmbPYXh1dLU4VC7vUB/jdRYxVP4pxP2b622/4pAIo3lzCPFP4U6+48GgYywS3ROG JGPHZS6rIFy+LHlRRNdD7nTeLtyEvYo98m0WQyBLSygrs40N4fwoSYd/9YDxhzT7sq hX7t6KWBKN4DQ== 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 "Tue, 01 Jul 2025 11:05:43 +0200") References: <20250612-module-params-v3-v13-0-bc219cd1a3f8@kernel.org> <877c126bce.fsf@kernel.org> <87v7om4jhq.fsf@kernel.org> <878qlh4aj1.fsf@kernel.org> <87plepzke5.fsf@kernel.org> <87wm8txysl.fsf@kernel.org> <9G3W1seaM7elcwWXaeoaa2nfpFYCf-AmBdvZhACGP13KGUtTPVMwGNYdTQsdtp8ru7GIP3-UYTzXscC1MRUKrg==@protonmail.internalid> <87h5zxxtdw.fsf@kernel.org> <87bjq4xpv7.fsf@kernel.org> User-Agent: mu4e 1.12.9; emacs 30.1 Date: Tue, 01 Jul 2025 16:14:55 +0200 Message-ID: <87zfdovvz4.fsf@kernel.org> Precedence: bulk X-Mailing-List: linux-kbuild@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain "Benno Lossin" writes: > On Tue Jul 1, 2025 at 10:43 AM CEST, Andreas Hindborg wrote: >> "Benno Lossin" writes: >>> On Mon Jun 30, 2025 at 3:15 PM CEST, Andreas Hindborg wrote: >>>> "Benno Lossin" writes: >>>>> On Mon Jun 30, 2025 at 1:18 PM CEST, Andreas Hindborg wrote: >>>>>> "Benno Lossin" writes: >>>>>>> (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? >>>>> >>>>> I won't remember this issue in a few weeks and I fear that it will just >>>>> get buried. In fact, I already had to re-read now what the actual issue >>>>> was... >>>>> >>>>>> 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. >>>>> >>>>> ... In doing that, I saw my original example of UB: >>>>> >>>>> module! { >>>>> // ... >>>>> params: { >>>>> my_param: i64 { >>>>> default: 0, >>>>> description: "", >>>>> }, >>>>> }, >>>>> } >>>>> >>>>> static BAD: &'static i64 = module_parameters::my_param.get(); >>>>> >>>>> That can happen without custom parsing, so it's still a problem... >>>> >>>> Ah, got it. Thanks. >>> >>> On second thought, we *could* just make the accessor function `unsafe`. >>> Of course with a pinky promise to make the implementation safe once >>> atomics land. But I think if it helps you get your driver faster along, >>> then we should do it. >> >> No, I am OK for now with configfs. >> >> But, progress is still great. How about if we add a copy accessor >> instead for now, I think you proposed that a few million emails ago: >> >> pub fn get(&self) -> T; >> >> or maybe rename: >> >> pub fn copy(&self) -> T; >> >> Then we are fine safety wise for now, right? It is even sensible for >> these `T: Copy` types. > > That is better than getting a reference, but still someone could read at > the same time that a write is happening (though we need some new > abstractions AFAIK?). But I fear that we forget about this issue, > because it'll be some time until we land parameters that are `!Copy` (if > at all...) No, that could not happen when we are not allowing custom parsing or sysfs access. Regarding forgetting, I already added a `NOTE` on `!Copy`, and I would add one on this issue as well. Best regards, Andreas Hindborg