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: <87msag2b8r.fsf@kernel.org>
Date: Tue, 10 Jun 2025 11:32:04 +0200
From: Andreas Hindborg <a.hindborg@...nel.org>
To: "Benno Lossin" <lossin@...nel.org>
Cc: "Stephen Rothwell" <sfr@...b.auug.org.au>,  "Miguel Ojeda"
 <ojeda@...nel.org>,  "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

"Benno Lossin" <lossin@...nel.org> writes:

> 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?

I think you should add this change directly in your tree. I think you
should just fold it into the breaking commit so we avoid commits that do
not build.

Acked-by: Andreas Hindborg <a.hindborg@...nel.org>


Best regards,
Andreas Hindborg




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ