linux-kernel - Re: linux-next: build failure after merge of the rust-pin-init tree

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: <DAIPCCIHRLHW.1TDNY93G6UZM0@kernel.org>
Date: Tue, 10 Jun 2025 10:15:08 +0200
From: "Benno Lossin" <lossin@...nel.org>
To: "Stephen Rothwell" <sfr@...b.auug.org.au>, "Miguel Ojeda"
 <ojeda@...nel.org>, "Andreas Hindborg" <a.hindborg@...nel.org>
Cc: "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>, "Linux Next
 Mailing List" <linux-next@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the rust-pin-init tree

On Tue Jun 10, 2025 at 9:59 AM CEST, Benno Lossin wrote:
> On Tue Jun 10, 2025 at 6:22 AM CEST, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the rust-pin-init tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> error[E0282]: type annotations needed
>>    --> rust/kernel/configfs.rs:154:26
>>     |
>> 154 |             subsystem <- pin_init::zeroed().chain(
>>     |                          ^^^^^^^^^^^^^^^^ cannot infer type of the type parameter `T` declared on the function `zeroed`
>>     |
>> help: consider specifying the generic argument
>>     |
>> 154 |             subsystem <- pin_init::zeroed::<T>().chain(
>>     |                                          +++++
>>
>> error[E0282]: type annotations needed
>>    --> rust/kernel/configfs.rs:264:22
>>     |
>> 264 |             group <- pin_init::zeroed().chain(|v: &mut Opaque<bindings::config_group>| {
>>     |                      ^^^^^^^^^^^^^^^^ cannot infer type of the type parameter `T` declared on the function `zeroed`
>>     |
>> help: consider specifying the generic argument
>>     |
>> 264 |             group <- pin_init::zeroed::<T>().chain(|v: &mut Opaque<bindings::config_group>| {
>>     |                                      +++++
>>
>> error: aborting due to 2 previous errors
>>
>> For more information about this error, try `rustc --explain E0282`.
>>
>> Caused by commit
>>
>>   0bcaea04244b ("rust: pin-init: rename `zeroed` to `init_zeroed`")
>>
>> I have used the rust-pin-init tree from next-20250606 for today.
>
> Thanks for catching this! I didn't test with `CONFIG_CONFIGFS=y`, so the
> code was cfg'd out... I'll add it to my tests.
>
> @Andreas I'll send a new version of the commit above with configfs
> changed.

(sorry forgot to add your emails and also some new info)

Actually, the correct change would be this in commit 0bcaea04244b
("rust: pin-init: rename `zeroed` to `init_zeroed`"):

diff --git a/rust/kernel/configfs.rs b/rust/kernel/configfs.rs
index 34d0bea4f9a5..6d566a8bde74 100644
--- a/rust/kernel/configfs.rs
+++ b/rust/kernel/configfs.rs
@@ -151,7 +151,7 @@ pub fn new(
         data: impl PinInit<Data, Error>,
     ) -> impl PinInit<Self, Error> {
         try_pin_init!(Self {
-            subsystem <- pin_init::zeroed().chain(
+            subsystem <- pin_init::init_zeroed().chain(
                 |place: &mut Opaque<bindings::configfs_subsystem>| {
                     // SAFETY: We initialized the required fields of `place.group` above.
                     unsafe {
@@ -261,7 +261,7 @@ pub fn new(
         data: impl PinInit<Data, Error>,
     ) -> impl PinInit<Self, Error> {
         try_pin_init!(Self {
-            group <- pin_init::zeroed().chain(|v: &mut Opaque<bindings::config_group>| {
+            group <- pin_init::init_zeroed().chain(|v: &mut Opaque<bindings::config_group>| {
                 let place = v.get();
                 let name = name.as_bytes_with_nul().as_ptr();
                 // SAFETY: It is safe to initialize a group once it has been zeroed.

@Miguel, @Andreas, how should I go about this? Send the commit above
augmented with the diff, or send a patch with just the diff to the list?
Or apply the diff directly to the commit in the pin-init-next branch &
rebasing (potentially adding an Acked-by from Andreas)? Or some other
way?

---
Cheers,
Benno