linux-next: build failure after merge of the rust-xarray tree

linux-next: build failure after merge of the rust-xarray tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2589 bytes --]

Hi all,

After merging the rust-xarray tree, today's linux-next build (x86_64
allmodconfig) failed like this:

rror[E0308]: mismatched types
   --> rust/kernel/cpufreq.rs:633:37
    |
633 |             Some(unsafe { T::borrow(self.as_ref().driver_data) })
    |                           --------- ^^^^^^^^^^^^^^^^^^^^^^^^^ expected `*mut <... as ForeignOwnable>::PointedTo`, found `*mut c_void`
    |                           |
    |                           arguments to this function are incorrect
    |
    = note: expected raw pointer `*mut <T as ForeignOwnable>::PointedTo`
               found raw pointer `*mut c_void`
note: associated function defined here
   --> rust/kernel/types.rs:98:15
    |
98  |     unsafe fn borrow<'a>(ptr: *mut Self::PointedTo) -> Self::Borrowed<'a>;
    |               ^^^^^^
help: consider constraining the associated type `<T as ForeignOwnable>::PointedTo` to `c_void`
    |
628 |     pub fn data<T: ForeignOwnable<PointedTo = c_void>>(&mut self) -> Option<<T>::Borrowed<'_>> {
    |                                  ++++++++++++++++++++

error[E0308]: mismatched types
   --> rust/kernel/cpufreq.rs:660:62
    |
660 |                 unsafe { <T as ForeignOwnable>::from_foreign(self.as_ref().driver_data) },
    |                          ----------------------------------- ^^^^^^^^^^^^^^^^^^^^^^^^^ expected `*mut <... as ForeignOwnable>::PointedTo`, found `*mut c_void`
    |                          |
    |                          arguments to this function are incorrect
    |
    = note: expected raw pointer `*mut <T as ForeignOwnable>::PointedTo`
               found raw pointer `*mut c_void`
note: associated function defined here
   --> rust/kernel/types.rs:63:15
    |
63  |     unsafe fn from_foreign(ptr: *mut Self::PointedTo) -> Self;
    |               ^^^^^^^^^^^^
help: consider constraining the associated type `<T as ForeignOwnable>::PointedTo` to `c_void`
    |
653 |     fn clear_data<T: ForeignOwnable<PointedTo = c_void>>(&mut self) -> Option<T> {
    |                                    ++++++++++++++++++++

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0308`.

Caused by commit

  a68f46e83747 ("rust: types: add `ForeignOwnable::PointedTo`")

interacting with commit

  254df142ab42 ("rust: cpufreq: Add initial abstractions for cpufreq framework")

from the cpufreq-arm tree.

I don't know how to fix this up, so I have dropped the rust-xarray tree
for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the rust-xarray tree

[Viresh Kumar]

On 30-04-25, 20:23, Stephen Rothwell wrote:
> Caused by commit
> 
>   a68f46e83747 ("rust: types: add `ForeignOwnable::PointedTo`")
> 
> interacting with commit
> 
>   254df142ab42 ("rust: cpufreq: Add initial abstractions for cpufreq framework")
> 
> from the cpufreq-arm tree.
> 
> I don't know how to fix this up, so I have dropped the rust-xarray tree
> for today.

Probably this:

diff --git a/rust/kernel/cpufreq.rs b/rust/kernel/cpufreq.rs
index 49246e50f67e..82d20b999e6c 100644
--- a/rust/kernel/cpufreq.rs
+++ b/rust/kernel/cpufreq.rs
@@ -630,7 +630,7 @@ pub fn data<T: ForeignOwnable>(&mut self) -> Option<<T>::Borrowed<'_>> {
             None
         } else {
             // SAFETY: The data is earlier set from [`set_data`].
-            Some(unsafe { T::borrow(self.as_ref().driver_data) })
+            Some(unsafe { T::borrow(self.as_ref().driver_data.cast()) })
         }
     }

@@ -657,7 +657,7 @@ fn clear_data<T: ForeignOwnable>(&mut self) -> Option<T> {
             let data = Some(
                 // SAFETY: The data is earlier set by us from [`set_data`]. It is safe to take
                 // back the ownership of the data from the foreign interface.
-                unsafe { <T as ForeignOwnable>::from_foreign(self.as_ref().driver_data) },
+                unsafe { <T as ForeignOwnable>::from_foreign(self.as_ref().driver_data.cast()) },
             );
             self.as_mut_ref().driver_data = ptr::null_mut();
             data


Andreas, is your xarray-next branch immmutable ? I can rebase over the
change then.

-- 
viresh

Re: linux-next: build failure after merge of the rust-xarray tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]

Hi Viresh,

On Wed, 30 Apr 2025 16:12:34 +0530 Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 30-04-25, 20:23, Stephen Rothwell wrote:
> > Caused by commit
> > 
> >   a68f46e83747 ("rust: types: add `ForeignOwnable::PointedTo`")
> > 
> > interacting with commit
> > 
> >   254df142ab42 ("rust: cpufreq: Add initial abstractions for cpufreq framework")
> > 
> > from the cpufreq-arm tree.
> > 
> > I don't know how to fix this up, so I have dropped the rust-xarray tree
> > for today.  
> 
> Probably this:
> 
> diff --git a/rust/kernel/cpufreq.rs b/rust/kernel/cpufreq.rs
> index 49246e50f67e..82d20b999e6c 100644
> --- a/rust/kernel/cpufreq.rs
> +++ b/rust/kernel/cpufreq.rs
> @@ -630,7 +630,7 @@ pub fn data<T: ForeignOwnable>(&mut self) -> Option<<T>::Borrowed<'_>> {
>              None
>          } else {
>              // SAFETY: The data is earlier set from [`set_data`].
> -            Some(unsafe { T::borrow(self.as_ref().driver_data) })
> +            Some(unsafe { T::borrow(self.as_ref().driver_data.cast()) })
>          }
>      }
> 
> @@ -657,7 +657,7 @@ fn clear_data<T: ForeignOwnable>(&mut self) -> Option<T> {
>              let data = Some(
>                  // SAFETY: The data is earlier set by us from [`set_data`]. It is safe to take
>                  // back the ownership of the data from the foreign interface.
> -                unsafe { <T as ForeignOwnable>::from_foreign(self.as_ref().driver_data) },
> +                unsafe { <T as ForeignOwnable>::from_foreign(self.as_ref().driver_data.cast()) },
>              );
>              self.as_mut_ref().driver_data = ptr::null_mut();
>              data
> 
> 
> Andreas, is your xarray-next branch immmutable ? I can rebase over the
> change then.

I have applied that as a merge fix up for the rust-xarray tree merge
from today.  (This time running "make rustftmcheck" :-))
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the rust-xarray tree

[Andreas Hindborg]

"Viresh Kumar" <viresh.kumar@linaro.org> writes:

> On 30-04-25, 20:23, Stephen Rothwell wrote:
>> Caused by commit
>>
>>   a68f46e83747 ("rust: types: add `ForeignOwnable::PointedTo`")
>>
>> interacting with commit
>>
>>   254df142ab42 ("rust: cpufreq: Add initial abstractions for cpufreq framework")
>>
>> from the cpufreq-arm tree.
>>
>> I don't know how to fix this up, so I have dropped the rust-xarray tree
>> for today.
>
> Probably this:
>
> diff --git a/rust/kernel/cpufreq.rs b/rust/kernel/cpufreq.rs
> index 49246e50f67e..82d20b999e6c 100644
> --- a/rust/kernel/cpufreq.rs
> +++ b/rust/kernel/cpufreq.rs
> @@ -630,7 +630,7 @@ pub fn data<T: ForeignOwnable>(&mut self) -> Option<<T>::Borrowed<'_>> {
>              None
>          } else {
>              // SAFETY: The data is earlier set from [`set_data`].
> -            Some(unsafe { T::borrow(self.as_ref().driver_data) })
> +            Some(unsafe { T::borrow(self.as_ref().driver_data.cast()) })
>          }
>      }
>
> @@ -657,7 +657,7 @@ fn clear_data<T: ForeignOwnable>(&mut self) -> Option<T> {
>              let data = Some(
>                  // SAFETY: The data is earlier set by us from [`set_data`]. It is safe to take
>                  // back the ownership of the data from the foreign interface.
> -                unsafe { <T as ForeignOwnable>::from_foreign(self.as_ref().driver_data) },
> +                unsafe { <T as ForeignOwnable>::from_foreign(self.as_ref().driver_data.cast()) },
>              );
>              self.as_mut_ref().driver_data = ptr::null_mut();
>              data
>
>
> Andreas, is your xarray-next branch immmutable ? I can rebase over the
> change then.

I might add tags. But I guess now that Stephen carries the merge
resolution, we should be fine? Not sure what the preferred approach is
for this situation.


Best regards,
Andreas Hindborg

Re: linux-next: build failure after merge of the rust-xarray tree

[Viresh Kumar]

On Thu, 1 May 2025 at 15:45, Andreas Hindborg <a.hindborg@kernel.org> wrote:

> I might add tags.

That won't change the SHA for the commits, so I can safely rebase over
your patches.

> But I guess now that Stephen carries the merge resolution, we should be fine?

Yes, that would work as well. I anyway have prepared a branch based on
your's, I will push that anyway to avoid merge resolution.

Thanks.

Re: linux-next: build failure after merge of the rust-xarray tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 407 bytes --]

Hi Viresh,

On Thu, 1 May 2025 15:54:01 +0530 Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On Thu, 1 May 2025 at 15:45, Andreas Hindborg <a.hindborg@kernel.org> wrote:
> 
> > I might add tags.  
> 
> That won't change the SHA for the commits, so I can safely rebase over
> your patches.

Tags like "Acked-by" etc in the commit message will change the SHA.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the rust-xarray tree

[Viresh Kumar]

On 01-05-25, 22:19, Stephen Rothwell wrote:
> Tags like "Acked-by" etc in the commit message will change the SHA.

I misunderstood what he meant earlier, Of course SHA will change with
this.

-- 
viresh

linux-next: build failure after merge of the rust-xarray tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 329 bytes --]

Hi all,

After merging the rust-xarray tree, today's linux-next build (x86_64
allmodconfig) failed like this:


I don't know what caused this, but it is presumably an interaction
between this tree and the mm-unstable and drm-nova trees.

I have dropped the rust-xarray tree for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the rust-xarray tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3161 bytes --]

Hi all,

On Mon, 28 Apr 2025 20:39:43 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the rust-xarray tree, today's linux-next build (x86_64
> allmodconfig) failed like this:

error[E0308]: mismatched types
  --> rust/kernel/auxiliary.rs:76:73
   |
55 | impl<T: Driver + 'static> Adapter<T> {
   |      - found this type parameter
...
76 |                 unsafe { bindings::auxiliary_set_drvdata(adev.as_raw(), data.into_foreign()) };
   |                          -------------------------------                ^^^^^^^^^^^^^^^^^^^ expected `*mut c_void`, found `*mut T`
   |                          |
   |                          arguments to this function are incorrect
   |
   = note: expected raw pointer `*mut c_void`
              found raw pointer `*mut T`
note: function defined here
  --> rust/bindings/bindings_helpers_generated.rs:5:12
   |
5  |     pub fn auxiliary_set_drvdata(adev: *mut auxiliary_device, data: *mut ffi::c_void);
   |            ^^^^^^^^^^^^^^^^^^^^^

error[E0308]: mismatched types
  --> rust/kernel/auxiliary.rs:92:47
   |
55 | impl<T: Driver + 'static> Adapter<T> {
   |      - expected this type parameter
...
92 |         drop(unsafe { KBox::<T>::from_foreign(ptr) });
   |                       ----------------------- ^^^ expected `*mut T`, found `*mut c_void`
   |                       |
   |                       arguments to this function are incorrect
   |
   = note: expected raw pointer `*mut T`
              found raw pointer `*mut c_void`
note: associated function defined here
  --> rust/kernel/types.rs:63:15
   |
63 |     unsafe fn from_foreign(ptr: *mut Self::PointedTo) -> Self;
   |               ^^^^^^^^^^^^

error[E0308]: mismatched types
   --> rust/kernel/miscdevice.rs:256:66
    |
256 |         let device = unsafe { <T::Ptr as ForeignOwnable>::borrow(private) };
    |                               ---------------------------------- ^^^^^^^ expected `*mut <... as ForeignOwnable>::PointedTo`, found `*mut c_void`
    |                               |
    |                               arguments to this function are incorrect
    |
    = note: expected raw pointer `*mut <<T as MiscDevice>::Ptr as ForeignOwnable>::PointedTo`
               found raw pointer `*mut c_void`
    = help: consider constraining the associated type `<<T as MiscDevice>::Ptr as ForeignOwnable>::PointedTo` to `c_void` or calling a method that returns `<<T as MiscDevice>::Ptr as ForeignOwnable>::PointedTo`
    = note: for more information, visit https://doc.rust-lang.org/book/ch19-03-advanced-traits.html
note: associated function defined here
   --> rust/kernel/types.rs:98:15
    |
98  |     unsafe fn borrow<'a>(ptr: *mut Self::PointedTo) -> Self::Borrowed<'a>;
    |               ^^^^^^

error: aborting due to 3 previous errors

For more information about this error, try `rustc --explain E0308`.

> I don't know what caused this, but it is presumably an interaction
> between this tree and the mm-unstable and drm-nova trees.
> 
> I have dropped the rust-xarray tree for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the rust-xarray tree

[Andreas Hindborg]

Hi Stephen,

"Stephen Rothwell" <sfr@canb.auug.org.au> writes:

> Hi all,
>
> After merging the rust-xarray tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
>
> I don't know what caused this, but it is presumably an interaction
> between this tree and the mm-unstable and drm-nova trees.
>
> I have dropped the rust-xarray tree for today.

The diff below should solve the conflict.

Best regards,
Andreas Hindborg


diff --git a/rust/kernel/auxiliary.rs b/rust/kernel/auxiliary.rs
index 5c072960dee0..bc94850ef322 100644
--- a/rust/kernel/auxiliary.rs
+++ b/rust/kernel/auxiliary.rs
@@ -73,7 +73,9 @@ extern "C" fn probe_callback(
                 // Let the `struct auxiliary_device` own a reference of the driver's private data.
                 // SAFETY: By the type invariant `adev.as_raw` returns a valid pointer to a
                 // `struct auxiliary_device`.
-                unsafe { bindings::auxiliary_set_drvdata(adev.as_raw(), data.into_foreign()) };
+                unsafe {
+                    bindings::auxiliary_set_drvdata(adev.as_raw(), data.into_foreign().cast())
+                };
             }
             Err(err) => return Error::to_errno(err),
         }
@@ -89,7 +91,7 @@ extern "C" fn remove_callback(adev: *mut bindings::auxiliary_device) {
         // SAFETY: `remove_callback` is only ever called after a successful call to
         // `probe_callback`, hence it's guaranteed that `ptr` points to a valid and initialized
         // `KBox<T>` pointer created through `KBox::into_foreign`.
-        drop(unsafe { KBox::<T>::from_foreign(ptr) });
+        drop(unsafe { KBox::<T>::from_foreign(ptr.cast()) });
     }
 }
 
diff --git a/rust/kernel/miscdevice.rs b/rust/kernel/miscdevice.rs
index a4bc6016f037..f33c13c3ff97 100644
--- a/rust/kernel/miscdevice.rs
+++ b/rust/kernel/miscdevice.rs
@@ -253,7 +253,7 @@ impl<T: MiscDevice> MiscdeviceVTable<T> {
         // SAFETY: This is a Rust Miscdevice, so we call `into_foreign` in `open` and
         // `from_foreign` in `release`, and `fops_mmap` is guaranteed to be called between those
         // two operations.
-        let device = unsafe { <T::Ptr as ForeignOwnable>::borrow(private) };
+        let device = unsafe { <T::Ptr as ForeignOwnable>::borrow(private.cast()) };
         // SAFETY: The caller provides a vma that is undergoing initial VMA setup.
         let area = unsafe { VmaNew::from_raw(vma) };
         // SAFETY:

Re: linux-next: build failure after merge of the rust-xarray tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 248 bytes --]

Hi Andreas,

On Mon, 28 Apr 2025 14:25:50 +0200 Andreas Hindborg <a.hindborg@kernel.org> wrote:
>
> The diff below should solve the conflict.

I have applied that from today and it all builds fine.  Thanks.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the rust-xarray tree

[Miguel Ojeda]

On Tue, Apr 29, 2025 at 9:44 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I have applied that from today and it all builds fine.  Thanks.

It seems a couple spaces got removed when applying, so `rustfmtcheck`
fails in next-20250429.

Would it be possible to run `make ..... rustfmt` as a merge/build step?

Thanks!

Cheers,
Miguel

Re: linux-next: build failure after merge of the rust-xarray tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

Hi Miguel,

On Tue, 29 Apr 2025 17:33:29 +0200 Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Tue, Apr 29, 2025 at 9:44 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > I have applied that from today and it all builds fine.  Thanks.  
> 
> It seems a couple spaces got removed when applying, so `rustfmtcheck`
> fails in next-20250429.
> 
> Would it be possible to run `make ..... rustfmt` as a merge/build step?

I will try to remember to run 'make rustfmtcheck' whenever I do a merge
fix up on rust code.

(hmmm, no leading tab characters - who knew :-))
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the rust-xarray tree

[Miguel Ojeda]

On Thu, May 1, 2025 at 10:32 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I will try to remember to run 'make rustfmtcheck' whenever I do a merge
> fix up on rust code.
>
> (hmmm, no leading tab characters - who knew :-))

Thanks! :)

(If you run `make rustfmt`, i.e. without the `check` at the end, it
will apply the changes directly).

Cheers,
Miguel