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 6D7DF2374E; Tue, 14 May 2024 10:59: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=1715684345; cv=none; b=iSODtE44BFq5YLKhE9kbgu3UdEhZGqKj6+VTS01lRlOkbb85p1Aubp2rK1SG1WbS8SqDVstuLA3xTGbuKv64DXu7iBzWTHWReRbL+gSn+YMRGVdWjLcRUcdLQRWUOoScr4wsbvFuNtH2ay6TrMSwtZPCkMG7S/QfyemdjDt8rqg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715684345; c=relaxed/simple; bh=TeuAfgymTVBlLISmk4RR9LlHrSnIakFG9KCUYe//KhY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jUaNyQ7P6CsXPar3y9t5Rz5iZI2kfdcFAKXE9bx6xO1IJGnE7QM9tTTVSRawRsN0B3Pz8Lrv9cV4o8pxocNGDMCWVUthsWHO+4NE6Axrq1dfz7CN4HS1yIBTlJj0Jj6/nPuGQk+7NVXqeivPh2jz4l2eiDajdao+xUziX/m4VzA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=PEiT0NBP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="PEiT0NBP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C95E9C2BD10; Tue, 14 May 2024 10:59:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1715684345; bh=TeuAfgymTVBlLISmk4RR9LlHrSnIakFG9KCUYe//KhY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PEiT0NBPJJ3i8e0MScWFalqpeQiAKfNEyNTkSBD6dtPCrQk5NI9lnPR7dazC73fXZ g6bbCN9lsw8h585ZG2VwdbMxtvcipACxjoFutrGPqnzhk1kF3VJ1fIm/eOzGo3OQ1p YJWWo+7dMUjSL52fxeKLtbH+hFXSkwL1YvQ2iidI= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Thomas Bertschinger , Martin Rodriguez Reboredo , Alice Ryhl , Miguel Ojeda , Sasha Levin Subject: [PATCH 6.6 005/301] rust: module: place generated init_module() function in .init.text Date: Tue, 14 May 2024 12:14:36 +0200 Message-ID: <20240514101032.432772913@linuxfoundation.org> X-Mailer: git-send-email 2.45.0 In-Reply-To: <20240514101032.219857983@linuxfoundation.org> References: <20240514101032.219857983@linuxfoundation.org> User-Agent: quilt/0.67 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.6-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Bertschinger [ Upstream commit 1b6170ff7a203a5e8354f19b7839fe8b897a9c0d ] 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 as long as all code called during initialization lives in `.text`. However, if a Rust `init_module()` function (that lives in `.text`) calls a function marked with `__init` (in C) or `#[link_section = ".init.text"]` (in Rust), then a warning is generated by modpost because that function lives in `.init.text`. For example: WARNING: modpost: fs/bcachefs/bcachefs: section mismatch in reference: init_module+0x6 (section: .text) -> _RNvXCsj7d3tFpT5JS_15bcachefs_moduleNtB2_8BcachefsNtCsjDtqRIL3JAG_6kernel6Module4init (section: .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 `init_module()` as unsafe--now it may not be called after module initialization completes 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 `__init` functions. However, this patch enables module authors do so, when previously it would not be possible (without warnings). Signed-off-by: Thomas Bertschinger Reviewed-by: Martin Rodriguez Reboredo Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20240206153806.567055-1-tahbertschinger@gmail.com [ Reworded title to add prefix. ] Signed-off-by: Miguel Ojeda Stable-dep-of: 7044dcff8301 ("rust: macros: fix soundness issue in `module!` macro") Signed-off-by: Sasha Levin --- rust/macros/module.rs | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/rust/macros/module.rs b/rust/macros/module.rs index d62d8710d77ab..27979e582e4b9 100644 --- a/rust/macros/module.rs +++ b/rust/macros/module.rs @@ -222,10 +222,15 @@ pub(crate) fn module(ts: TokenStream) -> TokenStream { }}; // Loadable modules need to export the `{{init,cleanup}}_module` identifiers. + /// # Safety + /// + /// This function must not be called after module initialization, because it may be + /// freed after that completes. #[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