From: Andreas Hindborg <a.hindborg@kernel.org>
To: "Alice Ryhl" <aliceryhl@google.com>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Masahiro Yamada" <masahiroy@kernel.org>,
"Nathan Chancellor" <nathan@kernel.org>,
"Luis Chamberlain" <mcgrof@kernel.org>,
"Danilo Krummrich" <dakr@kernel.org>,
"Nicolas Schier" <nicolas.schier@linux.dev>,
"Trevor Gross" <tmgross@umich.edu>,
"Adam Bratschi-Kaye" <ark.email@gmail.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kbuild@vger.kernel.org, "Petr Pavlu" <petr.pavlu@suse.com>,
"Sami Tolvanen" <samitolvanen@google.com>,
"Daniel Gomez" <da.gomez@samsung.com>,
"Simona Vetter" <simona.vetter@ffwll.ch>,
"Greg KH" <gregkh@linuxfoundation.org>,
"Fiona Behrens" <me@kloenk.dev>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
linux-modules@vger.kernel.org
Subject: Re: [PATCH v11 2/3] rust: add parameter support to the `module!` macro
Date: Mon, 05 May 2025 11:55:33 +0200 [thread overview]
Message-ID: <878qnbxtyi.fsf@kernel.org> (raw)
In-Reply-To: <aBTMMHWNXS7wK7zS@google.com> (Alice Ryhl's message of "Fri, 02 May 2025 13:44:16 +0000")
"Alice Ryhl" <aliceryhl@google.com> writes:
> On Fri, May 02, 2025 at 02:16:35PM +0200, Andreas Hindborg wrote:
>> Add support for module parameters to the `module!` macro. Implement read
>> only support for integer types without `sysfs` support.
>>
>> Acked-by: Petr Pavlu <petr.pavlu@suse.com> # from modules perspective
>> Tested-by: Daniel Gomez <da.gomez@samsung.com>
>> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>
>> +unsafe extern "C" fn set_param<T>(
>> + val: *const kernel::ffi::c_char,
>> + param: *const crate::bindings::kernel_param,
>> +) -> core::ffi::c_int
>> +where
>> + T: ModuleParam,
>> +{
>> + // NOTE: If we start supporting arguments without values, val _is_ allowed
>> + // to be null here.
>> + if val.is_null() {
>> + // TODO: Use pr_warn_once available.
>> + crate::pr_warn!("Null pointer passed to `module_param::set_param`");
>> + return EINVAL.to_errno();
>> + }
>> +
>> + // SAFETY: By function safety requirement, val is non-null and
>> + // null-terminated. By C API contract, `val` is live and valid for reads
>> + // for the duration of this function.
>> + let arg = unsafe { CStr::from_char_ptr(val) };
>> +
>> + crate::error::from_result(|| {
>> + let new_value = T::try_from_param_arg(arg)?;
>> +
>> + // SAFETY: `param` is guaranteed to be valid by C API contract
>> + // and `arg` is guaranteed to point to an instance of `T`.
>> + let old_value = unsafe { (*param).__bindgen_anon_1.arg as *mut T };
>> +
>> + // SAFETY: `old_value` is valid for writes, as we have exclusive
>> + // access. `old_value` is pointing to an initialized static, and
>> + // so it is properly initialized.
>> + unsafe { core::ptr::replace(old_value, new_value) };
>
> You don't use the return value of this, so this is equivalent to
> unsafe { *old_value = new_value };
Thanks.
>
>> +macro_rules! make_param_ops {
>> + ($ops:ident, $ty:ty) => {
>> + ///
>> + /// Static [`kernel_param_ops`](srctree/include/linux/moduleparam.h)
>> + /// struct generated by `make_param_ops`
>> + #[doc = concat!("for [`", stringify!($ty), "`].")]
>> + pub static $ops: $crate::bindings::kernel_param_ops = $crate::bindings::kernel_param_ops {
>> + flags: 0,
>> + set: Some(set_param::<$ty>),
>> + get: None,
>> + free: Some(free::<$ty>),
>
> You could potentially only include `free` if
> `core::mem::needs_drop::<T>()` as an optimization.
Right, nice 👍
>
>> + fn emit_params(&mut self, info: &ModuleInfo) {
>> + let Some(params) = &info.params else {
>> + return;
>> + };
>> +
>> + for param in params {
>> + let ops = param_ops_path(¶m.ptype);
>> +
>> + // Note: The spelling of these fields is dictated by the user space
>> + // tool `modinfo`.
>> + self.emit_param("parmtype", ¶m.name, ¶m.ptype);
>> + self.emit_param("parm", ¶m.name, ¶m.description);
>> +
>> + write!(
>> + self.param_buffer,
>> + "
>> + pub(crate) static {param_name}:
>> + ::kernel::module_param::ModuleParamAccess<{param_type}> =
>> + ::kernel::module_param::ModuleParamAccess::new({param_default});
>
> Is this global accessible to the user?
Yes.
> It would be a use-after-free to
> access it during module teardown. For example, what if I access this
> static during its own destructor? Or during the destructor of another
> module parameter?
Yes, that is a problem.
We can get around it for now by just not calling `free` for now. We only
support simple types that do not need drop. I think we would have to
seal the `ModuleParam` trait for this.
For a proper solution, we could
- Require a token to read the parameter.
- Synchronize on a module private field and return an option from the
parameter getter. This would require module exit to run before param
free. I think this is the case, but I did not check.
- Use a `Revocable` and revoke the parameter in `free`.
Any other ideas or comments on the outlined solutions?
Best regards,
Andreas Hindborg
next prev parent reply other threads:[~2025-05-05 9:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-02 12:16 [PATCH v11 0/3] rust: extend `module!` macro with integer parameter support Andreas Hindborg
2025-05-02 12:16 ` [PATCH v11 1/3] rust: str: add radix prefixed integer parsing functions Andreas Hindborg
2025-05-02 12:16 ` [PATCH v11 2/3] rust: add parameter support to the `module!` macro Andreas Hindborg
2025-05-02 13:44 ` Alice Ryhl
2025-05-05 9:55 ` Andreas Hindborg [this message]
2025-05-06 9:04 ` Alice Ryhl
2025-05-06 11:53 ` Andreas Hindborg
2025-05-02 12:16 ` [PATCH v11 3/3] modules: add rust modules files to MAINTAINERS Andreas Hindborg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878qnbxtyi.fsf@kernel.org \
--to=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=ark.email@gmail.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=da.gomez@samsung.com \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=mcgrof@kernel.org \
--cc=me@kloenk.dev \
--cc=nathan@kernel.org \
--cc=nicolas.schier@linux.dev \
--cc=ojeda@kernel.org \
--cc=petr.pavlu@suse.com \
--cc=rust-for-linux@vger.kernel.org \
--cc=samitolvanen@google.com \
--cc=simona.vetter@ffwll.ch \
--cc=tmgross@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).