Rust-for-linux archive mirror
 help / color / mirror / Atom feed
From: Thomas Bertschinger <tahbertschinger@gmail.com>
To: ojeda@kernel.org, alex.gaynor@gmail.com, wedsonaf@gmail.com,
	rust-for-linux@vger.kernel.org
Cc: Thomas Bertschinger <tahbertschinger@gmail.com>,
	Martin Rodriguez Reboredo <yakoyoku@gmail.com>,
	Alice Ryhl <aliceryhl@google.com>
Subject: [PATCH v2] rust: place generated init_module() function in .init.text
Date: Mon,  5 Feb 2024 18:25:35 -0700	[thread overview]
Message-ID: <20240206012535.480193-1-tahbertschinger@gmail.com> (raw)

Currently Rust kernel modules have their init code placed in the `.text`
section of the .ko file. I don't think this causes any real problems
for Rust modules but it does present a challenge with implementing Rust
functionality for existing C modules.

If a Rust `init_module()` function (that lives in `.text`) calls a C
function annotated with `__init`, then a warning is generated because
the C function lives in `.init.text`.

I ran into this while experimenting with converting the bcachefs kernel
module from C to Rust. The module's `init()`, written in Rust, calls C
functions like `bch2_vfs_init()` which are placed in `.init.text`.

This patch places the macro-generated `init_module()` Rust function in
the `.init.text` section. It also marks that function as unsafe--now it
may not be called again after returning because it may be freed already.

Note that this is not enough on its own to actually get all the module
initialization code in that section. The module author must still add
the `#[link_section = ".init.text"]` attribute to the Rust `init()` in
the `impl kernel::Module` block in order to then call C `__init`
functions. However, this patch enables module authors do so, when
previously it would not be possible (without warnings).

Signed-off-by: Thomas Bertschinger <tahbertschinger@gmail.com>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
---
V2: add "unsafe" to the init_module() function

 rust/macros/module.rs | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/rust/macros/module.rs b/rust/macros/module.rs
index d62d8710d77a..e54293faf523 100644
--- a/rust/macros/module.rs
+++ b/rust/macros/module.rs
@@ -222,10 +222,14 @@ pub(crate) fn module(ts: TokenStream) -> TokenStream {
             }};
 
             // Loadable modules need to export the `{{init,cleanup}}_module` identifiers.
+            /// # Safety
+            /// This function must only be called once, during module initialization, because it
+            /// may be freed after it returns.
             #[cfg(MODULE)]
             #[doc(hidden)]
             #[no_mangle]
-            pub extern \"C\" fn init_module() -> core::ffi::c_int {{
+            #[link_section = \".init.text\"]
+            pub unsafe extern \"C\" fn init_module() -> core::ffi::c_int {{
                 __init()
             }}
 
-- 
2.43.0


             reply	other threads:[~2024-02-06  1:26 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-06  1:25 Thomas Bertschinger [this message]
2024-02-06  1:39 ` [PATCH v2] rust: place generated init_module() function in .init.text Martin Rodriguez Reboredo
2024-02-06  2:13   ` Thomas Bertschinger
2024-02-06  3:10     ` Trevor Gross
2024-02-06  3:17 ` Trevor Gross
2024-02-06 10:01 ` Greg KH
2024-02-06 10:51   ` Miguel Ojeda
2024-02-06 10:58     ` Greg KH
2024-02-06 11:31       ` Miguel Ojeda
2024-02-06 14:49     ` Thomas Bertschinger
2024-02-06 16:07       ` Martin Rodriguez Reboredo
2024-02-06 17:19         ` Miguel Ojeda
2024-02-06 21:28           ` Martin Rodriguez Reboredo
2024-02-06 17:19       ` Miguel Ojeda
2024-02-06 10:01 ` Greg KH
2024-02-06 10:29   ` Alice Ryhl
2024-02-06 10:50     ` Greg KH
2024-02-06 11:18       ` Miguel Ojeda
2024-02-06 10:57   ` Miguel Ojeda

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=20240206012535.480193-1-tahbertschinger@gmail.com \
    --to=tahbertschinger@gmail.com \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=wedsonaf@gmail.com \
    --cc=yakoyoku@gmail.com \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).