linux-kernel - Re: [PATCH v3 4/4] rust: add parameter support to the `module!` macro

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANiq72nBpVy911cVhNFM6teQ0EaE-xs0SB2Qx95O4=nKBdRDuQ@mail.gmail.com>
Date: Fri, 13 Dec 2024 18:14:37 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Andreas Hindborg <a.hindborg@...nel.org>
Cc: Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, 
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <benno.lossin@...ton.me>, Alice Ryhl <aliceryhl@...gle.com>, 
	Masahiro Yamada <masahiroy@...nel.org>, Nathan Chancellor <nathan@...nel.org>, 
	Nicolas Schier <nicolas@...sle.eu>, Trevor Gross <tmgross@...ch.edu>, 
	Adam Bratschi-Kaye <ark.email@...il.com>, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org
Subject: Re: [PATCH v3 4/4] rust: add parameter support to the `module!` macro

On Fri, Dec 13, 2024 at 2:17 PM Andreas Hindborg <a.hindborg@...nel.org> wrote:
>
> scheduled for removal. Interior mutability via `SyncUnsafeCell` provides
> the same functionality and it is my understanding that this feature is
> on track to be stabilized.

I am not sure about the last bit, but even if it is on track, we do
not want to start using new language features or APIs that could
potentially change.

And even if it is a feature that we are sure will not change, we
should still let upstream Rust know before using it, since we are
actively discussing with them the remaining unstable items that the
kernel needs and they are putting the kernel in their roadmap.

So I suggest we mention it next week in the Rust/Rust for Linux meeting.

> Not sure. `val` being null not supposed to happen in the current
> configuration. It should be an unreachable state. So BUG is the right thing?

Since you can easily return an error in this situation, I would say
ideally a `WARN_ON_ONCE` + returning an error would be the best
option, and covers you in case the rest changes and someone forgets to
update this.

> Not in the current configuration. The parameters can only be declared
> "read only". It should be impossible for anyone to call this function.

What I meant is, can you avoid writing the function to begin with, by
leaving a null function pointer in the `kernel_param_ops` struct, i.e.
`None`?

Thanks!

Cheers,
Miguel