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

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

[Stephen Rothwell]

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

Hi all,

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

error[E0308]: mismatched types
   --> drivers/gpu/drm/drm_panic_qr.rs:961:60
    |
961 |         let url_cstr: &CStr = unsafe { CStr::from_char_ptr(url) };
    |                                        ------------------- ^^^ expected `*const u8`, found `*const i8`
    |                                        |
    |                                        arguments to this function are incorrect
    |
    = note: expected raw pointer `*const u8`
               found raw pointer `*const i8`
note: associated function defined here
   --> rust/kernel/str.rs:187:19
    |
187 |     pub unsafe fn from_char_ptr<'a>(ptr: *const crate::ffi::c_char) -> &'a Self {
    |                   ^^^^^^^^^^^^^

error: aborting due to 1 previous error

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

Caused by commit

  e721cd7570b2 ("rust: map `long` to `isize` and `char` to `u8`")

I have used the rust tree from next-20241213 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 tree

[Miguel Ojeda]

On Mon, Dec 16, 2024 at 6:25 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the rust tree, today's linux-next build (x86_64
> allmodconfig) failed like this:

Apologies, fixed now, thanks!

Jocelyn: we are performing the remapping via the new `ffi` crate in
this cycle. I had to add a change to `drm_panic_qr.rs` to take
`c_char` instead of `i8` in `drm_panic_qr_generate`, so that types
match both before and after the remapping. I think this signature
would have been better anyway, but please let me know if you disagree!

    https://github.com/Rust-for-Linux/linux/commit/e1157aee5f038c2c91af269cd48653133e99f3fb

(Diff copied below too)

Thanks!

Cheers,
Miguel

[1]

diff --git a/drivers/gpu/drm/drm_panic_qr.rs b/drivers/gpu/drm/drm_panic_qr.rs
index ef2d490965ba..bcf248f69252 100644
--- a/drivers/gpu/drm/drm_panic_qr.rs
+++ b/drivers/gpu/drm/drm_panic_qr.rs
@@ -931,7 +931,7 @@ fn draw_all(&mut self, data: impl Iterator<Item = u8>) {
 /// They must remain valid for the duration of the function call.
 #[no_mangle]
 pub unsafe extern "C" fn drm_panic_qr_generate(
-    url: *const i8,
+    url: *const kernel::ffi::c_char,
     data: *mut u8,
     data_len: usize,
     data_size: usize,

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

[Jocelyn Falempe]

On 16/12/2024 11:31, Miguel Ojeda wrote:
> On Mon, Dec 16, 2024 at 6:25 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> After merging the rust tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
> 
> Apologies, fixed now, thanks!
> 
> Jocelyn: we are performing the remapping via the new `ffi` crate in
> this cycle. I had to add a change to `drm_panic_qr.rs` to take
> `c_char` instead of `i8` in `drm_panic_qr_generate`, so that types
> match both before and after the remapping. I think this signature
> would have been better anyway, but please let me know if you disagree!
> 
>      https://github.com/Rust-for-Linux/linux/commit/e1157aee5f038c2c91af269cd48653133e99f3fb
> 
> (Diff copied below too)

Yes, I'm fine with that change, thanks for the fix!

Best regards,

-- 

Jocelyn

> 
> Thanks!
> 
> Cheers,
> Miguel
> 
> [1]
> 
> diff --git a/drivers/gpu/drm/drm_panic_qr.rs b/drivers/gpu/drm/drm_panic_qr.rs
> index ef2d490965ba..bcf248f69252 100644
> --- a/drivers/gpu/drm/drm_panic_qr.rs
> +++ b/drivers/gpu/drm/drm_panic_qr.rs
> @@ -931,7 +931,7 @@ fn draw_all(&mut self, data: impl Iterator<Item = u8>) {
>   /// They must remain valid for the duration of the function call.
>   #[no_mangle]
>   pub unsafe extern "C" fn drm_panic_qr_generate(
> -    url: *const i8,
> +    url: *const kernel::ffi::c_char,
>       data: *mut u8,
>       data_len: usize,
>       data_size: usize,
> 

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

[Miguel Ojeda]

On Mon, Dec 16, 2024 at 11:59 AM Jocelyn Falempe <jfalempe@redhat.com> wrote:
>
> Yes, I'm fine with that change, thanks for the fix!

Thanks for the quick reply!

May I transform your reply into an Acked-by?

By the way, if you want it as an independent fix that can go to stable
too, I am happy to split it into its own (previous) commit and tag it
as such. I am not sure if it should be considered a fix, though, since
one could argue nothing is "broken" (apart from the type not being the
optimal choice).

I am also happy to split it without marking it as a fix, in case you
may want to backport it independently as a prerequisite at some point
or similar.

Cheers,
Miguel

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

[Jocelyn Falempe]

On 16/12/2024 17:24, Miguel Ojeda wrote:
> On Mon, Dec 16, 2024 at 11:59 AM Jocelyn Falempe <jfalempe@redhat.com> wrote:
>>
>> Yes, I'm fine with that change, thanks for the fix!
> 
> Thanks for the quick reply!
> 
> May I transform your reply into an Acked-by?

Sure, please do.
> 
> By the way, if you want it as an independent fix that can go to stable
> too, I am happy to split it into its own (previous) commit and tag it
> as such. I am not sure if it should be considered a fix, though, since
> one could argue nothing is "broken" (apart from the type not being the
> optimal choice).

Don't spend more time on this trivial fix, it probably won't need to be 
backported.
> 
> I am also happy to split it without marking it as a fix, in case you
> may want to backport it independently as a prerequisite at some point
> or similar.
> 
> Cheers,
> Miguel
> 

Thanks,

--

Jocelyn

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

[Stephen Rothwell]

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

Hi all,

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

error[E0277]: the trait bound `u32: From<DmaTrfCmdSize>` is not satisfied
   --> drivers/gpu/nova-core/regs/macros.rs:310:26
    |
310 |               let value = (u32::from(value) << SHIFT) & MASK;
    |                            ^^^ the trait `From<DmaTrfCmdSize>` is not implemented for `u32`
    |
   ::: drivers/gpu/nova-core/regs.rs:240:1
    |
240 | / register!(NV_PFALCON_FALCON_DMATRFCMD @ +0x00000118 {
241 | |     0:0     full as bool;
242 | |     1:1     idle as bool;
243 | |     3:2     sec as u8;
...   |
248 | |     16:16   set_dmtag as u8;
249 | | });
    | |__- in this macro invocation
    |
    = help: the following other types implement trait `From<T>`:
              `u32` implements `From<Char>`
              `u32` implements `From<CpuId>`
              `u32` implements `From<Ipv4Addr>`
              `u32` implements `From<NV_FUSE_OPT_FPF_GSP_UCODE1_VERSION>`
              `u32` implements `From<NV_FUSE_OPT_FPF_NVDEC_UCODE1_VERSION>`
              `u32` implements `From<NV_FUSE_OPT_FPF_SEC2_UCODE1_VERSION>`
              `u32` implements `From<NV_PBUS_SW_SCRATCH_0E>`
              `u32` implements `From<NV_PDISP_VGA_WORKSPACE_BASE>`
            and 41 others
    = note: this error originates in the macro `register` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `u32: From<FalconCoreRev>` is not satisfied
   --> drivers/gpu/nova-core/regs/macros.rs:310:26
    |
310 |               let value = (u32::from(value) << SHIFT) & MASK;
    |                            ^^^ the trait `From<FalconCoreRev>` is not implemented for `u32`
    |
   ::: drivers/gpu/nova-core/regs.rs:259:1
    |
259 | / register!(NV_PFALCON_FALCON_HWCFG1 @ +0x0000012c {
260 | |     3:0     core_rev as u8 ?=> FalconCoreRev, "Core revision";
261 | |     5:4     security_model as u8 ?=> FalconSecurityModel, "Security model";
262 | |     7:6     core_rev_subversion as u8 ?=> FalconCoreRevSubversion, "Core revision subversion";
263 | | });
    | |__- in this macro invocation
    |
    = help: the following other types implement trait `From<T>`:
              `u32` implements `From<Char>`
              `u32` implements `From<CpuId>`
              `u32` implements `From<Ipv4Addr>`
              `u32` implements `From<NV_FUSE_OPT_FPF_GSP_UCODE1_VERSION>`
              `u32` implements `From<NV_FUSE_OPT_FPF_NVDEC_UCODE1_VERSION>`
              `u32` implements `From<NV_FUSE_OPT_FPF_SEC2_UCODE1_VERSION>`
              `u32` implements `From<NV_PBUS_SW_SCRATCH_0E>`
              `u32` implements `From<NV_PDISP_VGA_WORKSPACE_BASE>`
            and 41 others
    = note: this error originates in the macro `register` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `u32: From<FalconSecurityModel>` is not satisfied
   --> drivers/gpu/nova-core/regs/macros.rs:310:26
    |
310 |               let value = (u32::from(value) << SHIFT) & MASK;
    |                            ^^^ the trait `From<FalconSecurityModel>` is not implemented for `u32`
    |
   ::: drivers/gpu/nova-core/regs.rs:259:1
    |
259 | / register!(NV_PFALCON_FALCON_HWCFG1 @ +0x0000012c {
260 | |     3:0     core_rev as u8 ?=> FalconCoreRev, "Core revision";
261 | |     5:4     security_model as u8 ?=> FalconSecurityModel, "Security model";
262 | |     7:6     core_rev_subversion as u8 ?=> FalconCoreRevSubversion, "Core revision subversion";
263 | | });
    | |__- in this macro invocation
    |
    = help: the following other types implement trait `From<T>`:
              `u32` implements `From<Char>`
              `u32` implements `From<CpuId>`
              `u32` implements `From<Ipv4Addr>`
              `u32` implements `From<NV_FUSE_OPT_FPF_GSP_UCODE1_VERSION>`
              `u32` implements `From<NV_FUSE_OPT_FPF_NVDEC_UCODE1_VERSION>`
              `u32` implements `From<NV_FUSE_OPT_FPF_SEC2_UCODE1_VERSION>`
              `u32` implements `From<NV_PBUS_SW_SCRATCH_0E>`
              `u32` implements `From<NV_PDISP_VGA_WORKSPACE_BASE>`
            and 41 others
    = note: this error originates in the macro `register` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `u32: From<FalconCoreRevSubversion>` is not satisfied
   --> drivers/gpu/nova-core/regs/macros.rs:310:26
    |
310 |               let value = (u32::from(value) << SHIFT) & MASK;
    |                            ^^^ the trait `From<FalconCoreRevSubversion>` is not implemented for `u32`
    |
   ::: drivers/gpu/nova-core/regs.rs:259:1
    |
259 | / register!(NV_PFALCON_FALCON_HWCFG1 @ +0x0000012c {
260 | |     3:0     core_rev as u8 ?=> FalconCoreRev, "Core revision";
261 | |     5:4     security_model as u8 ?=> FalconSecurityModel, "Security model";
262 | |     7:6     core_rev_subversion as u8 ?=> FalconCoreRevSubversion, "Core revision subversion";
263 | | });
    | |__- in this macro invocation
    |
    = help: the following other types implement trait `From<T>`:
              `u32` implements `From<Char>`
              `u32` implements `From<CpuId>`
              `u32` implements `From<Ipv4Addr>`
              `u32` implements `From<NV_FUSE_OPT_FPF_GSP_UCODE1_VERSION>`
              `u32` implements `From<NV_FUSE_OPT_FPF_NVDEC_UCODE1_VERSION>`
              `u32` implements `From<NV_FUSE_OPT_FPF_SEC2_UCODE1_VERSION>`
              `u32` implements `From<NV_PBUS_SW_SCRATCH_0E>`
              `u32` implements `From<NV_PDISP_VGA_WORKSPACE_BASE>`
            and 41 others
    = note: this error originates in the macro `register` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `u32: From<FalconFbifTarget>` is not satisfied
   --> drivers/gpu/nova-core/regs/macros.rs:310:26
    |
310 |               let value = (u32::from(value) << SHIFT) & MASK;
    |                            ^^^ the trait `From<FalconFbifTarget>` is not implemented for `u32`
    |
   ::: drivers/gpu/nova-core/regs.rs:276:1
    |
276 | / register!(NV_PFALCON_FBIF_TRANSCFG @ +0x00000600 {
277 | |     1:0     target as u8 ?=> FalconFbifTarget;
278 | |     2:2     mem_type as bool => FalconFbifMemType;
279 | | });
    | |__- in this macro invocation
    |
    = help: the following other types implement trait `From<T>`:
              `u32` implements `From<Char>`
              `u32` implements `From<CpuId>`
              `u32` implements `From<Ipv4Addr>`
              `u32` implements `From<NV_FUSE_OPT_FPF_GSP_UCODE1_VERSION>`
              `u32` implements `From<NV_FUSE_OPT_FPF_NVDEC_UCODE1_VERSION>`
              `u32` implements `From<NV_FUSE_OPT_FPF_SEC2_UCODE1_VERSION>`
              `u32` implements `From<NV_PBUS_SW_SCRATCH_0E>`
              `u32` implements `From<NV_PDISP_VGA_WORKSPACE_BASE>`
            and 41 others
    = note: this error originates in the macro `register` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `u32: From<FalconFbifMemType>` is not satisfied
   --> drivers/gpu/nova-core/regs/macros.rs:310:26
    |
310 |               let value = (u32::from(value) << SHIFT) & MASK;
    |                            ^^^ the trait `From<FalconFbifMemType>` is not implemented for `u32`
    |
   ::: drivers/gpu/nova-core/regs.rs:276:1
    |
276 | / register!(NV_PFALCON_FBIF_TRANSCFG @ +0x00000600 {
277 | |     1:0     target as u8 ?=> FalconFbifTarget;
278 | |     2:2     mem_type as bool => FalconFbifMemType;
279 | | });
    | |__- in this macro invocation
    |
    = help: the following other types implement trait `From<T>`:
              `u32` implements `From<Char>`
              `u32` implements `From<CpuId>`
              `u32` implements `From<Ipv4Addr>`
              `u32` implements `From<NV_FUSE_OPT_FPF_GSP_UCODE1_VERSION>`
              `u32` implements `From<NV_FUSE_OPT_FPF_NVDEC_UCODE1_VERSION>`
              `u32` implements `From<NV_FUSE_OPT_FPF_SEC2_UCODE1_VERSION>`
              `u32` implements `From<NV_PBUS_SW_SCRATCH_0E>`
              `u32` implements `From<NV_PDISP_VGA_WORKSPACE_BASE>`
            and 41 others
    = note: this error originates in the macro `register` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `u32: From<FalconModSelAlgo>` is not satisfied
   --> drivers/gpu/nova-core/regs/macros.rs:310:26
    |
310 |               let value = (u32::from(value) << SHIFT) & MASK;
    |                            ^^^ the trait `From<FalconModSelAlgo>` is not implemented for `u32`
    |
   ::: drivers/gpu/nova-core/regs.rs:285:1
    |
285 | / register!(NV_PFALCON2_FALCON_MOD_SEL @ +0x00001180 {
286 | |     7:0     algo as u8 ?=> FalconModSelAlgo;
287 | | });
    | |__- in this macro invocation
    |
    = help: the following other types implement trait `From<T>`:
              `u32` implements `From<Char>`
              `u32` implements `From<CpuId>`
              `u32` implements `From<Ipv4Addr>`
              `u32` implements `From<NV_FUSE_OPT_FPF_GSP_UCODE1_VERSION>`
              `u32` implements `From<NV_FUSE_OPT_FPF_NVDEC_UCODE1_VERSION>`
              `u32` implements `From<NV_FUSE_OPT_FPF_SEC2_UCODE1_VERSION>`
              `u32` implements `From<NV_PBUS_SW_SCRATCH_0E>`
              `u32` implements `From<NV_PDISP_VGA_WORKSPACE_BASE>`
            and 41 others
    = note: this error originates in the macro `register` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `u32: From<PeregrineCoreSelect>` is not satisfied
   --> drivers/gpu/nova-core/regs/macros.rs:310:26
    |
310 |               let value = (u32::from(value) << SHIFT) & MASK;
    |                            ^^^ the trait `From<PeregrineCoreSelect>` is not implemented for `u32`
    |
   ::: drivers/gpu/nova-core/regs.rs:304:1
    |
304 | / register!(NV_PRISCV_RISCV_BCR_CTRL @ +0x00001668 {
305 | |     0:0     valid as bool;
306 | |     4:4     core_select as bool => PeregrineCoreSelect;
307 | |     8:8     br_fetch as bool;
308 | | });
    | |__- in this macro invocation
    |
    = help: the following other types implement trait `From<T>`:
              `u32` implements `From<Char>`
              `u32` implements `From<CpuId>`
              `u32` implements `From<Ipv4Addr>`
              `u32` implements `From<NV_FUSE_OPT_FPF_GSP_UCODE1_VERSION>`
              `u32` implements `From<NV_FUSE_OPT_FPF_NVDEC_UCODE1_VERSION>`
              `u32` implements `From<NV_FUSE_OPT_FPF_SEC2_UCODE1_VERSION>`
              `u32` implements `From<NV_PBUS_SW_SCRATCH_0E>`
              `u32` implements `From<NV_PDISP_VGA_WORKSPACE_BASE>`
            and 41 others
    = note: this error originates in the macro `register` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0599]: no method named `as_nanos` found for struct `Delta` in the current scope
  --> drivers/gpu/nova-core/util.rs:45:33
   |
45 |         if start_time.elapsed().as_nanos() > timeout.as_nanos() as i64 {
   |                                 ^^^^^^^^ method not found in `Delta`

error: aborting due to 9 previous errors

Some errors have detailed explanations: E0277, E0599.
For more information about an error, try `rustc --explain E0277`.

Presumably caused by commit

  b7c8d7a8d251 ("rust: enable `clippy::cast_lossless` lint")

interacting with some changes in the drm-nova tree
(https://gitlab.freedesktop.org/drm/nova.git#nova-next).

A suggested merge resolution would be appreciated.

I have used the rust tree from next-20250620 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 tree

[Miguel Ojeda]

On Tue, Jun 24, 2025 at 9:31 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> error[E0277]: the trait bound `u32: From<DmaTrfCmdSize>` is not satisfied

> error[E0599]: no method named `as_nanos` found for struct `Delta` in the current scope

> Presumably caused by commit
>
>   b7c8d7a8d251 ("rust: enable `clippy::cast_lossless` lint")

The first error, yes -- the `register!` macro was changed to use
`u32::from()` to avoid an `as` cast in that commit, and while the cast
is OK converting the new `enum`s like `FalconCoreRev`, `from()`
isn't`, so we would need to implement `From` explicitly -- Cc'ing
Danilo, Alexandre, Lyude.

The second error is due to 2ed94606a0fe ("rust: time: Rename Delta's
methods from as_* to into_*"). However, I am not sure why that patch
was applied since we were discussing the naming of those methods
elsewhere -- Cc'ing Andreas and Tomonori.

Nevertheless, even if 2ed94606a0fe is dropped (or the conflict solved
by a trivial rename), there will be another nearby conflict after that
one, due the addition of the `ClockSource` generic parameter, so that
needs a change too, e.g. using `Monotonic` explicitly if that is
correct or allowing the caller to pass a `ClockSource`.

By the way, I also noticed a Clippy warning in `nova-next` (on its
own, i.e. without merging anything) -- please see below [1].

I hope this helps.

Cheers,
Miguel

[1]

    error: mutable borrow from immutable input(s)
       --> rust/kernel/dma.rs:297:78
        |
    297 |     pub unsafe fn as_slice_mut(&self, offset: usize, count:
usize) -> Result<&mut [T]> {
        |
                ^^^^^^^^
        |
    note: immutable borrow here
       --> rust/kernel/dma.rs:297:32
        |
    297 |     pub unsafe fn as_slice_mut(&self, offset: usize, count:
usize) -> Result<&mut [T]> {
        |                                ^^^^^
        = help: for further information visit
https://rust-lang.github.io/rust-clippy/master/index.html#mut_from_ref
        = note: `-D clippy::mut-from-ref` implied by `-D warnings`
        = help: to override `-D warnings` add `#[allow(clippy::mut_from_ref)]`

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

[Danilo Krummrich]

On Tue, Jun 24, 2025 at 12:31:52PM +0200, Miguel Ojeda wrote:
> By the way, I also noticed a Clippy warning in `nova-next` (on its
> own, i.e. without merging anything) -- please see below [1].

How do I get this warning to trigger? I did run my usual tests with rustc 1.78
and 1.87.

> [1]
> 
>     error: mutable borrow from immutable input(s)
>        --> rust/kernel/dma.rs:297:78
>         |
>     297 |     pub unsafe fn as_slice_mut(&self, offset: usize, count:
> usize) -> Result<&mut [T]> {

I think the method isn't wrong, it is unsafe and the safety requirement
explicitly covers this part.

However, we should consider changing it anyways.

>         |
>                 ^^^^^^^^
>         |
>     note: immutable borrow here
>        --> rust/kernel/dma.rs:297:32
>         |
>     297 |     pub unsafe fn as_slice_mut(&self, offset: usize, count:
> usize) -> Result<&mut [T]> {
>         |                                ^^^^^
>         = help: for further information visit
> https://rust-lang.github.io/rust-clippy/master/index.html#mut_from_ref
>         = note: `-D clippy::mut-from-ref` implied by `-D warnings`
>         = help: to override `-D warnings` add `#[allow(clippy::mut_from_ref)]`

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

[Miguel Ojeda]

On Tue, Jun 24, 2025 at 1:12 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> How do I get this warning to trigger? I did run my usual tests with rustc 1.78
> and 1.87.

Ah, sorry, my bad -- it is in the upcoming 1.88, which I was using for
something else.

You can test it with:

    RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup update stable

Cheers,
Miguel

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

[Danilo Krummrich]

On Tue, Jun 24, 2025 at 12:31:52PM +0200, Miguel Ojeda wrote:
> On Tue, Jun 24, 2025 at 9:31 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > error[E0277]: the trait bound `u32: From<DmaTrfCmdSize>` is not satisfied
> 
> > error[E0599]: no method named `as_nanos` found for struct `Delta` in the current scope
> 
> > Presumably caused by commit
> >
> >   b7c8d7a8d251 ("rust: enable `clippy::cast_lossless` lint")
> 
> The first error, yes -- the `register!` macro was changed to use
> `u32::from()` to avoid an `as` cast in that commit, and while the cast
> is OK converting the new `enum`s like `FalconCoreRev`, `from()`
> isn't`, so we would need to implement `From` explicitly -- Cc'ing
> Danilo, Alexandre, Lyude.

It's a bit annoying to implement From explicitly for all of them, but it seems
to be the correct thing to do.

nova-next also contains a couple of cases where the introduction of
`cast_lossless` causes warnings.

I can implement the From traits and fix up the warnings caused by enabling
`cast_lossless` in my tree with subsequent patches, such that we do not have to
carry all this as merge resolution.

- Danilo

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

[Alexandre Courbot]

On Tue Jun 24, 2025 at 9:00 PM JST, Danilo Krummrich wrote:
> On Tue, Jun 24, 2025 at 12:31:52PM +0200, Miguel Ojeda wrote:
>> On Tue, Jun 24, 2025 at 9:31 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> >
>> > error[E0277]: the trait bound `u32: From<DmaTrfCmdSize>` is not satisfied
>> 
>> > error[E0599]: no method named `as_nanos` found for struct `Delta` in the current scope
>> 
>> > Presumably caused by commit
>> >
>> >   b7c8d7a8d251 ("rust: enable `clippy::cast_lossless` lint")
>> 
>> The first error, yes -- the `register!` macro was changed to use
>> `u32::from()` to avoid an `as` cast in that commit, and while the cast
>> is OK converting the new `enum`s like `FalconCoreRev`, `from()`
>> isn't`, so we would need to implement `From` explicitly -- Cc'ing
>> Danilo, Alexandre, Lyude.
>
> It's a bit annoying to implement From explicitly for all of them, but it seems
> to be the correct thing to do.

This might be something `FromPrimitive` will help with eventually, but
in the meantime I agree having explicit implementations is a bit
cumbersome.

What I don't understand is why these `as` are problematic - a type like
`FalconCoreRev` is `repr(u8)`, so the cast cannot be lossy. I think this
is the case for all such instances using the register!() macro.

>
> nova-next also contains a couple of cases where the introduction of
> `cast_lossless` causes warnings.
>
> I can implement the From traits and fix up the warnings caused by enabling
> `cast_lossless` in my tree with subsequent patches, such that we do not have to
> carry all this as merge resolution.

Let me know if you want me to take care of that.

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

[Tamir Duberstein]

On Tue, Jun 24, 2025 at 5:14 AM Alexandre Courbot <acourbot@nvidia.com> wrote:
>
> On Tue Jun 24, 2025 at 9:00 PM JST, Danilo Krummrich wrote:
> > On Tue, Jun 24, 2025 at 12:31:52PM +0200, Miguel Ojeda wrote:
> >> On Tue, Jun 24, 2025 at 9:31 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >> >
> >> > error[E0277]: the trait bound `u32: From<DmaTrfCmdSize>` is not satisfied
> >>
> >> > error[E0599]: no method named `as_nanos` found for struct `Delta` in the current scope
> >>
> >> > Presumably caused by commit
> >> >
> >> >   b7c8d7a8d251 ("rust: enable `clippy::cast_lossless` lint")
> >>
> >> The first error, yes -- the `register!` macro was changed to use
> >> `u32::from()` to avoid an `as` cast in that commit, and while the cast
> >> is OK converting the new `enum`s like `FalconCoreRev`, `from()`
> >> isn't`, so we would need to implement `From` explicitly -- Cc'ing
> >> Danilo, Alexandre, Lyude.
> >
> > It's a bit annoying to implement From explicitly for all of them, but it seems
> > to be the correct thing to do.
>
> This might be something `FromPrimitive` will help with eventually, but
> in the meantime I agree having explicit implementations is a bit
> cumbersome.
>
> What I don't understand is why these `as` are problematic - a type like
> `FalconCoreRev` is `repr(u8)`, so the cast cannot be lossy. I think this
> is the case for all such instances using the register!() macro.

The use of `as` is problematic because it disempowers the compiler
from checking that the cast is not lossy. In other words, it is of
course fine in the case of a `repr(u8)` enum, but if the type changes
in a way that causes a lossy conversion, the compiler will not warn
you.

>
> >
> > nova-next also contains a couple of cases where the introduction of
> > `cast_lossless` causes warnings.
> >
> > I can implement the From traits and fix up the warnings caused by enabling
> > `cast_lossless` in my tree with subsequent patches, such that we do not have to
> > carry all this as merge resolution.
>
> Let me know if you want me to take care of that.

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

[Alexandre Courbot]

On Tue Jun 24, 2025 at 9:16 PM JST, Tamir Duberstein wrote:
> On Tue, Jun 24, 2025 at 5:14 AM Alexandre Courbot <acourbot@nvidia.com> wrote:
>>
>> On Tue Jun 24, 2025 at 9:00 PM JST, Danilo Krummrich wrote:
>> > On Tue, Jun 24, 2025 at 12:31:52PM +0200, Miguel Ojeda wrote:
>> >> On Tue, Jun 24, 2025 at 9:31 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> >> >
>> >> > error[E0277]: the trait bound `u32: From<DmaTrfCmdSize>` is not satisfied
>> >>
>> >> > error[E0599]: no method named `as_nanos` found for struct `Delta` in the current scope
>> >>
>> >> > Presumably caused by commit
>> >> >
>> >> >   b7c8d7a8d251 ("rust: enable `clippy::cast_lossless` lint")
>> >>
>> >> The first error, yes -- the `register!` macro was changed to use
>> >> `u32::from()` to avoid an `as` cast in that commit, and while the cast
>> >> is OK converting the new `enum`s like `FalconCoreRev`, `from()`
>> >> isn't`, so we would need to implement `From` explicitly -- Cc'ing
>> >> Danilo, Alexandre, Lyude.
>> >
>> > It's a bit annoying to implement From explicitly for all of them, but it seems
>> > to be the correct thing to do.
>>
>> This might be something `FromPrimitive` will help with eventually, but
>> in the meantime I agree having explicit implementations is a bit
>> cumbersome.
>>
>> What I don't understand is why these `as` are problematic - a type like
>> `FalconCoreRev` is `repr(u8)`, so the cast cannot be lossy. I think this
>> is the case for all such instances using the register!() macro.
>
> The use of `as` is problematic because it disempowers the compiler
> from checking that the cast is not lossy. In other words, it is of
> course fine in the case of a `repr(u8)` enum, but if the type changes
> in a way that causes a lossy conversion, the compiler will not warn
> you.

I understand and agree with this, but why doesn't the linter limit
itself to such lossy cases (e.g. `u64 as u32`) and let the harmless ones
be?

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

[Tamir Duberstein]

On Tue, Jun 24, 2025 at 5:24 AM Alexandre Courbot <acourbot@nvidia.com> wrote:
>
> On Tue Jun 24, 2025 at 9:16 PM JST, Tamir Duberstein wrote:
> > On Tue, Jun 24, 2025 at 5:14 AM Alexandre Courbot <acourbot@nvidia.com> wrote:
> >>
> >> On Tue Jun 24, 2025 at 9:00 PM JST, Danilo Krummrich wrote:
> >> > On Tue, Jun 24, 2025 at 12:31:52PM +0200, Miguel Ojeda wrote:
> >> >> On Tue, Jun 24, 2025 at 9:31 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >> >> >
> >> >> > error[E0277]: the trait bound `u32: From<DmaTrfCmdSize>` is not satisfied
> >> >>
> >> >> > error[E0599]: no method named `as_nanos` found for struct `Delta` in the current scope
> >> >>
> >> >> > Presumably caused by commit
> >> >> >
> >> >> >   b7c8d7a8d251 ("rust: enable `clippy::cast_lossless` lint")
> >> >>
> >> >> The first error, yes -- the `register!` macro was changed to use
> >> >> `u32::from()` to avoid an `as` cast in that commit, and while the cast
> >> >> is OK converting the new `enum`s like `FalconCoreRev`, `from()`
> >> >> isn't`, so we would need to implement `From` explicitly -- Cc'ing
> >> >> Danilo, Alexandre, Lyude.
> >> >
> >> > It's a bit annoying to implement From explicitly for all of them, but it seems
> >> > to be the correct thing to do.
> >>
> >> This might be something `FromPrimitive` will help with eventually, but
> >> in the meantime I agree having explicit implementations is a bit
> >> cumbersome.
> >>
> >> What I don't understand is why these `as` are problematic - a type like
> >> `FalconCoreRev` is `repr(u8)`, so the cast cannot be lossy. I think this
> >> is the case for all such instances using the register!() macro.
> >
> > The use of `as` is problematic because it disempowers the compiler
> > from checking that the cast is not lossy. In other words, it is of
> > course fine in the case of a `repr(u8)` enum, but if the type changes
> > in a way that causes a lossy conversion, the compiler will not warn
> > you.
>
> I understand and agree with this, but why doesn't the linter limit
> itself to such lossy cases (e.g. `u64 as u32`) and let the harmless ones
> be?

Ah, that's a different lint. They are all explained in the docs
probably better than I can:

https://rust-lang.github.io/rust-clippy/master/index.html#cast_lossless
https://rust-lang.github.io/rust-clippy/master/index.html#cast_possible_truncation
https://rust-lang.github.io/rust-clippy/master/index.html#cast_possible_wrap
https://rust-lang.github.io/rust-clippy/master/index.html#cast_sign_loss

They are all allow-by-default though, because it is expected that
*sometimes* you do want to do the lossy thing and there's no other way
to express that.

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

[Miguel Ojeda]

On Tue, Jun 24, 2025 at 2:00 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> It's a bit annoying to implement From explicitly for all of them, but it seems
> to be the correct thing to do.

Yeah, agreed.

> I can implement the From traits and fix up the warnings caused by enabling
> `cast_lossless` in my tree with subsequent patches, such that we do not have to
> carry all this as merge resolution.

That would be great, thanks.

Cheers,
Miguel

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

[Stephen Rothwell]

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

Hi all,

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

x86_64-linux-gnu-ld: vmlinux.o: in function `kernel::alloc::kvec::tests::kunit_rust_wrapper_test_kvec_retain':
(.text+0x1bd7194): undefined reference to `kunit_unary_assert_format'
x86_64-linux-gnu-ld: (.text+0x1bd71a1): undefined reference to `__kunit_do_failed_assertion'
x86_64-linux-gnu-ld: (.text+0x1bd71ae): undefined reference to `__kunit_abort'
x86_64-linux-gnu-ld: vmlinux.o: in function `kernel::kunit::tests::kunit_rust_wrapper_rust_test_kunit_in_kunit_test':
(.text+0x1bd75eb): undefined reference to `kunit_unary_assert_format'
x86_64-linux-gnu-ld: (.text+0x1bd75f8): undefined reference to `__kunit_do_failed_assertion'
x86_64-linux-gnu-ld: (.text+0x1bd7605): undefined reference to `__kunit_abort'
x86_64-linux-gnu-ld: vmlinux.o: in function `kernel::str::tests::kunit_rust_wrapper_test_cstr_to_str':
(.text+0x1bd7e01): undefined reference to `kunit_unary_assert_format'
x86_64-linux-gnu-ld: (.text+0x1bd7e0e): undefined reference to `__kunit_do_failed_assertion'
x86_64-linux-gnu-ld: (.text+0x1bd7e1b): undefined reference to `__kunit_abort'
x86_64-linux-gnu-ld: vmlinux.o: in function `kernel::str::tests::kunit_rust_wrapper_test_cstr_to_str_invalid_utf8':
(.text+0x1bd81a0): undefined reference to `kunit_unary_assert_format'
x86_64-linux-gnu-ld: (.text+0x1bd81ad): undefined reference to `__kunit_do_failed_assertion'
x86_64-linux-gnu-ld: (.text+0x1bd81ba): undefined reference to `__kunit_abort'
x86_64-linux-gnu-ld: vmlinux.o: in function `kernel::str::tests::kunit_rust_wrapper_test_cstr_display':
(.text+0x1bd9728): undefined reference to `kunit_unary_assert_format'
x86_64-linux-gnu-ld: (.text+0x1bd9735): undefined reference to `__kunit_do_failed_assertion'
x86_64-linux-gnu-ld: (.text+0x1bd9742): undefined reference to `__kunit_abort'
x86_64-linux-gnu-ld: vmlinux.o: in function `kernel::str::tests::kunit_rust_wrapper_test_cstr_display_all_bytes':
(.text+0x1bda03c): undefined reference to `kunit_unary_assert_format'
x86_64-linux-gnu-ld: (.text+0x1bda049): undefined reference to `__kunit_do_failed_assertion'
x86_64-linux-gnu-ld: (.text+0x1bda056): undefined reference to `__kunit_abort'
x86_64-linux-gnu-ld: vmlinux.o: in function `kernel::str::tests::kunit_rust_wrapper_test_cstr_debug':
(.text+0x1bdb598): undefined reference to `kunit_unary_assert_format'
x86_64-linux-gnu-ld: (.text+0x1bdb5a5): undefined reference to `__kunit_do_failed_assertion'
x86_64-linux-gnu-ld: (.text+0x1bdb5b2): undefined reference to `__kunit_abort'
x86_64-linux-gnu-ld: vmlinux.o: in function `kernel::str::tests::kunit_rust_wrapper_test_bstr_display':
(.text+0x1bdcf82): undefined reference to `kunit_unary_assert_format'
x86_64-linux-gnu-ld: (.text+0x1bdcf8f): undefined reference to `__kunit_do_failed_assertion'
x86_64-linux-gnu-ld: (.text+0x1bdcf9c): undefined reference to `__kunit_abort'
x86_64-linux-gnu-ld: vmlinux.o: in function `kernel::str::tests::kunit_rust_wrapper_test_bstr_debug':
(.text+0x1bde962): undefined reference to `kunit_unary_assert_format'
x86_64-linux-gnu-ld: (.text+0x1bde96f): undefined reference to `__kunit_do_failed_assertion'
x86_64-linux-gnu-ld: (.text+0x1bde97c): undefined reference to `__kunit_abort'

Caused by one of the latest commits in the rust tree.

I have used the rust tree from next-20250526 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 tree

[Miguel Ojeda]

On Tue, May 27, 2025 at 11:42 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the rust tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> x86_64-linux-gnu-ld: vmlinux.o: in function `kernel::alloc::kvec::tests::kunit_rust_wrapper_test_kvec_retain':
> (.text+0x1bd7194): undefined reference to `kunit_unary_assert_format'

Sorry about that -- I did my usual tests (several archs, Rust
versions, etc.), but not an `allmodconfig`. I will take a look.

Cheers,
Miguel

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

[Stephen Rothwell]

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

Hi all,

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

error[E0599]: no method named `cast_mut` found for raw pointer `*mut auxiliary_device` in the current scope
   --> rust/kernel/auxiliary.rs:239:83
    |
239 |         let adev = unsafe { container_of!(dev, bindings::auxiliary_device, dev) }.cast_mut();
    |                                                                                   ^^^^^^^^
    |
help: there is a method `as_mut` with a similar name
    |
239 |         let adev = unsafe { container_of!(dev, bindings::auxiliary_device, dev) }.as_mut();
    |                                                                                   ~~~~~~

error: aborting due to 1 previous error

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

Not sure what caused this and that file has not changed from
next-20250509, so I have used the rust tree from next-20250509 for today.
Clearly I need help with the merge resolution here.



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

[Miguel Ojeda]

On Mon, May 12, 2025 at 11:40 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Not sure what caused this and that file has not changed from
> next-20250509, so I have used the rust tree from next-20250509 for today.
> Clearly I need help with the merge resolution here.

Sorry, it is due to commit b0ba6be4458e ("rust: retain pointer
mut-ness in `container_of!`") -- the change requires cleanups in other
code arriving elsewhere and `auxiliary.rs` does not have those.

I was about to suggest the cleanup (just removing 3 cases of
`.cast_mut()`), but then I noticed a Clippy lint triggering in turn
due to that -- reported.

Anyway, I have some upcoming travel, so I have dropped the commit (and
the dependent) for the moment.

Thanks!

Cheers,
Miguel

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

[Stephen Rothwell]

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

Hi all,

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

error[E0277]: `*mut MyStruct` cannot be sent between threads safely
  --> samples/rust/rust_dma.rs:47:22
   |
47 | impl pci::Driver for DmaSampleDriver {
   |                      ^^^^^^^^^^^^^^^ `*mut MyStruct` cannot be sent between threads safely
   |
   = help: within `DmaSampleDriver`, the trait `Send` is not implemented for `*mut MyStruct`, which is required by `DmaSampleDriver: Send`
note: required because it appears within the type `CoherentAllocation<MyStruct>`
  --> rust/kernel/dma.rs:132:12
note: required because it appears within the type `DmaSampleDriver`
  --> samples/rust/rust_dma.rs:9:8
   |
9  | struct DmaSampleDriver {
   |        ^^^^^^^^^^^^^^^
note: required by a bound in `kernel::pci::Driver`
  --> rust/kernel/pci.rs:225:1

error: aborting due to 1 previous error

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

I have no idea what caused this - it built in next-20250321, but that
no longer builds, so I have reset to the version of the rust tree in
next-20250320 (commit 4a47eec07be6).

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

[Stephen Rothwell]

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

Hi all,

On Mon, 24 Mar 2025 21:57:02 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the rust tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> error[E0277]: `*mut MyStruct` cannot be sent between threads safely
>   --> samples/rust/rust_dma.rs:47:22  
>    |
> 47 | impl pci::Driver for DmaSampleDriver {
>    |                      ^^^^^^^^^^^^^^^ `*mut MyStruct` cannot be sent between threads safely
>    |
>    = help: within `DmaSampleDriver`, the trait `Send` is not implemented for `*mut MyStruct`, which is required by `DmaSampleDriver: Send`
> note: required because it appears within the type `CoherentAllocation<MyStruct>`
>   --> rust/kernel/dma.rs:132:12  
> note: required because it appears within the type `DmaSampleDriver`
>   --> samples/rust/rust_dma.rs:9:8  
>    |
> 9  | struct DmaSampleDriver {
>    |        ^^^^^^^^^^^^^^^
> note: required by a bound in `kernel::pci::Driver`
>   --> rust/kernel/pci.rs:225:1  
> 
> error: aborting due to 1 previous error
> 
> For more information about this error, try `rustc --explain E0277`.
> 
> I have no idea what caused this - it built in next-20250321, but that
> no longer builds, so I have reset to the version of the rust tree in
> next-20250320 (commit 4a47eec07be6).

Actually, the driver-core tree gained these commits over the weekend:

  51d0de7596a4 ("rust: platform: require Send for Driver trait implementers")
  935e1d90bf6f ("rust: pci: require Send for Driver trait implementers")
  455943aa187f ("rust: platform: impl Send + Sync for platform::Device")
  e2942bb4e629 ("rust: pci: impl Send + Sync for pci::Device")

A heads up would have been nice ... and maybe even a test merge and
build against -next (given how late we are in the cycle).
-- 
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 tree

[Danilo Krummrich]

Hi Stephen,

On Mon, Mar 24, 2025 at 10:06:29PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> On Mon, 24 Mar 2025 21:57:02 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the rust tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > error[E0277]: `*mut MyStruct` cannot be sent between threads safely
> >   --> samples/rust/rust_dma.rs:47:22  
> >    |
> > 47 | impl pci::Driver for DmaSampleDriver {
> >    |                      ^^^^^^^^^^^^^^^ `*mut MyStruct` cannot be sent between threads safely
> >    |
> >    = help: within `DmaSampleDriver`, the trait `Send` is not implemented for `*mut MyStruct`, which is required by `DmaSampleDriver: Send`
> > note: required because it appears within the type `CoherentAllocation<MyStruct>`
> >   --> rust/kernel/dma.rs:132:12  
> > note: required because it appears within the type `DmaSampleDriver`
> >   --> samples/rust/rust_dma.rs:9:8  
> >    |
> > 9  | struct DmaSampleDriver {
> >    |        ^^^^^^^^^^^^^^^
> > note: required by a bound in `kernel::pci::Driver`
> >   --> rust/kernel/pci.rs:225:1  
> > 
> > error: aborting due to 1 previous error
> > 
> > For more information about this error, try `rustc --explain E0277`.
> > 
> > I have no idea what caused this - it built in next-20250321, but that
> > no longer builds, so I have reset to the version of the rust tree in
> > next-20250320 (commit 4a47eec07be6).
> 
> Actually, the driver-core tree gained these commits over the weekend:
> 
>   51d0de7596a4 ("rust: platform: require Send for Driver trait implementers")
>   935e1d90bf6f ("rust: pci: require Send for Driver trait implementers")
>   455943aa187f ("rust: platform: impl Send + Sync for platform::Device")
>   e2942bb4e629 ("rust: pci: impl Send + Sync for pci::Device")
> 
> A heads up would have been nice ... and maybe even a test merge and
> build against -next (given how late we are in the cycle).

Commit 935e1d90bf6f ("rust: pci: require Send for Driver trait implementers")
from the driver-core tree fixes a missing concurrency requirement, which commit
9901addae63b ("samples: rust: add Rust dma test sample driver") from the Rust
tree did not yet consider.

Technically, it did what it is supposed to do -- catch a concurrency issue at
compile time. However, since I was involved into both sides, I could have
thought of this, but unfortunately in this case it was too subtle for me to
spot -- sorry.

There are two options, 1. simply drop the commit [1] that introduces the
affected sample DMA code, or 2. apply the fix below to [2]. My preference would
be (2).

--

diff --git a/rust/kernel/dma.rs b/rust/kernel/dma.rs
index 9d00f9c49f47..18de693c4924 100644
--- a/rust/kernel/dma.rs
+++ b/rust/kernel/dma.rs
@@ -301,6 +301,10 @@ fn drop(&mut self) {
     }
 }

+// SAFETY: It is safe to send a `CoherentAllocation` to another thread if `T`
+// can be send to another thread.
+unsafe impl<T: AsBytes + FromBytes + Send> Send for CoherentAllocation<T> {}
+
 /// Reads a field of an item from an allocated region of structs.
 ///
 /// # Examples

--

[1] 9901addae63b ("samples: rust: add Rust dma test sample driver")
[2] ad2907b4e308 ("rust: add dma coherent allocator abstraction")

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

[Greg KH]

On Mon, Mar 24, 2025 at 12:59:27PM +0100, Danilo Krummrich wrote:
> Hi Stephen,
> 
> On Mon, Mar 24, 2025 at 10:06:29PM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > On Mon, 24 Mar 2025 21:57:02 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > After merging the rust tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > > 
> > > error[E0277]: `*mut MyStruct` cannot be sent between threads safely
> > >   --> samples/rust/rust_dma.rs:47:22  
> > >    |
> > > 47 | impl pci::Driver for DmaSampleDriver {
> > >    |                      ^^^^^^^^^^^^^^^ `*mut MyStruct` cannot be sent between threads safely
> > >    |
> > >    = help: within `DmaSampleDriver`, the trait `Send` is not implemented for `*mut MyStruct`, which is required by `DmaSampleDriver: Send`
> > > note: required because it appears within the type `CoherentAllocation<MyStruct>`
> > >   --> rust/kernel/dma.rs:132:12  
> > > note: required because it appears within the type `DmaSampleDriver`
> > >   --> samples/rust/rust_dma.rs:9:8  
> > >    |
> > > 9  | struct DmaSampleDriver {
> > >    |        ^^^^^^^^^^^^^^^
> > > note: required by a bound in `kernel::pci::Driver`
> > >   --> rust/kernel/pci.rs:225:1  
> > > 
> > > error: aborting due to 1 previous error
> > > 
> > > For more information about this error, try `rustc --explain E0277`.
> > > 
> > > I have no idea what caused this - it built in next-20250321, but that
> > > no longer builds, so I have reset to the version of the rust tree in
> > > next-20250320 (commit 4a47eec07be6).
> > 
> > Actually, the driver-core tree gained these commits over the weekend:
> > 
> >   51d0de7596a4 ("rust: platform: require Send for Driver trait implementers")
> >   935e1d90bf6f ("rust: pci: require Send for Driver trait implementers")
> >   455943aa187f ("rust: platform: impl Send + Sync for platform::Device")
> >   e2942bb4e629 ("rust: pci: impl Send + Sync for pci::Device")
> > 
> > A heads up would have been nice ... and maybe even a test merge and
> > build against -next (given how late we are in the cycle).
> 
> Commit 935e1d90bf6f ("rust: pci: require Send for Driver trait implementers")
> from the driver-core tree fixes a missing concurrency requirement, which commit
> 9901addae63b ("samples: rust: add Rust dma test sample driver") from the Rust
> tree did not yet consider.
> 
> Technically, it did what it is supposed to do -- catch a concurrency issue at
> compile time. However, since I was involved into both sides, I could have
> thought of this, but unfortunately in this case it was too subtle for me to
> spot -- sorry.
> 
> There are two options, 1. simply drop the commit [1] that introduces the
> affected sample DMA code, or 2. apply the fix below to [2]. My preference would
> be (2).
> 
> --
> 
> diff --git a/rust/kernel/dma.rs b/rust/kernel/dma.rs
> index 9d00f9c49f47..18de693c4924 100644
> --- a/rust/kernel/dma.rs
> +++ b/rust/kernel/dma.rs
> @@ -301,6 +301,10 @@ fn drop(&mut self) {
>      }
>  }
> 
> +// SAFETY: It is safe to send a `CoherentAllocation` to another thread if `T`
> +// can be send to another thread.
> +unsafe impl<T: AsBytes + FromBytes + Send> Send for CoherentAllocation<T> {}
> +
>  /// Reads a field of an item from an allocated region of structs.
>  ///
>  /// # Examples
> 

I can't "drop" anything here as that would be a mess.  Maybe we just
consider a merge of the driver core and rust trees at this point in time
and fix things up and do a combined pull request to Linus so he doesn't
have to deal with the fixups?

thanks,

greg k-h

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

[Danilo Krummrich]

On Mon, Mar 24, 2025 at 06:29:30AM -0700, Greg KH wrote:
> On Mon, Mar 24, 2025 at 12:59:27PM +0100, Danilo Krummrich wrote:
> > Hi Stephen,
> > 
> > On Mon, Mar 24, 2025 at 10:06:29PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > On Mon, 24 Mar 2025 21:57:02 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > >
> > > > After merging the rust tree, today's linux-next build (x86_64
> > > > allmodconfig) failed like this:
> > > > 
> > > > error[E0277]: `*mut MyStruct` cannot be sent between threads safely
> > > >   --> samples/rust/rust_dma.rs:47:22  
> > > >    |
> > > > 47 | impl pci::Driver for DmaSampleDriver {
> > > >    |                      ^^^^^^^^^^^^^^^ `*mut MyStruct` cannot be sent between threads safely
> > > >    |
> > > >    = help: within `DmaSampleDriver`, the trait `Send` is not implemented for `*mut MyStruct`, which is required by `DmaSampleDriver: Send`
> > > > note: required because it appears within the type `CoherentAllocation<MyStruct>`
> > > >   --> rust/kernel/dma.rs:132:12  
> > > > note: required because it appears within the type `DmaSampleDriver`
> > > >   --> samples/rust/rust_dma.rs:9:8  
> > > >    |
> > > > 9  | struct DmaSampleDriver {
> > > >    |        ^^^^^^^^^^^^^^^
> > > > note: required by a bound in `kernel::pci::Driver`
> > > >   --> rust/kernel/pci.rs:225:1  
> > > > 
> > > > error: aborting due to 1 previous error
> > > > 
> > > > For more information about this error, try `rustc --explain E0277`.
> > > > 
> > > > I have no idea what caused this - it built in next-20250321, but that
> > > > no longer builds, so I have reset to the version of the rust tree in
> > > > next-20250320 (commit 4a47eec07be6).
> > > 
> > > Actually, the driver-core tree gained these commits over the weekend:
> > > 
> > >   51d0de7596a4 ("rust: platform: require Send for Driver trait implementers")
> > >   935e1d90bf6f ("rust: pci: require Send for Driver trait implementers")
> > >   455943aa187f ("rust: platform: impl Send + Sync for platform::Device")
> > >   e2942bb4e629 ("rust: pci: impl Send + Sync for pci::Device")
> > > 
> > > A heads up would have been nice ... and maybe even a test merge and
> > > build against -next (given how late we are in the cycle).
> > 
> > Commit 935e1d90bf6f ("rust: pci: require Send for Driver trait implementers")
> > from the driver-core tree fixes a missing concurrency requirement, which commit
> > 9901addae63b ("samples: rust: add Rust dma test sample driver") from the Rust
> > tree did not yet consider.
> > 
> > Technically, it did what it is supposed to do -- catch a concurrency issue at
> > compile time. However, since I was involved into both sides, I could have
> > thought of this, but unfortunately in this case it was too subtle for me to
> > spot -- sorry.
> > 
> > There are two options, 1. simply drop the commit [1] that introduces the
> > affected sample DMA code, or 2. apply the fix below to [2]. My preference would
> > be (2).
> > 
> > --
> > 
> > diff --git a/rust/kernel/dma.rs b/rust/kernel/dma.rs
> > index 9d00f9c49f47..18de693c4924 100644
> > --- a/rust/kernel/dma.rs
> > +++ b/rust/kernel/dma.rs
> > @@ -301,6 +301,10 @@ fn drop(&mut self) {
> >      }
> >  }
> > 
> > +// SAFETY: It is safe to send a `CoherentAllocation` to another thread if `T`
> > +// can be send to another thread.
> > +unsafe impl<T: AsBytes + FromBytes + Send> Send for CoherentAllocation<T> {}
> > +
> >  /// Reads a field of an item from an allocated region of structs.
> >  ///
> >  /// # Examples
> > 
> 
> I can't "drop" anything here as that would be a mess.

It's the DMA commit that has a bug, that was revealed by the fix in the
driver-core tree. So, the patch to drop is in the rust tree (not sure if Miguel
changes history at this point though).

Anyways, I think the fix is simple enough.

> Maybe we just
> consider a merge of the driver core and rust trees at this point in time
> and fix things up and do a combined pull request to Linus so he doesn't
> have to deal with the fixups?

I think it's not that bad, the full diff for the conflicts between driver-core
and rust is:

diff --git a/rust/kernel/dma.rs b/rust/kernel/dma.rs
index 9d00f9c49f47..18de693c4924 100644
--- a/rust/kernel/dma.rs
+++ b/rust/kernel/dma.rs
@@ -301,6 +301,10 @@ fn drop(&mut self) {
     }
 }

+// SAFETY: It is safe to send a `CoherentAllocation` to another thread if `T`
+// can be send to another thread.
+unsafe impl<T: AsBytes + FromBytes + Send> Send for CoherentAllocation<T> {}
+
 /// Reads a field of an item from an allocated region of structs.
 ///
 /// # Examples
diff --git a/samples/rust/rust_dma.rs b/samples/rust/rust_dma.rs
index 908acd34b8db..874c2c964afa 100644
--- a/samples/rust/rust_dma.rs
+++ b/samples/rust/rust_dma.rs
@@ -4,10 +4,10 @@
 //!
 //! To make this driver probe, QEMU must be run with `-device pci-testdev`.

-use kernel::{bindings, dma::CoherentAllocation, pci, prelude::*};
+use kernel::{bindings, device::Core, dma::CoherentAllocation, pci, prelude::*, types::ARef};

 struct DmaSampleDriver {
-    pdev: pci::Device,
+    pdev: ARef<pci::Device>,
     ca: CoherentAllocation<MyStruct>,
 }

@@ -48,7 +48,7 @@ impl pci::Driver for DmaSampleDriver {
     type IdInfo = ();
     const ID_TABLE: pci::IdTable<Self::IdInfo> = &PCI_TABLE;

-    fn probe(pdev: &mut pci::Device, _info: &Self::IdInfo) -> Result<Pin<KBox<Self>>> {
+    fn probe(pdev: &pci::Device<Core>, _info: &Self::IdInfo) -> Result<Pin<KBox<Self>>> {
         dev_info!(pdev.as_ref(), "Probe DMA test driver.\n");

         let ca: CoherentAllocation<MyStruct> =
@@ -64,7 +64,7 @@ fn probe(pdev: &mut pci::Device, _info: &Self::IdInfo) -> Result<Pin<KBox<Self>>

         let drvdata = KBox::new(
             Self {
-                pdev: pdev.clone(),
+                pdev: pdev.into(),
                 ca,
             },
             GFP_KERNEL,

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

[Greg KH]

On Mon, Mar 24, 2025 at 02:43:27PM +0100, Danilo Krummrich wrote:
> On Mon, Mar 24, 2025 at 06:29:30AM -0700, Greg KH wrote:
> > On Mon, Mar 24, 2025 at 12:59:27PM +0100, Danilo Krummrich wrote:
> > > Hi Stephen,
> > > 
> > > On Mon, Mar 24, 2025 at 10:06:29PM +1100, Stephen Rothwell wrote:
> > > > Hi all,
> > > > 
> > > > On Mon, 24 Mar 2025 21:57:02 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > >
> > > > > After merging the rust tree, today's linux-next build (x86_64
> > > > > allmodconfig) failed like this:
> > > > > 
> > > > > error[E0277]: `*mut MyStruct` cannot be sent between threads safely
> > > > >   --> samples/rust/rust_dma.rs:47:22  
> > > > >    |
> > > > > 47 | impl pci::Driver for DmaSampleDriver {
> > > > >    |                      ^^^^^^^^^^^^^^^ `*mut MyStruct` cannot be sent between threads safely
> > > > >    |
> > > > >    = help: within `DmaSampleDriver`, the trait `Send` is not implemented for `*mut MyStruct`, which is required by `DmaSampleDriver: Send`
> > > > > note: required because it appears within the type `CoherentAllocation<MyStruct>`
> > > > >   --> rust/kernel/dma.rs:132:12  
> > > > > note: required because it appears within the type `DmaSampleDriver`
> > > > >   --> samples/rust/rust_dma.rs:9:8  
> > > > >    |
> > > > > 9  | struct DmaSampleDriver {
> > > > >    |        ^^^^^^^^^^^^^^^
> > > > > note: required by a bound in `kernel::pci::Driver`
> > > > >   --> rust/kernel/pci.rs:225:1  
> > > > > 
> > > > > error: aborting due to 1 previous error
> > > > > 
> > > > > For more information about this error, try `rustc --explain E0277`.
> > > > > 
> > > > > I have no idea what caused this - it built in next-20250321, but that
> > > > > no longer builds, so I have reset to the version of the rust tree in
> > > > > next-20250320 (commit 4a47eec07be6).
> > > > 
> > > > Actually, the driver-core tree gained these commits over the weekend:
> > > > 
> > > >   51d0de7596a4 ("rust: platform: require Send for Driver trait implementers")
> > > >   935e1d90bf6f ("rust: pci: require Send for Driver trait implementers")
> > > >   455943aa187f ("rust: platform: impl Send + Sync for platform::Device")
> > > >   e2942bb4e629 ("rust: pci: impl Send + Sync for pci::Device")
> > > > 
> > > > A heads up would have been nice ... and maybe even a test merge and
> > > > build against -next (given how late we are in the cycle).
> > > 
> > > Commit 935e1d90bf6f ("rust: pci: require Send for Driver trait implementers")
> > > from the driver-core tree fixes a missing concurrency requirement, which commit
> > > 9901addae63b ("samples: rust: add Rust dma test sample driver") from the Rust
> > > tree did not yet consider.
> > > 
> > > Technically, it did what it is supposed to do -- catch a concurrency issue at
> > > compile time. However, since I was involved into both sides, I could have
> > > thought of this, but unfortunately in this case it was too subtle for me to
> > > spot -- sorry.
> > > 
> > > There are two options, 1. simply drop the commit [1] that introduces the
> > > affected sample DMA code, or 2. apply the fix below to [2]. My preference would
> > > be (2).
> > > 
> > > --
> > > 
> > > diff --git a/rust/kernel/dma.rs b/rust/kernel/dma.rs
> > > index 9d00f9c49f47..18de693c4924 100644
> > > --- a/rust/kernel/dma.rs
> > > +++ b/rust/kernel/dma.rs
> > > @@ -301,6 +301,10 @@ fn drop(&mut self) {
> > >      }
> > >  }
> > > 
> > > +// SAFETY: It is safe to send a `CoherentAllocation` to another thread if `T`
> > > +// can be send to another thread.
> > > +unsafe impl<T: AsBytes + FromBytes + Send> Send for CoherentAllocation<T> {}
> > > +
> > >  /// Reads a field of an item from an allocated region of structs.
> > >  ///
> > >  /// # Examples
> > > 
> > 
> > I can't "drop" anything here as that would be a mess.
> 
> It's the DMA commit that has a bug, that was revealed by the fix in the
> driver-core tree. So, the patch to drop is in the rust tree (not sure if Miguel
> changes history at this point though).
> 
> Anyways, I think the fix is simple enough.
> 
> > Maybe we just
> > consider a merge of the driver core and rust trees at this point in time
> > and fix things up and do a combined pull request to Linus so he doesn't
> > have to deal with the fixups?
> 
> I think it's not that bad, the full diff for the conflicts between driver-core
> and rust is:
> 
> diff --git a/rust/kernel/dma.rs b/rust/kernel/dma.rs
> index 9d00f9c49f47..18de693c4924 100644
> --- a/rust/kernel/dma.rs
> +++ b/rust/kernel/dma.rs
> @@ -301,6 +301,10 @@ fn drop(&mut self) {
>      }
>  }
> 
> +// SAFETY: It is safe to send a `CoherentAllocation` to another thread if `T`
> +// can be send to another thread.
> +unsafe impl<T: AsBytes + FromBytes + Send> Send for CoherentAllocation<T> {}
> +
>  /// Reads a field of an item from an allocated region of structs.
>  ///
>  /// # Examples
> diff --git a/samples/rust/rust_dma.rs b/samples/rust/rust_dma.rs
> index 908acd34b8db..874c2c964afa 100644
> --- a/samples/rust/rust_dma.rs
> +++ b/samples/rust/rust_dma.rs
> @@ -4,10 +4,10 @@
>  //!
>  //! To make this driver probe, QEMU must be run with `-device pci-testdev`.
> 
> -use kernel::{bindings, dma::CoherentAllocation, pci, prelude::*};
> +use kernel::{bindings, device::Core, dma::CoherentAllocation, pci, prelude::*, types::ARef};
> 
>  struct DmaSampleDriver {
> -    pdev: pci::Device,
> +    pdev: ARef<pci::Device>,
>      ca: CoherentAllocation<MyStruct>,
>  }
> 
> @@ -48,7 +48,7 @@ impl pci::Driver for DmaSampleDriver {
>      type IdInfo = ();
>      const ID_TABLE: pci::IdTable<Self::IdInfo> = &PCI_TABLE;
> 
> -    fn probe(pdev: &mut pci::Device, _info: &Self::IdInfo) -> Result<Pin<KBox<Self>>> {
> +    fn probe(pdev: &pci::Device<Core>, _info: &Self::IdInfo) -> Result<Pin<KBox<Self>>> {
>          dev_info!(pdev.as_ref(), "Probe DMA test driver.\n");
> 
>          let ca: CoherentAllocation<MyStruct> =
> @@ -64,7 +64,7 @@ fn probe(pdev: &mut pci::Device, _info: &Self::IdInfo) -> Result<Pin<KBox<Self>>
> 
>          let drvdata = KBox::new(
>              Self {
> -                pdev: pdev.clone(),
> +                pdev: pdev.into(),
>                  ca,
>              },
>              GFP_KERNEL,

Ok, let's just leave it as-is for now...

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

[Miguel Ojeda]

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

On Mon, Mar 24, 2025 at 2:43 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> It's the DMA commit that has a bug, that was revealed by the fix in the
> driver-core tree. So, the patch to drop is in the rust tree (not sure if Miguel
> changes history at this point though).

Just to double-check, the diff you show below is the combined one,
right? i.e. it is the one that Stephen already had the previous week +
the fix you posted above (`Send` `impl`), right?

If so, I think it is OK, and we could put the new `Send` impl on top
of `rust-next` -- given the trees on their own are OK until they
arrive to Linus, I am not sure if it counts as a fix.

i.e. something like the attached patch (crediting Danilo and Stephen).

Cheers,
Miguel

[-- Attachment #2: 0001-rust-dma-add-Send-implementation-for-CoherentAllocat.patch --]
[-- Type: text/x-patch, Size: 1795 bytes --]

From 6a152af23cb49a3bcbb8c4457a612ffa27d54693 Mon Sep 17 00:00:00 2001
From: Danilo Krummrich <dakr@kernel.org>
Date: Mon, 24 Mar 2025 16:01:00 +0100
Subject: [PATCH] rust: dma: add `Send` implementation for `CoherentAllocation`

Stephen found a future build failure in linux-next [1]:

    error[E0277]: `*mut MyStruct` cannot be sent between threads safely
      --> samples/rust/rust_dma.rs:47:22
       |
    47 | impl pci::Driver for DmaSampleDriver {
       |                      ^^^^^^^^^^^^^^^ `*mut MyStruct` cannot be sent between threads safely

It is caused by the interaction between commit 935e1d90bf6f ("rust: pci:
require Send for Driver trait implementers") from the driver-core tree,
which fixes a missing concurrency requirement, and commit 9901addae63b
("samples: rust: add Rust dma test sample driver") which adds a sample
that does not satisfy that requirement.

Add a `Send` implementation to `CoherentAllocation`, which allows the
sample (and other future users) to satisfy it.

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Link: https://lore.kernel.org/linux-next/20250324215702.1515ba92@canb.auug.org.au/
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 rust/kernel/dma.rs | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/rust/kernel/dma.rs b/rust/kernel/dma.rs
index 9d00f9c49f47..18de693c4924 100644
--- a/rust/kernel/dma.rs
+++ b/rust/kernel/dma.rs
@@ -301,6 +301,10 @@ fn drop(&mut self) {
     }
 }
 
+// SAFETY: It is safe to send a `CoherentAllocation` to another thread if `T`
+// can be send to another thread.
+unsafe impl<T: AsBytes + FromBytes + Send> Send for CoherentAllocation<T> {}
+
 /// Reads a field of an item from an allocated region of structs.
 ///
 /// # Examples
-- 
2.49.0

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

[Danilo Krummrich]

On Mon, Mar 24, 2025 at 04:18:40PM +0100, Miguel Ojeda wrote:
> On Mon, Mar 24, 2025 at 2:43 PM Danilo Krummrich <dakr@kernel.org> wrote:
> >
> > It's the DMA commit that has a bug, that was revealed by the fix in the
> > driver-core tree. So, the patch to drop is in the rust tree (not sure if Miguel
> > changes history at this point though).
> 
> Just to double-check, the diff you show below is the combined one,
> right? i.e. it is the one that Stephen already had the previous week +
> the fix you posted above (`Send` `impl`), right?

Correct, it is the full conflict resolution of the current rust and driver-core
tree.

> 
> If so, I think it is OK, and we could put the new `Send` impl on top
> of `rust-next` -- given the trees on their own are OK until they
> arrive to Linus, I am not sure if it counts as a fix.
> 
> i.e. something like the attached patch (crediting Danilo and Stephen).

Thanks, the attached patch looks perfectly fine to me to add on top.

One small nit: The "Link:" tag should rather be "Closes:".

> 
> Cheers,
> Miguel

> From 6a152af23cb49a3bcbb8c4457a612ffa27d54693 Mon Sep 17 00:00:00 2001
> From: Danilo Krummrich <dakr@kernel.org>
> Date: Mon, 24 Mar 2025 16:01:00 +0100
> Subject: [PATCH] rust: dma: add `Send` implementation for `CoherentAllocation`
> 
> Stephen found a future build failure in linux-next [1]:
> 
>     error[E0277]: `*mut MyStruct` cannot be sent between threads safely
>       --> samples/rust/rust_dma.rs:47:22
>        |
>     47 | impl pci::Driver for DmaSampleDriver {
>        |                      ^^^^^^^^^^^^^^^ `*mut MyStruct` cannot be sent between threads safely
> 
> It is caused by the interaction between commit 935e1d90bf6f ("rust: pci:
> require Send for Driver trait implementers") from the driver-core tree,
> which fixes a missing concurrency requirement, and commit 9901addae63b
> ("samples: rust: add Rust dma test sample driver") which adds a sample
> that does not satisfy that requirement.
> 
> Add a `Send` implementation to `CoherentAllocation`, which allows the
> sample (and other future users) to satisfy it.
> 
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Link: https://lore.kernel.org/linux-next/20250324215702.1515ba92@canb.auug.org.au/
> Signed-off-by: Danilo Krummrich <dakr@kernel.org>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
>  rust/kernel/dma.rs | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/rust/kernel/dma.rs b/rust/kernel/dma.rs
> index 9d00f9c49f47..18de693c4924 100644
> --- a/rust/kernel/dma.rs
> +++ b/rust/kernel/dma.rs
> @@ -301,6 +301,10 @@ fn drop(&mut self) {
>      }
>  }
>  
> +// SAFETY: It is safe to send a `CoherentAllocation` to another thread if `T`
> +// can be send to another thread.
> +unsafe impl<T: AsBytes + FromBytes + Send> Send for CoherentAllocation<T> {}
> +
>  /// Reads a field of an item from an allocated region of structs.
>  ///
>  /// # Examples
> -- 
> 2.49.0
> 

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

[Miguel Ojeda]

On Mon, Mar 24, 2025 at 4:27 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> Correct, it is the full conflict resolution of the current rust and driver-core
> tree.
>
> Thanks, the attached patch looks perfectly fine to me to add on top.

Thanks for the quick reply, then I will send it and add it.

> One small nit: The "Link:" tag should rather be "Closes:".

Sure, will change -- I didn't use that since I am still not sure it
counts as a fix or not (so Reported-by vs. "Found-by", Closes vs. Link
etc.), given it is "in the future" :)

Cheers,
Miguel

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

[Stephen Rothwell]

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

Hi all,

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

error[E0603]: trait import `PinInit` is private
   --> rust/kernel/time/hrtimer.rs:71:19
    |
71  | use crate::{init::PinInit, prelude::*, time::Ktime, types::Opaque};
    |                   ^^^^^^^ private trait import
    |
note: the trait import `PinInit` is defined here...
   --> rust/kernel/init.rs:141:64
    |
141 | use pin_init::{init_from_closure, pin_init_from_closure, Init, PinInit};
    |                                                                ^^^^^^^
note: ...and refers to the trait `PinInit` which is defined here
   --> rust/pin-init/src/lib.rs:1003:1
    |
    = note: you could import this directly
help: import `PinInit` directly
    |
71  | use crate::{pin_init::PinInit, prelude::*, time::Ktime, types::Opaque};
    |             ~~~~~~~~~~~~~~~~~

error: aborting due to 1 previous error

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

Presumably this is caused by my merge resolutions :-(  Please have a
look and let me know what te resolutions should be.

I have used the rust tree from next-20250314 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 tree

[Miguel Ojeda]

On Mon, Mar 17, 2025 at 11:58 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Presumably this is caused by my merge resolutions :-(  Please have a
> look and let me know what te resolutions should be.

No, it is due to hrtimer-next, which I still have to merge on my side.
I have created an example merge of hrtimer-next into rust-next which
should solve you mention error above -- but please feel free to drop
hrtimer-next today if you prefer, since I will be pushing to rust-next
the proper merge if linux-next goes well, so you will get it:

    https://github.com/ojeda/linux.git rust-next-merge-hrtimer

For the other things mentioned in the other threads, I have also
created two branches, one merging rust-next into Linus, and another
into next-20250317 -- not sure which is the one you usually prefer:

    https://github.com/ojeda/linux.git linus-merge-rust-next
    https://github.com/ojeda/linux.git next-merge-rust-next

It is a bit subtle because we have to "redo" a fix from mainline in 2
different places since the lines of the fix are moved in rust-next.

I build-tested the branches a bit -- I hope they are all OK.

I didn't modify anything in rust-next today to avoid further issues
and get this part over with.

Thanks!

Cheers,
Miguel

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

[Stephen Rothwell]

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

Hi Miguel,

On Mon, 17 Mar 2025 23:35:54 +0100 Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Mon, Mar 17, 2025 at 11:58 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Presumably this is caused by my merge resolutions :-(  Please have a
> > look and let me know what te resolutions should be.  
> 
> No, it is due to hrtimer-next, which I still have to merge on my side.
> I have created an example merge of hrtimer-next into rust-next which
> should solve you mention error above -- but please feel free to drop
> hrtimer-next today if you prefer, since I will be pushing to rust-next
> the proper merge if linux-next goes well, so you will get it:
> 
>     https://github.com/ojeda/linux.git rust-next-merge-hrtimer
> 
> For the other things mentioned in the other threads, I have also
> created two branches, one merging rust-next into Linus, and another
> into next-20250317 -- not sure which is the one you usually prefer:
> 
>     https://github.com/ojeda/linux.git linus-merge-rust-next
>     https://github.com/ojeda/linux.git next-merge-rust-next
> 
> It is a bit subtle because we have to "redo" a fix from mainline in 2
> different places since the lines of the fix are moved in rust-next.
> 
> I build-tested the branches a bit -- I hope they are all OK.
> 
> I didn't modify anything in rust-next today to avoid further issues
> and get this part over with.

Thanks, I will see what I can come up with.

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

[Stephen Rothwell]

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

Hi all,

On Tue, 18 Mar 2025 10:35:04 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Thanks, I will see what I can come up with.

(there are 2 resolutions below)

When I merge the rust tree into linux-next, the complete resolution now
looks like this:
(the hunk in rust/kernel/sync.rs is needed due to a commit in the tip
tree)

892715be4379deb333376e573113fd75672eca6c
diff --cc drivers/gpu/drm/drm_panic_qr.rs
index 5d21f6d10bcb,ecd87e8ffe05..f2a99681b998
--- a/drivers/gpu/drm/drm_panic_qr.rs
+++ b/drivers/gpu/drm/drm_panic_qr.rs
@@@ -27,7 -26,8 +27,7 @@@
  //! * <https://github.com/erwanvivien/fast_qr>
  //! * <https://github.com/bjguillot/qr>
  
- use kernel::str::CStr;
 -use core::cmp;
+ use kernel::{prelude::*, str::CStr};
  
  #[derive(Debug, Clone, Copy, PartialEq, Eq, Ord, PartialOrd)]
  struct Version(usize);
diff --cc rust/Makefile
index 089473a89d46,e761a8cc3bd5..3474f0b2b24c
--- a/rust/Makefile
+++ b/rust/Makefile
@@@ -175,9 -199,9 +203,9 @@@ quiet_cmd_rustdoc_test_kernel = RUSTDO
  	rm -rf $(objtree)/$(obj)/test/doctests/kernel; \
  	mkdir -p $(objtree)/$(obj)/test/doctests/kernel; \
  	OBJTREE=$(abspath $(objtree)) \
 -	$(RUSTDOC) --test $(rust_flags) \
 +	$(RUSTDOC) --test $(filter-out --remap-path-prefix=%,$(rust_flags)) \
- 		-L$(objtree)/$(obj) --extern ffi --extern kernel \
- 		--extern build_error --extern macros \
+ 		-L$(objtree)/$(obj) --extern ffi --extern pin_init \
+ 		--extern kernel --extern build_error --extern macros \
  		--extern bindings --extern uapi \
  		--no-run --crate-name kernel -Zunstable-options \
  		--sysroot=/dev/null \
diff --cc rust/kernel/alloc/kbox.rs
index cb4ebea3b074,e6200cd1d06d..a4bde2616c4e
--- a/rust/kernel/alloc/kbox.rs
+++ b/rust/kernel/alloc/kbox.rs
@@@ -99,6 -100,12 +100,10 @@@ pub type VBox<T> = Box<T, super::alloca
  /// ```
  pub type KVBox<T> = Box<T, super::allocator::KVmalloc>;
  
 -// SAFETY: All zeros is equivalent to `None` (option layout optimization guarantee).
 -//
 -// In this case we are allowed to use `T: ?Sized`, since all zeros is the `None` variant and there
 -// is no problem with a VTABLE pointer being null.
 -unsafe impl<T: ?Sized, A: Allocator> ZeroableOption for Box<T, A> {}
++// SAFETY: All zeros is equivalent to `None` (option layout optimization guarantee:
++// https://doc.rust-lang.org/stable/std/option/index.html#representation).
++unsafe impl<T, A: Allocator> ZeroableOption for Box<T, A> {}
+ 
  // SAFETY: `Box` is `Send` if `T` is `Send` because the `Box` owns a `T`.
  unsafe impl<T, A> Send for Box<T, A>
  where
diff --cc rust/kernel/sync.rs
index 4104bc26471a,3498fb344dc9..ee8ffd2955b8
--- a/rust/kernel/sync.rs
+++ b/rust/kernel/sync.rs
@@@ -5,8 -5,6 +5,8 @@@
  //! This module contains the kernel APIs related to synchronisation that have been ported or
  //! wrapped for usage by Rust code in the kernel.
  
- use crate::pin_init;
++use pin_init;
 +use crate::prelude::*;
  use crate::types::Opaque;
  
  mod arc;
diff --cc rust/kernel/sync/condvar.rs
index fbf68ada582f,c2535db9e0f8..caebf03f553b
--- a/rust/kernel/sync/condvar.rs
+++ b/rust/kernel/sync/condvar.rs
@@@ -8,17 -8,14 +8,15 @@@
  use super::{lock::Backend, lock::Guard, LockClassKey};
  use crate::{
      ffi::{c_int, c_long},
-     init::PinInit,
-     pin_init,
      str::CStr,
 -    task::{MAX_SCHEDULE_TIMEOUT, TASK_INTERRUPTIBLE, TASK_NORMAL, TASK_UNINTERRUPTIBLE},
 +    task::{
 +        MAX_SCHEDULE_TIMEOUT, TASK_FREEZABLE, TASK_INTERRUPTIBLE, TASK_NORMAL, TASK_UNINTERRUPTIBLE,
 +    },
      time::Jiffies,
      types::Opaque,
  };
 -use core::marker::PhantomPinned;
 -use core::ptr;
 +use core::{marker::PhantomPinned, pin::Pin, ptr};
- use macros::pin_data;
+ use pin_init::{pin_data, pin_init, PinInit};
  
  /// Creates a [`CondVar`] initialiser with the given name and a newly-created lock class.
  #[macro_export]
diff --cc rust/kernel/sync/lock.rs
index 360a10a9216d,7f611b59ac57..b69ed684df14
--- a/rust/kernel/sync/lock.rs
+++ b/rust/kernel/sync/lock.rs
@@@ -10,10 -10,8 +10,8 @@@ use crate::
      str::CStr,
      types::{NotThreadSafe, Opaque, ScopeGuard},
  };
 -use core::{cell::UnsafeCell, marker::PhantomPinned};
 +use core::{cell::UnsafeCell, marker::PhantomPinned, pin::Pin};
- use macros::pin_data;
+ use pin_init::{pin_data, pin_init, PinInit};
  
  pub mod mutex;
  pub mod spinlock;
diff --cc rust/pin-init/src/lib.rs
index 000000000000,f36b8f8e8730..9cd822388ba2
mode 000000,100644..100644
--- a/rust/pin-init/src/lib.rs
+++ b/rust/pin-init/src/lib.rs
@@@ -1,0 -1,1486 +1,1484 @@@
+ // SPDX-License-Identifier: Apache-2.0 OR MIT
+ 
+ //! Library to safely and fallibly initialize pinned `struct`s using in-place constructors.
+ //!
+ //! [Pinning][pinning] is Rust's way of ensuring data does not move.
+ //!
+ //! It also allows in-place initialization of big `struct`s that would otherwise produce a stack
+ //! overflow.
+ //!
+ //! This library's main use-case is in [Rust-for-Linux]. Although this version can be used
+ //! standalone.
+ //!
+ //! There are cases when you want to in-place initialize a struct. For example when it is very big
+ //! and moving it from the stack is not an option, because it is bigger than the stack itself.
+ //! Another reason would be that you need the address of the object to initialize it. This stands
+ //! in direct conflict with Rust's normal process of first initializing an object and then moving
+ //! it into it's final memory location. For more information, see
+ //! <https://rust-for-linux.com/the-safe-pinned-initialization-problem>.
+ //!
+ //! This library allows you to do in-place initialization safely.
+ //!
+ //! ## Nightly Needed for `alloc` feature
+ //!
+ //! This library requires the [`allocator_api` unstable feature] when the `alloc` feature is
+ //! enabled and thus this feature can only be used with a nightly compiler. When enabling the
+ //! `alloc` feature, the user will be required to activate `allocator_api` as well.
+ //!
+ //! [`allocator_api` unstable feature]: https://doc.rust-lang.org/nightly/unstable-book/library-features/allocator-api.html
+ //!
+ //! The feature is enabled by default, thus by default `pin-init` will require a nightly compiler.
+ //! However, using the crate on stable compilers is possible by disabling `alloc`. In practice this
+ //! will require the `std` feature, because stable compilers have neither `Box` nor `Arc` in no-std
+ //! mode.
+ //!
+ //! # Overview
+ //!
+ //! To initialize a `struct` with an in-place constructor you will need two things:
+ //! - an in-place constructor,
+ //! - a memory location that can hold your `struct` (this can be the [stack], an [`Arc<T>`],
+ //!   [`Box<T>`] or any other smart pointer that supports this library).
+ //!
+ //! To get an in-place constructor there are generally three options:
+ //! - directly creating an in-place constructor using the [`pin_init!`] macro,
+ //! - a custom function/macro returning an in-place constructor provided by someone else,
+ //! - using the unsafe function [`pin_init_from_closure()`] to manually create an initializer.
+ //!
+ //! Aside from pinned initialization, this library also supports in-place construction without
+ //! pinning, the macros/types/functions are generally named like the pinned variants without the
+ //! `pin_` prefix.
+ //!
+ //! # Examples
+ //!
+ //! Throughout the examples we will often make use of the `CMutex` type which can be found in
+ //! `../examples/mutex.rs`. It is essentially a userland rebuild of the `struct mutex` type from
+ //! the Linux kernel. It also uses a wait list and a basic spinlock. Importantly the wait list
+ //! requires it to be pinned to be locked and thus is a prime candidate for using this library.
+ //!
+ //! ## Using the [`pin_init!`] macro
+ //!
+ //! If you want to use [`PinInit`], then you will have to annotate your `struct` with
+ //! `#[`[`pin_data`]`]`. It is a macro that uses `#[pin]` as a marker for
+ //! [structurally pinned fields]. After doing this, you can then create an in-place constructor via
+ //! [`pin_init!`]. The syntax is almost the same as normal `struct` initializers. The difference is
+ //! that you need to write `<-` instead of `:` for fields that you want to initialize in-place.
+ //!
+ //! ```rust
+ //! # #![expect(clippy::disallowed_names)]
+ //! # #![feature(allocator_api)]
+ //! # #[path = "../examples/mutex.rs"] mod mutex; use mutex::*;
+ //! # use core::pin::Pin;
+ //! use pin_init::{pin_data, pin_init, InPlaceInit};
+ //!
+ //! #[pin_data]
+ //! struct Foo {
+ //!     #[pin]
+ //!     a: CMutex<usize>,
+ //!     b: u32,
+ //! }
+ //!
+ //! let foo = pin_init!(Foo {
+ //!     a <- CMutex::new(42),
+ //!     b: 24,
+ //! });
+ //! # let _ = Box::pin_init(foo);
+ //! ```
+ //!
+ //! `foo` now is of the type [`impl PinInit<Foo>`]. We can now use any smart pointer that we like
+ //! (or just the stack) to actually initialize a `Foo`:
+ //!
+ //! ```rust
+ //! # #![expect(clippy::disallowed_names)]
+ //! # #![feature(allocator_api)]
+ //! # #[path = "../examples/mutex.rs"] mod mutex; use mutex::*;
+ //! # use core::{alloc::AllocError, pin::Pin};
+ //! # use pin_init::*;
+ //! #
+ //! # #[pin_data]
+ //! # struct Foo {
+ //! #     #[pin]
+ //! #     a: CMutex<usize>,
+ //! #     b: u32,
+ //! # }
+ //! #
+ //! # let foo = pin_init!(Foo {
+ //! #     a <- CMutex::new(42),
+ //! #     b: 24,
+ //! # });
+ //! let foo: Result<Pin<Box<Foo>>, AllocError> = Box::pin_init(foo);
+ //! ```
+ //!
+ //! For more information see the [`pin_init!`] macro.
+ //!
+ //! ## Using a custom function/macro that returns an initializer
+ //!
+ //! Many types that use this library supply a function/macro that returns an initializer, because
+ //! the above method only works for types where you can access the fields.
+ //!
+ //! ```rust
+ //! # #![feature(allocator_api)]
+ //! # #[path = "../examples/mutex.rs"] mod mutex; use mutex::*;
+ //! # use pin_init::*;
+ //! # use std::sync::Arc;
+ //! # use core::pin::Pin;
+ //! let mtx: Result<Pin<Arc<CMutex<usize>>>, _> = Arc::pin_init(CMutex::new(42));
+ //! ```
+ //!
+ //! To declare an init macro/function you just return an [`impl PinInit<T, E>`]:
+ //!
+ //! ```rust
+ //! # #![feature(allocator_api)]
+ //! # use pin_init::*;
+ //! # #[path = "../examples/error.rs"] mod error; use error::Error;
+ //! # #[path = "../examples/mutex.rs"] mod mutex; use mutex::*;
+ //! #[pin_data]
+ //! struct DriverData {
+ //!     #[pin]
+ //!     status: CMutex<i32>,
+ //!     buffer: Box<[u8; 1_000_000]>,
+ //! }
+ //!
+ //! impl DriverData {
+ //!     fn new() -> impl PinInit<Self, Error> {
+ //!         try_pin_init!(Self {
+ //!             status <- CMutex::new(0),
+ //!             buffer: Box::init(pin_init::zeroed())?,
+ //!         }? Error)
+ //!     }
+ //! }
+ //! ```
+ //!
+ //! ## Manual creation of an initializer
+ //!
+ //! Often when working with primitives the previous approaches are not sufficient. That is where
+ //! [`pin_init_from_closure()`] comes in. This `unsafe` function allows you to create a
+ //! [`impl PinInit<T, E>`] directly from a closure. Of course you have to ensure that the closure
+ //! actually does the initialization in the correct way. Here are the things to look out for
+ //! (we are calling the parameter to the closure `slot`):
+ //! - when the closure returns `Ok(())`, then it has completed the initialization successfully, so
+ //!   `slot` now contains a valid bit pattern for the type `T`,
+ //! - when the closure returns `Err(e)`, then the caller may deallocate the memory at `slot`, so
+ //!   you need to take care to clean up anything if your initialization fails mid-way,
+ //! - you may assume that `slot` will stay pinned even after the closure returns until `drop` of
+ //!   `slot` gets called.
+ //!
+ //! ```rust
+ //! # #![feature(extern_types)]
+ //! use pin_init::{pin_data, pinned_drop, PinInit, PinnedDrop, pin_init_from_closure};
+ //! use core::{
+ //!     ptr::addr_of_mut,
+ //!     marker::PhantomPinned,
+ //!     cell::UnsafeCell,
+ //!     pin::Pin,
+ //!     mem::MaybeUninit,
+ //! };
+ //! mod bindings {
+ //!     #[repr(C)]
+ //!     pub struct foo {
+ //!         /* fields from C ... */
+ //!     }
+ //!     extern "C" {
+ //!         pub fn init_foo(ptr: *mut foo);
+ //!         pub fn destroy_foo(ptr: *mut foo);
+ //!         #[must_use = "you must check the error return code"]
+ //!         pub fn enable_foo(ptr: *mut foo, flags: u32) -> i32;
+ //!     }
+ //! }
+ //!
+ //! /// # Invariants
+ //! ///
+ //! /// `foo` is always initialized
+ //! #[pin_data(PinnedDrop)]
+ //! pub struct RawFoo {
+ //!     #[pin]
+ //!     _p: PhantomPinned,
+ //!     #[pin]
+ //!     foo: UnsafeCell<MaybeUninit<bindings::foo>>,
+ //! }
+ //!
+ //! impl RawFoo {
+ //!     pub fn new(flags: u32) -> impl PinInit<Self, i32> {
+ //!         // SAFETY:
+ //!         // - when the closure returns `Ok(())`, then it has successfully initialized and
+ //!         //   enabled `foo`,
+ //!         // - when it returns `Err(e)`, then it has cleaned up before
+ //!         unsafe {
+ //!             pin_init_from_closure(move |slot: *mut Self| {
+ //!                 // `slot` contains uninit memory, avoid creating a reference.
+ //!                 let foo = addr_of_mut!((*slot).foo);
+ //!                 let foo = UnsafeCell::raw_get(foo).cast::<bindings::foo>();
+ //!
+ //!                 // Initialize the `foo`
+ //!                 bindings::init_foo(foo);
+ //!
+ //!                 // Try to enable it.
+ //!                 let err = bindings::enable_foo(foo, flags);
+ //!                 if err != 0 {
+ //!                     // Enabling has failed, first clean up the foo and then return the error.
+ //!                     bindings::destroy_foo(foo);
+ //!                     Err(err)
+ //!                 } else {
+ //!                     // All fields of `RawFoo` have been initialized, since `_p` is a ZST.
+ //!                     Ok(())
+ //!                 }
+ //!             })
+ //!         }
+ //!     }
+ //! }
+ //!
+ //! #[pinned_drop]
+ //! impl PinnedDrop for RawFoo {
+ //!     fn drop(self: Pin<&mut Self>) {
+ //!         // SAFETY: Since `foo` is initialized, destroying is safe.
+ //!         unsafe { bindings::destroy_foo(self.foo.get().cast::<bindings::foo>()) };
+ //!     }
+ //! }
+ //! ```
+ //!
+ //! For more information on how to use [`pin_init_from_closure()`], take a look at the uses inside
+ //! the `kernel` crate. The [`sync`] module is a good starting point.
+ //!
+ //! [`sync`]: https://rust.docs.kernel.org/kernel/sync/index.html
+ //! [pinning]: https://doc.rust-lang.org/std/pin/index.html
+ //! [structurally pinned fields]:
+ //!     https://doc.rust-lang.org/std/pin/index.html#pinning-is-structural-for-field
+ //! [stack]: crate::stack_pin_init
+ #![cfg_attr(
+     kernel,
+     doc = "[`Arc<T>`]: https://rust.docs.kernel.org/kernel/sync/struct.Arc.html"
+ )]
+ #![cfg_attr(
+     kernel,
+     doc = "[`Box<T>`]: https://rust.docs.kernel.org/kernel/alloc/kbox/struct.Box.html"
+ )]
+ #![cfg_attr(not(kernel), doc = "[`Arc<T>`]: alloc::alloc::sync::Arc")]
+ #![cfg_attr(not(kernel), doc = "[`Box<T>`]: alloc::alloc::boxed::Box")]
+ //! [`impl PinInit<Foo>`]: crate::PinInit
+ //! [`impl PinInit<T, E>`]: crate::PinInit
+ //! [`impl Init<T, E>`]: crate::Init
+ //! [Rust-for-Linux]: https://rust-for-linux.com/
+ 
+ #![cfg_attr(not(RUSTC_LINT_REASONS_IS_STABLE), feature(lint_reasons))]
+ #![cfg_attr(
+     all(
+         any(feature = "alloc", feature = "std"),
+         not(RUSTC_NEW_UNINIT_IS_STABLE)
+     ),
+     feature(new_uninit)
+ )]
+ #![forbid(missing_docs, unsafe_op_in_unsafe_fn)]
+ #![cfg_attr(not(feature = "std"), no_std)]
+ #![cfg_attr(feature = "alloc", feature(allocator_api))]
+ 
+ use core::{
+     cell::UnsafeCell,
+     convert::Infallible,
+     marker::PhantomData,
+     mem::MaybeUninit,
+     num::*,
+     pin::Pin,
+     ptr::{self, NonNull},
+ };
+ 
+ #[doc(hidden)]
+ pub mod __internal;
+ #[doc(hidden)]
+ pub mod macros;
+ 
+ #[cfg(any(feature = "std", feature = "alloc"))]
+ mod alloc;
+ #[cfg(any(feature = "std", feature = "alloc"))]
+ pub use alloc::InPlaceInit;
+ 
+ /// Used to specify the pinning information of the fields of a struct.
+ ///
+ /// This is somewhat similar in purpose as
+ /// [pin-project-lite](https://crates.io/crates/pin-project-lite).
+ /// Place this macro on a struct definition and then `#[pin]` in front of the attributes of each
+ /// field you want to structurally pin.
+ ///
+ /// This macro enables the use of the [`pin_init!`] macro. When pin-initializing a `struct`,
+ /// then `#[pin]` directs the type of initializer that is required.
+ ///
+ /// If your `struct` implements `Drop`, then you need to add `PinnedDrop` as arguments to this
+ /// macro, and change your `Drop` implementation to `PinnedDrop` annotated with
+ /// `#[`[`macro@pinned_drop`]`]`, since dropping pinned values requires extra care.
+ ///
+ /// # Examples
+ ///
+ /// ```
+ /// # #![feature(allocator_api)]
+ /// # #[path = "../examples/mutex.rs"] mod mutex; use mutex::*;
+ /// use pin_init::pin_data;
+ ///
+ /// enum Command {
+ ///     /* ... */
+ /// }
+ ///
+ /// #[pin_data]
+ /// struct DriverData {
+ ///     #[pin]
+ ///     queue: CMutex<Vec<Command>>,
+ ///     buf: Box<[u8; 1024 * 1024]>,
+ /// }
+ /// ```
+ ///
+ /// ```
+ /// # #![feature(allocator_api)]
+ /// # #[path = "../examples/mutex.rs"] mod mutex; use mutex::*;
+ /// # mod bindings { pub struct info; pub unsafe fn destroy_info(_: *mut info) {} }
+ /// use core::pin::Pin;
+ /// use pin_init::{pin_data, pinned_drop, PinnedDrop};
+ ///
+ /// enum Command {
+ ///     /* ... */
+ /// }
+ ///
+ /// #[pin_data(PinnedDrop)]
+ /// struct DriverData {
+ ///     #[pin]
+ ///     queue: CMutex<Vec<Command>>,
+ ///     buf: Box<[u8; 1024 * 1024]>,
+ ///     raw_info: *mut bindings::info,
+ /// }
+ ///
+ /// #[pinned_drop]
+ /// impl PinnedDrop for DriverData {
+ ///     fn drop(self: Pin<&mut Self>) {
+ ///         unsafe { bindings::destroy_info(self.raw_info) };
+ ///     }
+ /// }
+ /// ```
+ pub use ::pin_init_internal::pin_data;
+ 
+ /// Used to implement `PinnedDrop` safely.
+ ///
+ /// Only works on structs that are annotated via `#[`[`macro@pin_data`]`]`.
+ ///
+ /// # Examples
+ ///
+ /// ```
+ /// # #![feature(allocator_api)]
+ /// # #[path = "../examples/mutex.rs"] mod mutex; use mutex::*;
+ /// # mod bindings { pub struct info; pub unsafe fn destroy_info(_: *mut info) {} }
+ /// use core::pin::Pin;
+ /// use pin_init::{pin_data, pinned_drop, PinnedDrop};
+ ///
+ /// enum Command {
+ ///     /* ... */
+ /// }
+ ///
+ /// #[pin_data(PinnedDrop)]
+ /// struct DriverData {
+ ///     #[pin]
+ ///     queue: CMutex<Vec<Command>>,
+ ///     buf: Box<[u8; 1024 * 1024]>,
+ ///     raw_info: *mut bindings::info,
+ /// }
+ ///
+ /// #[pinned_drop]
+ /// impl PinnedDrop for DriverData {
+ ///     fn drop(self: Pin<&mut Self>) {
+ ///         unsafe { bindings::destroy_info(self.raw_info) };
+ ///     }
+ /// }
+ /// ```
+ pub use ::pin_init_internal::pinned_drop;
+ 
+ /// Derives the [`Zeroable`] trait for the given struct.
+ ///
+ /// This can only be used for structs where every field implements the [`Zeroable`] trait.
+ ///
+ /// # Examples
+ ///
+ /// ```
+ /// use pin_init::Zeroable;
+ ///
+ /// #[derive(Zeroable)]
+ /// pub struct DriverData {
+ ///     id: i64,
+ ///     buf_ptr: *mut u8,
+ ///     len: usize,
+ /// }
+ /// ```
+ pub use ::pin_init_internal::Zeroable;
+ 
+ /// Initialize and pin a type directly on the stack.
+ ///
+ /// # Examples
+ ///
+ /// ```rust
+ /// # #![expect(clippy::disallowed_names)]
+ /// # #![feature(allocator_api)]
+ /// # #[path = "../examples/mutex.rs"] mod mutex; use mutex::*;
+ /// # use pin_init::*;
+ /// # use core::pin::Pin;
+ /// #[pin_data]
+ /// struct Foo {
+ ///     #[pin]
+ ///     a: CMutex<usize>,
+ ///     b: Bar,
+ /// }
+ ///
+ /// #[pin_data]
+ /// struct Bar {
+ ///     x: u32,
+ /// }
+ ///
+ /// stack_pin_init!(let foo = pin_init!(Foo {
+ ///     a <- CMutex::new(42),
+ ///     b: Bar {
+ ///         x: 64,
+ ///     },
+ /// }));
+ /// let foo: Pin<&mut Foo> = foo;
+ /// println!("a: {}", &*foo.a.lock());
+ /// ```
+ ///
+ /// # Syntax
+ ///
+ /// A normal `let` binding with optional type annotation. The expression is expected to implement
+ /// [`PinInit`]/[`Init`] with the error type [`Infallible`]. If you want to use a different error
+ /// type, then use [`stack_try_pin_init!`].
+ #[macro_export]
+ macro_rules! stack_pin_init {
+     (let $var:ident $(: $t:ty)? = $val:expr) => {
+         let val = $val;
+         let mut $var = ::core::pin::pin!($crate::__internal::StackInit$(::<$t>)?::uninit());
+         let mut $var = match $crate::__internal::StackInit::init($var, val) {
+             Ok(res) => res,
+             Err(x) => {
+                 let x: ::core::convert::Infallible = x;
+                 match x {}
+             }
+         };
+     };
+ }
+ 
+ /// Initialize and pin a type directly on the stack.
+ ///
+ /// # Examples
+ ///
+ /// ```rust
+ /// # #![expect(clippy::disallowed_names)]
+ /// # #![feature(allocator_api)]
+ /// # #[path = "../examples/error.rs"] mod error; use error::Error;
+ /// # #[path = "../examples/mutex.rs"] mod mutex; use mutex::*;
+ /// # use pin_init::*;
+ /// #[pin_data]
+ /// struct Foo {
+ ///     #[pin]
+ ///     a: CMutex<usize>,
+ ///     b: Box<Bar>,
+ /// }
+ ///
+ /// struct Bar {
+ ///     x: u32,
+ /// }
+ ///
+ /// stack_try_pin_init!(let foo: Foo = try_pin_init!(Foo {
+ ///     a <- CMutex::new(42),
+ ///     b: Box::try_new(Bar {
+ ///         x: 64,
+ ///     })?,
+ /// }? Error));
+ /// let foo = foo.unwrap();
+ /// println!("a: {}", &*foo.a.lock());
+ /// ```
+ ///
+ /// ```rust
+ /// # #![expect(clippy::disallowed_names)]
+ /// # #![feature(allocator_api)]
+ /// # #[path = "../examples/error.rs"] mod error; use error::Error;
+ /// # #[path = "../examples/mutex.rs"] mod mutex; use mutex::*;
+ /// # use pin_init::*;
+ /// #[pin_data]
+ /// struct Foo {
+ ///     #[pin]
+ ///     a: CMutex<usize>,
+ ///     b: Box<Bar>,
+ /// }
+ ///
+ /// struct Bar {
+ ///     x: u32,
+ /// }
+ ///
+ /// stack_try_pin_init!(let foo: Foo =? try_pin_init!(Foo {
+ ///     a <- CMutex::new(42),
+ ///     b: Box::try_new(Bar {
+ ///         x: 64,
+ ///     })?,
+ /// }? Error));
+ /// println!("a: {}", &*foo.a.lock());
+ /// # Ok::<_, Error>(())
+ /// ```
+ ///
+ /// # Syntax
+ ///
+ /// A normal `let` binding with optional type annotation. The expression is expected to implement
+ /// [`PinInit`]/[`Init`]. This macro assigns a result to the given variable, adding a `?` after the
+ /// `=` will propagate this error.
+ #[macro_export]
+ macro_rules! stack_try_pin_init {
+     (let $var:ident $(: $t:ty)? = $val:expr) => {
+         let val = $val;
+         let mut $var = ::core::pin::pin!($crate::__internal::StackInit$(::<$t>)?::uninit());
+         let mut $var = $crate::__internal::StackInit::init($var, val);
+     };
+     (let $var:ident $(: $t:ty)? =? $val:expr) => {
+         let val = $val;
+         let mut $var = ::core::pin::pin!($crate::__internal::StackInit$(::<$t>)?::uninit());
+         let mut $var = $crate::__internal::StackInit::init($var, val)?;
+     };
+ }
+ 
+ /// Construct an in-place, pinned initializer for `struct`s.
+ ///
+ /// This macro defaults the error to [`Infallible`]. If you need a different error, then use
+ /// [`try_pin_init!`].
+ ///
+ /// The syntax is almost identical to that of a normal `struct` initializer:
+ ///
+ /// ```rust
+ /// # use pin_init::*;
+ /// # use core::pin::Pin;
+ /// #[pin_data]
+ /// struct Foo {
+ ///     a: usize,
+ ///     b: Bar,
+ /// }
+ ///
+ /// #[pin_data]
+ /// struct Bar {
+ ///     x: u32,
+ /// }
+ ///
+ /// # fn demo() -> impl PinInit<Foo> {
+ /// let a = 42;
+ ///
+ /// let initializer = pin_init!(Foo {
+ ///     a,
+ ///     b: Bar {
+ ///         x: 64,
+ ///     },
+ /// });
+ /// # initializer }
+ /// # Box::pin_init(demo()).unwrap();
+ /// ```
+ ///
+ /// Arbitrary Rust expressions can be used to set the value of a variable.
+ ///
+ /// The fields are initialized in the order that they appear in the initializer. So it is possible
+ /// to read already initialized fields using raw pointers.
+ ///
+ /// IMPORTANT: You are not allowed to create references to fields of the struct inside of the
+ /// initializer.
+ ///
+ /// # Init-functions
+ ///
+ /// When working with this library it is often desired to let others construct your types without
+ /// giving access to all fields. This is where you would normally write a plain function `new` that
+ /// would return a new instance of your type. With this library that is also possible. However,
+ /// there are a few extra things to keep in mind.
+ ///
+ /// To create an initializer function, simply declare it like this:
+ ///
+ /// ```rust
+ /// # use pin_init::*;
+ /// # use core::pin::Pin;
+ /// # #[pin_data]
+ /// # struct Foo {
+ /// #     a: usize,
+ /// #     b: Bar,
+ /// # }
+ /// # #[pin_data]
+ /// # struct Bar {
+ /// #     x: u32,
+ /// # }
+ /// impl Foo {
+ ///     fn new() -> impl PinInit<Self> {
+ ///         pin_init!(Self {
+ ///             a: 42,
+ ///             b: Bar {
+ ///                 x: 64,
+ ///             },
+ ///         })
+ ///     }
+ /// }
+ /// ```
+ ///
+ /// Users of `Foo` can now create it like this:
+ ///
+ /// ```rust
+ /// # #![expect(clippy::disallowed_names)]
+ /// # use pin_init::*;
+ /// # use core::pin::Pin;
+ /// # #[pin_data]
+ /// # struct Foo {
+ /// #     a: usize,
+ /// #     b: Bar,
+ /// # }
+ /// # #[pin_data]
+ /// # struct Bar {
+ /// #     x: u32,
+ /// # }
+ /// # impl Foo {
+ /// #     fn new() -> impl PinInit<Self> {
+ /// #         pin_init!(Self {
+ /// #             a: 42,
+ /// #             b: Bar {
+ /// #                 x: 64,
+ /// #             },
+ /// #         })
+ /// #     }
+ /// # }
+ /// let foo = Box::pin_init(Foo::new());
+ /// ```
+ ///
+ /// They can also easily embed it into their own `struct`s:
+ ///
+ /// ```rust
+ /// # use pin_init::*;
+ /// # use core::pin::Pin;
+ /// # #[pin_data]
+ /// # struct Foo {
+ /// #     a: usize,
+ /// #     b: Bar,
+ /// # }
+ /// # #[pin_data]
+ /// # struct Bar {
+ /// #     x: u32,
+ /// # }
+ /// # impl Foo {
+ /// #     fn new() -> impl PinInit<Self> {
+ /// #         pin_init!(Self {
+ /// #             a: 42,
+ /// #             b: Bar {
+ /// #                 x: 64,
+ /// #             },
+ /// #         })
+ /// #     }
+ /// # }
+ /// #[pin_data]
+ /// struct FooContainer {
+ ///     #[pin]
+ ///     foo1: Foo,
+ ///     #[pin]
+ ///     foo2: Foo,
+ ///     other: u32,
+ /// }
+ ///
+ /// impl FooContainer {
+ ///     fn new(other: u32) -> impl PinInit<Self> {
+ ///         pin_init!(Self {
+ ///             foo1 <- Foo::new(),
+ ///             foo2 <- Foo::new(),
+ ///             other,
+ ///         })
+ ///     }
+ /// }
+ /// ```
+ ///
+ /// Here we see that when using `pin_init!` with `PinInit`, one needs to write `<-` instead of `:`.
+ /// This signifies that the given field is initialized in-place. As with `struct` initializers, just
+ /// writing the field (in this case `other`) without `:` or `<-` means `other: other,`.
+ ///
+ /// # Syntax
+ ///
+ /// As already mentioned in the examples above, inside of `pin_init!` a `struct` initializer with
+ /// the following modifications is expected:
+ /// - Fields that you want to initialize in-place have to use `<-` instead of `:`.
+ /// - In front of the initializer you can write `&this in` to have access to a [`NonNull<Self>`]
+ ///   pointer named `this` inside of the initializer.
+ /// - Using struct update syntax one can place `..Zeroable::zeroed()` at the very end of the
+ ///   struct, this initializes every field with 0 and then runs all initializers specified in the
+ ///   body. This can only be done if [`Zeroable`] is implemented for the struct.
+ ///
+ /// For instance:
+ ///
+ /// ```rust
+ /// # use pin_init::*;
+ /// # use core::{ptr::addr_of_mut, marker::PhantomPinned};
+ /// #[pin_data]
+ /// #[derive(Zeroable)]
+ /// struct Buf {
+ ///     // `ptr` points into `buf`.
+ ///     ptr: *mut u8,
+ ///     buf: [u8; 64],
+ ///     #[pin]
+ ///     pin: PhantomPinned,
+ /// }
+ ///
+ /// let init = pin_init!(&this in Buf {
+ ///     buf: [0; 64],
+ ///     // SAFETY: TODO.
+ ///     ptr: unsafe { addr_of_mut!((*this.as_ptr()).buf).cast() },
+ ///     pin: PhantomPinned,
+ /// });
+ /// let init = pin_init!(Buf {
+ ///     buf: [1; 64],
+ ///     ..Zeroable::zeroed()
+ /// });
+ /// ```
+ ///
+ /// [`NonNull<Self>`]: core::ptr::NonNull
+ // For a detailed example of how this macro works, see the module documentation of the hidden
+ // module `macros` inside of `macros.rs`.
+ #[macro_export]
+ macro_rules! pin_init {
+     ($(&$this:ident in)? $t:ident $(::<$($generics:ty),* $(,)?>)? {
+         $($fields:tt)*
+     }) => {
+         $crate::try_pin_init!($(&$this in)? $t $(::<$($generics),*>)? {
+             $($fields)*
+         }? ::core::convert::Infallible)
+     };
+ }
+ 
+ /// Construct an in-place, fallible pinned initializer for `struct`s.
+ ///
+ /// If the initialization can complete without error (or [`Infallible`]), then use [`pin_init!`].
+ ///
+ /// You can use the `?` operator or use `return Err(err)` inside the initializer to stop
+ /// initialization and return the error.
+ ///
+ /// IMPORTANT: if you have `unsafe` code inside of the initializer you have to ensure that when
+ /// initialization fails, the memory can be safely deallocated without any further modifications.
+ ///
+ /// The syntax is identical to [`pin_init!`] with the following exception: you must append `? $type`
+ /// after the `struct` initializer to specify the error type you want to use.
+ ///
+ /// # Examples
+ ///
+ /// ```rust
+ /// # #![feature(allocator_api)]
+ /// # #[path = "../examples/error.rs"] mod error; use error::Error;
+ /// use pin_init::{pin_data, try_pin_init, PinInit, InPlaceInit, zeroed};
+ ///
+ /// #[pin_data]
+ /// struct BigBuf {
+ ///     big: Box<[u8; 1024 * 1024 * 1024]>,
+ ///     small: [u8; 1024 * 1024],
+ ///     ptr: *mut u8,
+ /// }
+ ///
+ /// impl BigBuf {
+ ///     fn new() -> impl PinInit<Self, Error> {
+ ///         try_pin_init!(Self {
+ ///             big: Box::init(zeroed())?,
+ ///             small: [0; 1024 * 1024],
+ ///             ptr: core::ptr::null_mut(),
+ ///         }? Error)
+ ///     }
+ /// }
+ /// # let _ = Box::pin_init(BigBuf::new());
+ /// ```
+ // For a detailed example of how this macro works, see the module documentation of the hidden
+ // module `macros` inside of `macros.rs`.
+ #[macro_export]
+ macro_rules! try_pin_init {
+     ($(&$this:ident in)? $t:ident $(::<$($generics:ty),* $(,)?>)? {
+         $($fields:tt)*
+     }? $err:ty) => {
+         $crate::__init_internal!(
+             @this($($this)?),
+             @typ($t $(::<$($generics),*>)? ),
+             @fields($($fields)*),
+             @error($err),
+             @data(PinData, use_data),
+             @has_data(HasPinData, __pin_data),
+             @construct_closure(pin_init_from_closure),
+             @munch_fields($($fields)*),
+         )
+     }
+ }
+ 
+ /// Construct an in-place initializer for `struct`s.
+ ///
+ /// This macro defaults the error to [`Infallible`]. If you need a different error, then use
+ /// [`try_init!`].
+ ///
+ /// The syntax is identical to [`pin_init!`] and its safety caveats also apply:
+ /// - `unsafe` code must guarantee either full initialization or return an error and allow
+ ///   deallocation of the memory.
+ /// - the fields are initialized in the order given in the initializer.
+ /// - no references to fields are allowed to be created inside of the initializer.
+ ///
+ /// This initializer is for initializing data in-place that might later be moved. If you want to
+ /// pin-initialize, use [`pin_init!`].
+ ///
+ /// # Examples
+ ///
+ /// ```rust
+ /// # #![feature(allocator_api)]
+ /// # #[path = "../examples/error.rs"] mod error; use error::Error;
+ /// # #[path = "../examples/mutex.rs"] mod mutex; use mutex::*;
+ /// # use pin_init::InPlaceInit;
+ /// use pin_init::{init, Init, zeroed};
+ ///
+ /// struct BigBuf {
+ ///     small: [u8; 1024 * 1024],
+ /// }
+ ///
+ /// impl BigBuf {
+ ///     fn new() -> impl Init<Self> {
+ ///         init!(Self {
+ ///             small <- zeroed(),
+ ///         })
+ ///     }
+ /// }
+ /// # let _ = Box::init(BigBuf::new());
+ /// ```
+ // For a detailed example of how this macro works, see the module documentation of the hidden
+ // module `macros` inside of `macros.rs`.
+ #[macro_export]
+ macro_rules! init {
+     ($(&$this:ident in)? $t:ident $(::<$($generics:ty),* $(,)?>)? {
+         $($fields:tt)*
+     }) => {
+         $crate::try_init!($(&$this in)? $t $(::<$($generics),*>)? {
+             $($fields)*
+         }? ::core::convert::Infallible)
+     }
+ }
+ 
+ /// Construct an in-place fallible initializer for `struct`s.
+ ///
+ /// If the initialization can complete without error (or [`Infallible`]), then use
+ /// [`init!`].
+ ///
+ /// The syntax is identical to [`try_pin_init!`]. You need to specify a custom error
+ /// via `? $type` after the `struct` initializer.
+ /// The safety caveats from [`try_pin_init!`] also apply:
+ /// - `unsafe` code must guarantee either full initialization or return an error and allow
+ ///   deallocation of the memory.
+ /// - the fields are initialized in the order given in the initializer.
+ /// - no references to fields are allowed to be created inside of the initializer.
+ ///
+ /// # Examples
+ ///
+ /// ```rust
+ /// # #![feature(allocator_api)]
+ /// # use core::alloc::AllocError;
+ /// # use pin_init::InPlaceInit;
+ /// use pin_init::{try_init, Init, zeroed};
+ ///
+ /// struct BigBuf {
+ ///     big: Box<[u8; 1024 * 1024 * 1024]>,
+ ///     small: [u8; 1024 * 1024],
+ /// }
+ ///
+ /// impl BigBuf {
+ ///     fn new() -> impl Init<Self, AllocError> {
+ ///         try_init!(Self {
+ ///             big: Box::init(zeroed())?,
+ ///             small: [0; 1024 * 1024],
+ ///         }? AllocError)
+ ///     }
+ /// }
+ /// # let _ = Box::init(BigBuf::new());
+ /// ```
+ // For a detailed example of how this macro works, see the module documentation of the hidden
+ // module `macros` inside of `macros.rs`.
+ #[macro_export]
+ macro_rules! try_init {
+     ($(&$this:ident in)? $t:ident $(::<$($generics:ty),* $(,)?>)? {
+         $($fields:tt)*
+     }? $err:ty) => {
+         $crate::__init_internal!(
+             @this($($this)?),
+             @typ($t $(::<$($generics),*>)?),
+             @fields($($fields)*),
+             @error($err),
+             @data(InitData, /*no use_data*/),
+             @has_data(HasInitData, __init_data),
+             @construct_closure(init_from_closure),
+             @munch_fields($($fields)*),
+         )
+     }
+ }
+ 
+ /// Asserts that a field on a struct using `#[pin_data]` is marked with `#[pin]` ie. that it is
+ /// structurally pinned.
+ ///
+ /// # Example
+ ///
+ /// This will succeed:
+ /// ```
+ /// use pin_init::{pin_data, assert_pinned};
+ ///
+ /// #[pin_data]
+ /// struct MyStruct {
+ ///     #[pin]
+ ///     some_field: u64,
+ /// }
+ ///
+ /// assert_pinned!(MyStruct, some_field, u64);
+ /// ```
+ ///
+ /// This will fail:
+ /// ```compile_fail
+ /// use pin_init::{pin_data, assert_pinned};
+ ///
+ /// #[pin_data]
+ /// struct MyStruct {
+ ///     some_field: u64,
+ /// }
+ ///
+ /// assert_pinned!(MyStruct, some_field, u64);
+ /// ```
+ ///
+ /// Some uses of the macro may trigger the `can't use generic parameters from outer item` error. To
+ /// work around this, you may pass the `inline` parameter to the macro. The `inline` parameter can
+ /// only be used when the macro is invoked from a function body.
+ /// ```
+ /// # use core::pin::Pin;
+ /// use pin_init::{pin_data, assert_pinned};
+ ///
+ /// #[pin_data]
+ /// struct Foo<T> {
+ ///     #[pin]
+ ///     elem: T,
+ /// }
+ ///
+ /// impl<T> Foo<T> {
+ ///     fn project(self: Pin<&mut Self>) -> Pin<&mut T> {
+ ///         assert_pinned!(Foo<T>, elem, T, inline);
+ ///
+ ///         // SAFETY: The field is structurally pinned.
+ ///         unsafe { self.map_unchecked_mut(|me| &mut me.elem) }
+ ///     }
+ /// }
+ /// ```
+ #[macro_export]
+ macro_rules! assert_pinned {
+     ($ty:ty, $field:ident, $field_ty:ty, inline) => {
+         let _ = move |ptr: *mut $field_ty| {
+             // SAFETY: This code is unreachable.
+             let data = unsafe { <$ty as $crate::__internal::HasPinData>::__pin_data() };
+             let init = $crate::__internal::AlwaysFail::<$field_ty>::new();
+             // SAFETY: This code is unreachable.
+             unsafe { data.$field(ptr, init) }.ok();
+         };
+     };
+ 
+     ($ty:ty, $field:ident, $field_ty:ty) => {
+         const _: () = {
+             $crate::assert_pinned!($ty, $field, $field_ty, inline);
+         };
+     };
+ }
+ 
+ /// A pin-initializer for the type `T`.
+ ///
+ /// To use this initializer, you will need a suitable memory location that can hold a `T`. This can
+ /// be [`Box<T>`], [`Arc<T>`] or even the stack (see [`stack_pin_init!`]).
+ ///
+ /// Also see the [module description](self).
+ ///
+ /// # Safety
+ ///
+ /// When implementing this trait you will need to take great care. Also there are probably very few
+ /// cases where a manual implementation is necessary. Use [`pin_init_from_closure`] where possible.
+ ///
+ /// The [`PinInit::__pinned_init`] function:
+ /// - returns `Ok(())` if it initialized every field of `slot`,
+ /// - returns `Err(err)` if it encountered an error and then cleaned `slot`, this means:
+ ///     - `slot` can be deallocated without UB occurring,
+ ///     - `slot` does not need to be dropped,
+ ///     - `slot` is not partially initialized.
+ /// - while constructing the `T` at `slot` it upholds the pinning invariants of `T`.
+ ///
+ #[cfg_attr(
+     kernel,
+     doc = "[`Arc<T>`]: https://rust.docs.kernel.org/kernel/sync/struct.Arc.html"
+ )]
+ #[cfg_attr(
+     kernel,
+     doc = "[`Box<T>`]: https://rust.docs.kernel.org/kernel/alloc/kbox/struct.Box.html"
+ )]
+ #[cfg_attr(not(kernel), doc = "[`Arc<T>`]: alloc::alloc::sync::Arc")]
+ #[cfg_attr(not(kernel), doc = "[`Box<T>`]: alloc::alloc::boxed::Box")]
+ #[must_use = "An initializer must be used in order to create its value."]
+ pub unsafe trait PinInit<T: ?Sized, E = Infallible>: Sized {
+     /// Initializes `slot`.
+     ///
+     /// # Safety
+     ///
+     /// - `slot` is a valid pointer to uninitialized memory.
+     /// - the caller does not touch `slot` when `Err` is returned, they are only permitted to
+     ///   deallocate.
+     /// - `slot` will not move until it is dropped, i.e. it will be pinned.
+     unsafe fn __pinned_init(self, slot: *mut T) -> Result<(), E>;
+ 
+     /// First initializes the value using `self` then calls the function `f` with the initialized
+     /// value.
+     ///
+     /// If `f` returns an error the value is dropped and the initializer will forward the error.
+     ///
+     /// # Examples
+     ///
+     /// ```rust
+     /// # #![feature(allocator_api)]
+     /// # #[path = "../examples/mutex.rs"] mod mutex; use mutex::*;
+     /// # use pin_init::*;
+     /// let mtx_init = CMutex::new(42);
+     /// // Make the initializer print the value.
+     /// let mtx_init = mtx_init.pin_chain(|mtx| {
+     ///     println!("{:?}", mtx.get_data_mut());
+     ///     Ok(())
+     /// });
+     /// ```
+     fn pin_chain<F>(self, f: F) -> ChainPinInit<Self, F, T, E>
+     where
+         F: FnOnce(Pin<&mut T>) -> Result<(), E>,
+     {
+         ChainPinInit(self, f, PhantomData)
+     }
+ }
+ 
+ /// An initializer returned by [`PinInit::pin_chain`].
+ pub struct ChainPinInit<I, F, T: ?Sized, E>(I, F, __internal::Invariant<(E, T)>);
+ 
+ // SAFETY: The `__pinned_init` function is implemented such that it
+ // - returns `Ok(())` on successful initialization,
+ // - returns `Err(err)` on error and in this case `slot` will be dropped.
+ // - considers `slot` pinned.
+ unsafe impl<T: ?Sized, E, I, F> PinInit<T, E> for ChainPinInit<I, F, T, E>
+ where
+     I: PinInit<T, E>,
+     F: FnOnce(Pin<&mut T>) -> Result<(), E>,
+ {
+     unsafe fn __pinned_init(self, slot: *mut T) -> Result<(), E> {
+         // SAFETY: All requirements fulfilled since this function is `__pinned_init`.
+         unsafe { self.0.__pinned_init(slot)? };
+         // SAFETY: The above call initialized `slot` and we still have unique access.
+         let val = unsafe { &mut *slot };
+         // SAFETY: `slot` is considered pinned.
+         let val = unsafe { Pin::new_unchecked(val) };
+         // SAFETY: `slot` was initialized above.
+         (self.1)(val).inspect_err(|_| unsafe { core::ptr::drop_in_place(slot) })
+     }
+ }
+ 
+ /// An initializer for `T`.
+ ///
+ /// To use this initializer, you will need a suitable memory location that can hold a `T`. This can
+ /// be [`Box<T>`], [`Arc<T>`] or even the stack (see [`stack_pin_init!`]). Because
+ /// [`PinInit<T, E>`] is a super trait, you can use every function that takes it as well.
+ ///
+ /// Also see the [module description](self).
+ ///
+ /// # Safety
+ ///
+ /// When implementing this trait you will need to take great care. Also there are probably very few
+ /// cases where a manual implementation is necessary. Use [`init_from_closure`] where possible.
+ ///
+ /// The [`Init::__init`] function:
+ /// - returns `Ok(())` if it initialized every field of `slot`,
+ /// - returns `Err(err)` if it encountered an error and then cleaned `slot`, this means:
+ ///     - `slot` can be deallocated without UB occurring,
+ ///     - `slot` does not need to be dropped,
+ ///     - `slot` is not partially initialized.
+ /// - while constructing the `T` at `slot` it upholds the pinning invariants of `T`.
+ ///
+ /// The `__pinned_init` function from the supertrait [`PinInit`] needs to execute the exact same
+ /// code as `__init`.
+ ///
+ /// Contrary to its supertype [`PinInit<T, E>`] the caller is allowed to
+ /// move the pointee after initialization.
+ ///
+ #[cfg_attr(
+     kernel,
+     doc = "[`Arc<T>`]: https://rust.docs.kernel.org/kernel/sync/struct.Arc.html"
+ )]
+ #[cfg_attr(
+     kernel,
+     doc = "[`Box<T>`]: https://rust.docs.kernel.org/kernel/alloc/kbox/struct.Box.html"
+ )]
+ #[cfg_attr(not(kernel), doc = "[`Arc<T>`]: alloc::alloc::sync::Arc")]
+ #[cfg_attr(not(kernel), doc = "[`Box<T>`]: alloc::alloc::boxed::Box")]
+ #[must_use = "An initializer must be used in order to create its value."]
+ pub unsafe trait Init<T: ?Sized, E = Infallible>: PinInit<T, E> {
+     /// Initializes `slot`.
+     ///
+     /// # Safety
+     ///
+     /// - `slot` is a valid pointer to uninitialized memory.
+     /// - the caller does not touch `slot` when `Err` is returned, they are only permitted to
+     ///   deallocate.
+     unsafe fn __init(self, slot: *mut T) -> Result<(), E>;
+ 
+     /// First initializes the value using `self` then calls the function `f` with the initialized
+     /// value.
+     ///
+     /// If `f` returns an error the value is dropped and the initializer will forward the error.
+     ///
+     /// # Examples
+     ///
+     /// ```rust
+     /// # #![expect(clippy::disallowed_names)]
+     /// use pin_init::{init, zeroed, Init};
+     ///
+     /// struct Foo {
+     ///     buf: [u8; 1_000_000],
+     /// }
+     ///
+     /// impl Foo {
+     ///     fn setup(&mut self) {
+     ///         println!("Setting up foo");
+     ///     }
+     /// }
+     ///
+     /// let foo = init!(Foo {
+     ///     buf <- zeroed()
+     /// }).chain(|foo| {
+     ///     foo.setup();
+     ///     Ok(())
+     /// });
+     /// ```
+     fn chain<F>(self, f: F) -> ChainInit<Self, F, T, E>
+     where
+         F: FnOnce(&mut T) -> Result<(), E>,
+     {
+         ChainInit(self, f, PhantomData)
+     }
+ }
+ 
+ /// An initializer returned by [`Init::chain`].
+ pub struct ChainInit<I, F, T: ?Sized, E>(I, F, __internal::Invariant<(E, T)>);
+ 
+ // SAFETY: The `__init` function is implemented such that it
+ // - returns `Ok(())` on successful initialization,
+ // - returns `Err(err)` on error and in this case `slot` will be dropped.
+ unsafe impl<T: ?Sized, E, I, F> Init<T, E> for ChainInit<I, F, T, E>
+ where
+     I: Init<T, E>,
+     F: FnOnce(&mut T) -> Result<(), E>,
+ {
+     unsafe fn __init(self, slot: *mut T) -> Result<(), E> {
+         // SAFETY: All requirements fulfilled since this function is `__init`.
+         unsafe { self.0.__pinned_init(slot)? };
+         // SAFETY: The above call initialized `slot` and we still have unique access.
+         (self.1)(unsafe { &mut *slot }).inspect_err(|_|
+             // SAFETY: `slot` was initialized above.
+             unsafe { core::ptr::drop_in_place(slot) })
+     }
+ }
+ 
+ // SAFETY: `__pinned_init` behaves exactly the same as `__init`.
+ unsafe impl<T: ?Sized, E, I, F> PinInit<T, E> for ChainInit<I, F, T, E>
+ where
+     I: Init<T, E>,
+     F: FnOnce(&mut T) -> Result<(), E>,
+ {
+     unsafe fn __pinned_init(self, slot: *mut T) -> Result<(), E> {
+         // SAFETY: `__init` has less strict requirements compared to `__pinned_init`.
+         unsafe { self.__init(slot) }
+     }
+ }
+ 
+ /// Creates a new [`PinInit<T, E>`] from the given closure.
+ ///
+ /// # Safety
+ ///
+ /// The closure:
+ /// - returns `Ok(())` if it initialized every field of `slot`,
+ /// - returns `Err(err)` if it encountered an error and then cleaned `slot`, this means:
+ ///     - `slot` can be deallocated without UB occurring,
+ ///     - `slot` does not need to be dropped,
+ ///     - `slot` is not partially initialized.
+ /// - may assume that the `slot` does not move if `T: !Unpin`,
+ /// - while constructing the `T` at `slot` it upholds the pinning invariants of `T`.
+ #[inline]
+ pub const unsafe fn pin_init_from_closure<T: ?Sized, E>(
+     f: impl FnOnce(*mut T) -> Result<(), E>,
+ ) -> impl PinInit<T, E> {
+     __internal::InitClosure(f, PhantomData)
+ }
+ 
+ /// Creates a new [`Init<T, E>`] from the given closure.
+ ///
+ /// # Safety
+ ///
+ /// The closure:
+ /// - returns `Ok(())` if it initialized every field of `slot`,
+ /// - returns `Err(err)` if it encountered an error and then cleaned `slot`, this means:
+ ///     - `slot` can be deallocated without UB occurring,
+ ///     - `slot` does not need to be dropped,
+ ///     - `slot` is not partially initialized.
+ /// - the `slot` may move after initialization.
+ /// - while constructing the `T` at `slot` it upholds the pinning invariants of `T`.
+ #[inline]
+ pub const unsafe fn init_from_closure<T: ?Sized, E>(
+     f: impl FnOnce(*mut T) -> Result<(), E>,
+ ) -> impl Init<T, E> {
+     __internal::InitClosure(f, PhantomData)
+ }
+ 
+ /// An initializer that leaves the memory uninitialized.
+ ///
+ /// The initializer is a no-op. The `slot` memory is not changed.
+ #[inline]
+ pub fn uninit<T, E>() -> impl Init<MaybeUninit<T>, E> {
+     // SAFETY: The memory is allowed to be uninitialized.
+     unsafe { init_from_closure(|_| Ok(())) }
+ }
+ 
+ /// Initializes an array by initializing each element via the provided initializer.
+ ///
+ /// # Examples
+ ///
+ /// ```rust
+ /// # use pin_init::*;
+ /// use pin_init::init_array_from_fn;
+ /// let array: Box<[usize; 1_000]> = Box::init(init_array_from_fn(|i| i)).unwrap();
+ /// assert_eq!(array.len(), 1_000);
+ /// ```
+ pub fn init_array_from_fn<I, const N: usize, T, E>(
+     mut make_init: impl FnMut(usize) -> I,
+ ) -> impl Init<[T; N], E>
+ where
+     I: Init<T, E>,
+ {
+     let init = move |slot: *mut [T; N]| {
+         let slot = slot.cast::<T>();
+         for i in 0..N {
+             let init = make_init(i);
+             // SAFETY: Since 0 <= `i` < N, it is still in bounds of `[T; N]`.
+             let ptr = unsafe { slot.add(i) };
+             // SAFETY: The pointer is derived from `slot` and thus satisfies the `__init`
+             // requirements.
+             if let Err(e) = unsafe { init.__init(ptr) } {
+                 // SAFETY: The loop has initialized the elements `slot[0..i]` and since we return
+                 // `Err` below, `slot` will be considered uninitialized memory.
+                 unsafe { ptr::drop_in_place(ptr::slice_from_raw_parts_mut(slot, i)) };
+                 return Err(e);
+             }
+         }
+         Ok(())
+     };
+     // SAFETY: The initializer above initializes every element of the array. On failure it drops
+     // any initialized elements and returns `Err`.
+     unsafe { init_from_closure(init) }
+ }
+ 
+ /// Initializes an array by initializing each element via the provided initializer.
+ ///
+ /// # Examples
+ ///
+ /// ```rust
+ /// # #![feature(allocator_api)]
+ /// # #[path = "../examples/mutex.rs"] mod mutex; use mutex::*;
+ /// # use pin_init::*;
+ /// # use core::pin::Pin;
+ /// use pin_init::pin_init_array_from_fn;
+ /// use std::sync::Arc;
+ /// let array: Pin<Arc<[CMutex<usize>; 1_000]>> =
+ ///     Arc::pin_init(pin_init_array_from_fn(|i| CMutex::new(i))).unwrap();
+ /// assert_eq!(array.len(), 1_000);
+ /// ```
+ pub fn pin_init_array_from_fn<I, const N: usize, T, E>(
+     mut make_init: impl FnMut(usize) -> I,
+ ) -> impl PinInit<[T; N], E>
+ where
+     I: PinInit<T, E>,
+ {
+     let init = move |slot: *mut [T; N]| {
+         let slot = slot.cast::<T>();
+         for i in 0..N {
+             let init = make_init(i);
+             // SAFETY: Since 0 <= `i` < N, it is still in bounds of `[T; N]`.
+             let ptr = unsafe { slot.add(i) };
+             // SAFETY: The pointer is derived from `slot` and thus satisfies the `__init`
+             // requirements.
+             if let Err(e) = unsafe { init.__pinned_init(ptr) } {
+                 // SAFETY: The loop has initialized the elements `slot[0..i]` and since we return
+                 // `Err` below, `slot` will be considered uninitialized memory.
+                 unsafe { ptr::drop_in_place(ptr::slice_from_raw_parts_mut(slot, i)) };
+                 return Err(e);
+             }
+         }
+         Ok(())
+     };
+     // SAFETY: The initializer above initializes every element of the array. On failure it drops
+     // any initialized elements and returns `Err`.
+     unsafe { pin_init_from_closure(init) }
+ }
+ 
+ // SAFETY: Every type can be initialized by-value.
+ unsafe impl<T, E> Init<T, E> for T {
+     unsafe fn __init(self, slot: *mut T) -> Result<(), E> {
+         // SAFETY: TODO.
+         unsafe { slot.write(self) };
+         Ok(())
+     }
+ }
+ 
+ // SAFETY: Every type can be initialized by-value. `__pinned_init` calls `__init`.
+ unsafe impl<T, E> PinInit<T, E> for T {
+     unsafe fn __pinned_init(self, slot: *mut T) -> Result<(), E> {
+         // SAFETY: TODO.
+         unsafe { self.__init(slot) }
+     }
+ }
+ 
+ /// Smart pointer containing uninitialized memory and that can write a value.
+ pub trait InPlaceWrite<T> {
+     /// The type `Self` turns into when the contents are initialized.
+     type Initialized;
+ 
+     /// Use the given initializer to write a value into `self`.
+     ///
+     /// Does not drop the current value and considers it as uninitialized memory.
+     fn write_init<E>(self, init: impl Init<T, E>) -> Result<Self::Initialized, E>;
+ 
+     /// Use the given pin-initializer to write a value into `self`.
+     ///
+     /// Does not drop the current value and considers it as uninitialized memory.
+     fn write_pin_init<E>(self, init: impl PinInit<T, E>) -> Result<Pin<Self::Initialized>, E>;
+ }
+ 
+ /// Trait facilitating pinned destruction.
+ ///
+ /// Use [`pinned_drop`] to implement this trait safely:
+ ///
+ /// ```rust
+ /// # #![feature(allocator_api)]
+ /// # #[path = "../examples/mutex.rs"] mod mutex; use mutex::*;
+ /// # use pin_init::*;
+ /// use core::pin::Pin;
+ /// #[pin_data(PinnedDrop)]
+ /// struct Foo {
+ ///     #[pin]
+ ///     mtx: CMutex<usize>,
+ /// }
+ ///
+ /// #[pinned_drop]
+ /// impl PinnedDrop for Foo {
+ ///     fn drop(self: Pin<&mut Self>) {
+ ///         println!("Foo is being dropped!");
+ ///     }
+ /// }
+ /// ```
+ ///
+ /// # Safety
+ ///
+ /// This trait must be implemented via the [`pinned_drop`] proc-macro attribute on the impl.
+ pub unsafe trait PinnedDrop: __internal::HasPinData {
+     /// Executes the pinned destructor of this type.
+     ///
+     /// While this function is marked safe, it is actually unsafe to call it manually. For this
+     /// reason it takes an additional parameter. This type can only be constructed by `unsafe` code
+     /// and thus prevents this function from being called where it should not.
+     ///
+     /// This extra parameter will be generated by the `#[pinned_drop]` proc-macro attribute
+     /// automatically.
+     fn drop(self: Pin<&mut Self>, only_call_from_drop: __internal::OnlyCallFromDrop);
+ }
+ 
+ /// Marker trait for types that can be initialized by writing just zeroes.
+ ///
+ /// # Safety
+ ///
+ /// The bit pattern consisting of only zeroes is a valid bit pattern for this type. In other words,
+ /// this is not UB:
+ ///
+ /// ```rust,ignore
+ /// let val: Self = unsafe { core::mem::zeroed() };
+ /// ```
+ pub unsafe trait Zeroable {}
+ 
+ /// Marker trait for types that allow `Option<Self>` to be set to all zeroes in order to write
+ /// `None` to that location.
+ ///
+ /// # Safety
+ ///
+ /// The implementer needs to ensure that `unsafe impl Zeroable for Option<Self> {}` is sound.
+ pub unsafe trait ZeroableOption {}
+ 
+ // SAFETY: by the safety requirement of `ZeroableOption`, this is valid.
+ unsafe impl<T: ZeroableOption> Zeroable for Option<T> {}
+ 
+ /// Create a new zeroed T.
+ ///
+ /// The returned initializer will write `0x00` to every byte of the given `slot`.
+ #[inline]
+ pub fn zeroed<T: Zeroable>() -> impl Init<T> {
+     // SAFETY: Because `T: Zeroable`, all bytes zero is a valid bit pattern for `T`
+     // and because we write all zeroes, the memory is initialized.
+     unsafe {
+         init_from_closure(|slot: *mut T| {
+             slot.write_bytes(0, 1);
+             Ok(())
+         })
+     }
+ }
+ 
+ macro_rules! impl_zeroable {
+     ($($({$($generics:tt)*})? $t:ty, )*) => {
+         // SAFETY: Safety comments written in the macro invocation.
+         $(unsafe impl$($($generics)*)? Zeroable for $t {})*
+     };
+ }
+ 
+ impl_zeroable! {
+     // SAFETY: All primitives that are allowed to be zero.
+     bool,
+     char,
+     u8, u16, u32, u64, u128, usize,
+     i8, i16, i32, i64, i128, isize,
+     f32, f64,
+ 
+     // Note: do not add uninhabited types (such as `!` or `core::convert::Infallible`) to this list;
+     // creating an instance of an uninhabited type is immediate undefined behavior. For more on
+     // uninhabited/empty types, consult The Rustonomicon:
+     // <https://doc.rust-lang.org/stable/nomicon/exotic-sizes.html#empty-types>. The Rust Reference
+     // also has information on undefined behavior:
+     // <https://doc.rust-lang.org/stable/reference/behavior-considered-undefined.html>.
+     //
+     // SAFETY: These are inhabited ZSTs; there is nothing to zero and a valid value exists.
+     {<T: ?Sized>} PhantomData<T>, core::marker::PhantomPinned, (),
+ 
+     // SAFETY: Type is allowed to take any value, including all zeros.
+     {<T>} MaybeUninit<T>,
+ 
+     // SAFETY: `T: Zeroable` and `UnsafeCell` is `repr(transparent)`.
+     {<T: ?Sized + Zeroable>} UnsafeCell<T>,
+ 
 -    // SAFETY: All zeros is equivalent to `None` (option layout optimization guarantee).
++    // SAFETY: All zeros is equivalent to `None` (option layout optimization guarantee:
++    // https://doc.rust-lang.org/stable/std/option/index.html#representation).
+     Option<NonZeroU8>, Option<NonZeroU16>, Option<NonZeroU32>, Option<NonZeroU64>,
+     Option<NonZeroU128>, Option<NonZeroUsize>,
+     Option<NonZeroI8>, Option<NonZeroI16>, Option<NonZeroI32>, Option<NonZeroI64>,
+     Option<NonZeroI128>, Option<NonZeroIsize>,
+ 
 -    // SAFETY: All zeros is equivalent to `None` (option layout optimization guarantee).
 -    //
 -    // In this case we are allowed to use `T: ?Sized`, since all zeros is the `None` variant.
 -    {<T: ?Sized>} Option<NonNull<T>>,
++    {<T>} Option<NonNull<T>>,
+ 
+     // SAFETY: `null` pointer is valid.
+     //
+     // We cannot use `T: ?Sized`, since the VTABLE pointer part of fat pointers is not allowed to be
+     // null.
+     //
+     // When `Pointee` gets stabilized, we could use
+     // `T: ?Sized where <T as Pointee>::Metadata: Zeroable`
+     {<T>} *mut T, {<T>} *const T,
+ 
+     // SAFETY: `null` pointer is valid and the metadata part of these fat pointers is allowed to be
+     // zero.
+     {<T>} *mut [T], {<T>} *const [T], *mut str, *const str,
+ 
+     // SAFETY: `T` is `Zeroable`.
+     {<const N: usize, T: Zeroable>} [T; N], {<T: Zeroable>} Wrapping<T>,
+ }
+ 
+ macro_rules! impl_tuple_zeroable {
+     ($(,)?) => {};
+     ($first:ident, $($t:ident),* $(,)?) => {
+         // SAFETY: All elements are zeroable and padding can be zero.
+         unsafe impl<$first: Zeroable, $($t: Zeroable),*> Zeroable for ($first, $($t),*) {}
+         impl_tuple_zeroable!($($t),* ,);
+     }
+ }
+ 
+ impl_tuple_zeroable!(A, B, C, D, E, F, G, H, I, J);
diff --cc scripts/generate_rust_analyzer.py
index adae71544cbd,54228e87e577..a0e5a0aef444
--- a/scripts/generate_rust_analyzer.py
+++ b/scripts/generate_rust_analyzer.py
@@@ -97,28 -85,42 +97,43 @@@ def generate_crates(srctree, objtree, s
          ["core", "compiler_builtins"],
      )
  
 -    append_crate(
 -        "bindings",
 -        srctree / "rust"/ "bindings" / "lib.rs",
 -        ["core"],
 -        cfg=cfg,
 -    )
 -    crates[-1]["env"]["OBJTREE"] = str(objtree.resolve(True))
 -
+     append_crate(
+         "pin_init_internal",
+         srctree / "rust" / "pin-init" / "internal" / "src" / "lib.rs",
+         [],
+         cfg=["kernel"],
+         is_proc_macro=True,
+     )
+ 
+     append_crate(
+         "pin_init",
+         srctree / "rust" / "pin-init" / "src" / "lib.rs",
+         ["core", "pin_init_internal", "macros"],
+         cfg=["kernel"],
+     )
+ 
 -    append_crate(
 -        "kernel",
 -        srctree / "rust" / "kernel" / "lib.rs",
 -        ["core", "macros", "build_error", "bindings", "pin_init"],
 -        cfg=cfg,
 -    )
 -    crates[-1]["source"] = {
 -        "include_dirs": [
 -            str(srctree / "rust" / "kernel"),
 -            str(objtree / "rust")
 -        ],
 -        "exclude_dirs": [],
 -    }
 +    def append_crate_with_generated(
 +        display_name,
 +        deps,
 +    ):
 +        append_crate(
 +            display_name,
 +            srctree / "rust"/ display_name / "lib.rs",
 +            deps,
 +            cfg=cfg,
 +        )
 +        crates[-1]["env"]["OBJTREE"] = str(objtree.resolve(True))
 +        crates[-1]["source"] = {
 +            "include_dirs": [
 +                str(srctree / "rust" / display_name),
 +                str(objtree / "rust")
 +            ],
 +            "exclude_dirs": [],
 +        }
 +
 +    append_crate_with_generated("bindings", ["core"])
 +    append_crate_with_generated("uapi", ["core"])
-     append_crate_with_generated("kernel", ["core", "macros", "build_error", "bindings", "uapi"])
++    append_crate_with_generated("kernel", ["core", "macros", "build_error", "bindings", "pin_init", "uapi"])
  
      def is_root_crate(build_file, target):
          try:


Then when I merge the rust-hrtimer tree in top of that, the resolution
looks like this:

6270ed5f46761dad1d29b06ccb73d86d5c019f3a
diff --cc rust/kernel/time/hrtimer.rs
index 000000000000,2746e69016aa..d52ce884303d
mode 000000,100644..100644
--- a/rust/kernel/time/hrtimer.rs
+++ b/rust/kernel/time/hrtimer.rs
@@@ -1,0 -1,517 +1,518 @@@
+ // SPDX-License-Identifier: GPL-2.0
+ 
+ //! Intrusive high resolution timers.
+ //!
+ //! Allows running timer callbacks without doing allocations at the time of
+ //! starting the timer. For now, only one timer per type is allowed.
+ //!
+ //! # Vocabulary
+ //!
+ //! States:
+ //!
+ //! - Stopped: initialized but not started, or cancelled, or not restarted.
+ //! - Started: initialized and started or restarted.
+ //! - Running: executing the callback.
+ //!
+ //! Operations:
+ //!
+ //! * Start
+ //! * Cancel
+ //! * Restart
+ //!
+ //! Events:
+ //!
+ //! * Expire
+ //!
+ //! ## State Diagram
+ //!
+ //! ```text
+ //!                                                   Return NoRestart
+ //!                       +---------------------------------------------------------------------+
+ //!                       |                                                                     |
+ //!                       |                                                                     |
+ //!                       |                                                                     |
+ //!                       |                                         Return Restart              |
+ //!                       |                                      +------------------------+     |
+ //!                       |                                      |                        |     |
+ //!                       |                                      |                        |     |
+ //!                       v                                      v                        |     |
+ //!           +-----------------+      Start      +------------------+           +--------+-----+--+
+ //!           |                 +---------------->|                  |           |                 |
+ //! Init      |                 |                 |                  |  Expire   |                 |
+ //! --------->|    Stopped      |                 |      Started     +---------->|     Running     |
+ //!           |                 |     Cancel      |                  |           |                 |
+ //!           |                 |<----------------+                  |           |                 |
+ //!           +-----------------+                 +---------------+--+           +-----------------+
+ //!                                                     ^         |
+ //!                                                     |         |
+ //!                                                     +---------+
+ //!                                                      Restart
+ //! ```
+ //!
+ //!
+ //! A timer is initialized in the **stopped** state. A stopped timer can be
+ //! **started** by the `start` operation, with an **expiry** time. After the
+ //! `start` operation, the timer is in the **started** state. When the timer
+ //! **expires**, the timer enters the **running** state and the handler is
+ //! executed. After the handler has returned, the timer may enter the
+ //! **started* or **stopped** state, depending on the return value of the
+ //! handler. A timer in the **started** or **running** state may be **canceled**
+ //! by the `cancel` operation. A timer that is cancelled enters the **stopped**
+ //! state.
+ //!
+ //! A `cancel` or `restart` operation on a timer in the **running** state takes
+ //! effect after the handler has returned and the timer has transitioned
+ //! out of the **running** state.
+ //!
+ //! A `restart` operation on a timer in the **stopped** state is equivalent to a
+ //! `start` operation.
+ 
+ use super::ClockId;
 -use crate::{init::PinInit, prelude::*, time::Ktime, types::Opaque};
++use crate::{prelude::*, time::Ktime, types::Opaque};
+ use core::marker::PhantomData;
++use pin_init::PinInit;
+ 
+ /// A timer backed by a C `struct hrtimer`.
+ ///
+ /// # Invariants
+ ///
+ /// * `self.timer` is initialized by `bindings::hrtimer_setup`.
+ #[pin_data]
+ #[repr(C)]
+ pub struct HrTimer<T> {
+     #[pin]
+     timer: Opaque<bindings::hrtimer>,
+     mode: HrTimerMode,
+     _t: PhantomData<T>,
+ }
+ 
+ // SAFETY: Ownership of an `HrTimer` can be moved to other threads and
+ // used/dropped from there.
+ unsafe impl<T> Send for HrTimer<T> {}
+ 
+ // SAFETY: Timer operations are locked on the C side, so it is safe to operate
+ // on a timer from multiple threads.
+ unsafe impl<T> Sync for HrTimer<T> {}
+ 
+ impl<T> HrTimer<T> {
+     /// Return an initializer for a new timer instance.
+     pub fn new(mode: HrTimerMode, clock: ClockId) -> impl PinInit<Self>
+     where
+         T: HrTimerCallback,
+     {
+         pin_init!(Self {
+             // INVARIANT: We initialize `timer` with `hrtimer_setup` below.
+             timer <- Opaque::ffi_init(move |place: *mut bindings::hrtimer| {
+                 // SAFETY: By design of `pin_init!`, `place` is a pointer to a
+                 // live allocation. hrtimer_setup will initialize `place` and
+                 // does not require `place` to be initialized prior to the call.
+                 unsafe {
+                     bindings::hrtimer_setup(
+                         place,
+                         Some(T::Pointer::run),
+                         clock.into_c(),
+                         mode.into_c(),
+                     );
+                 }
+             }),
+             mode: mode,
+             _t: PhantomData,
+         })
+     }
+ 
+     /// Get a pointer to the contained `bindings::hrtimer`.
+     ///
+     /// This function is useful to get access to the value without creating
+     /// intermediate references.
+     ///
+     /// # Safety
+     ///
+     /// `this` must point to a live allocation of at least the size of `Self`.
+     unsafe fn raw_get(this: *const Self) -> *mut bindings::hrtimer {
+         // SAFETY: The field projection to `timer` does not go out of bounds,
+         // because the caller of this function promises that `this` points to an
+         // allocation of at least the size of `Self`.
+         unsafe { Opaque::raw_get(core::ptr::addr_of!((*this).timer)) }
+     }
+ 
+     /// Cancel an initialized and potentially running timer.
+     ///
+     /// If the timer handler is running, this function will block until the
+     /// handler returns.
+     ///
+     /// Note that the timer might be started by a concurrent start operation. If
+     /// so, the timer might not be in the **stopped** state when this function
+     /// returns.
+     ///
+     /// Users of the `HrTimer` API would not usually call this method directly.
+     /// Instead they would use the safe [`HrTimerHandle::cancel`] on the handle
+     /// returned when the timer was started.
+     ///
+     /// This function is useful to get access to the value without creating
+     /// intermediate references.
+     ///
+     /// # Safety
+     ///
+     /// `this` must point to a valid `Self`.
+     pub(crate) unsafe fn raw_cancel(this: *const Self) -> bool {
+         // SAFETY: `this` points to an allocation of at least `HrTimer` size.
+         let c_timer_ptr = unsafe { HrTimer::raw_get(this) };
+ 
+         // If the handler is running, this will wait for the handler to return
+         // before returning.
+         // SAFETY: `c_timer_ptr` is initialized and valid. Synchronization is
+         // handled on the C side.
+         unsafe { bindings::hrtimer_cancel(c_timer_ptr) != 0 }
+     }
+ }
+ 
+ /// Implemented by pointer types that point to structs that contain a [`HrTimer`].
+ ///
+ /// `Self` must be [`Sync`] because it is passed to timer callbacks in another
+ /// thread of execution (hard or soft interrupt context).
+ ///
+ /// Starting a timer returns a [`HrTimerHandle`] that can be used to manipulate
+ /// the timer. Note that it is OK to call the start function repeatedly, and
+ /// that more than one [`HrTimerHandle`] associated with a [`HrTimerPointer`] may
+ /// exist. A timer can be manipulated through any of the handles, and a handle
+ /// may represent a cancelled timer.
+ pub trait HrTimerPointer: Sync + Sized {
+     /// A handle representing a started or restarted timer.
+     ///
+     /// If the timer is running or if the timer callback is executing when the
+     /// handle is dropped, the drop method of [`HrTimerHandle`] should not return
+     /// until the timer is stopped and the callback has completed.
+     ///
+     /// Note: When implementing this trait, consider that it is not unsafe to
+     /// leak the handle.
+     type TimerHandle: HrTimerHandle;
+ 
+     /// Start the timer with expiry after `expires` time units. If the timer was
+     /// already running, it is restarted with the new expiry time.
+     fn start(self, expires: Ktime) -> Self::TimerHandle;
+ }
+ 
+ /// Unsafe version of [`HrTimerPointer`] for situations where leaking the
+ /// [`HrTimerHandle`] returned by `start` would be unsound. This is the case for
+ /// stack allocated timers.
+ ///
+ /// Typical implementers are pinned references such as [`Pin<&T>`].
+ ///
+ /// # Safety
+ ///
+ /// Implementers of this trait must ensure that instances of types implementing
+ /// [`UnsafeHrTimerPointer`] outlives any associated [`HrTimerPointer::TimerHandle`]
+ /// instances.
+ pub unsafe trait UnsafeHrTimerPointer: Sync + Sized {
+     /// A handle representing a running timer.
+     ///
+     /// # Safety
+     ///
+     /// If the timer is running, or if the timer callback is executing when the
+     /// handle is dropped, the drop method of [`Self::TimerHandle`] must not return
+     /// until the timer is stopped and the callback has completed.
+     type TimerHandle: HrTimerHandle;
+ 
+     /// Start the timer after `expires` time units. If the timer was already
+     /// running, it is restarted at the new expiry time.
+     ///
+     /// # Safety
+     ///
+     /// Caller promises keep the timer structure alive until the timer is dead.
+     /// Caller can ensure this by not leaking the returned [`Self::TimerHandle`].
+     unsafe fn start(self, expires: Ktime) -> Self::TimerHandle;
+ }
+ 
+ /// A trait for stack allocated timers.
+ ///
+ /// # Safety
+ ///
+ /// Implementers must ensure that `start_scoped` does not return until the
+ /// timer is dead and the timer handler is not running.
+ pub unsafe trait ScopedHrTimerPointer {
+     /// Start the timer to run after `expires` time units and immediately
+     /// after call `f`. When `f` returns, the timer is cancelled.
+     fn start_scoped<T, F>(self, expires: Ktime, f: F) -> T
+     where
+         F: FnOnce() -> T;
+ }
+ 
+ // SAFETY: By the safety requirement of [`UnsafeHrTimerPointer`], dropping the
+ // handle returned by [`UnsafeHrTimerPointer::start`] ensures that the timer is
+ // killed.
+ unsafe impl<T> ScopedHrTimerPointer for T
+ where
+     T: UnsafeHrTimerPointer,
+ {
+     fn start_scoped<U, F>(self, expires: Ktime, f: F) -> U
+     where
+         F: FnOnce() -> U,
+     {
+         // SAFETY: We drop the timer handle below before returning.
+         let handle = unsafe { UnsafeHrTimerPointer::start(self, expires) };
+         let t = f();
+         drop(handle);
+         t
+     }
+ }
+ 
+ /// Implemented by [`HrTimerPointer`] implementers to give the C timer callback a
+ /// function to call.
+ // This is split from `HrTimerPointer` to make it easier to specify trait bounds.
+ pub trait RawHrTimerCallback {
+     /// Type of the parameter passed to [`HrTimerCallback::run`]. It may be
+     /// [`Self`], or a pointer type derived from [`Self`].
+     type CallbackTarget<'a>;
+ 
+     /// Callback to be called from C when timer fires.
+     ///
+     /// # Safety
+     ///
+     /// Only to be called by C code in the `hrtimer` subsystem. `this` must point
+     /// to the `bindings::hrtimer` structure that was used to start the timer.
+     unsafe extern "C" fn run(this: *mut bindings::hrtimer) -> bindings::hrtimer_restart;
+ }
+ 
+ /// Implemented by structs that can be the target of a timer callback.
+ pub trait HrTimerCallback {
+     /// The type whose [`RawHrTimerCallback::run`] method will be invoked when
+     /// the timer expires.
+     type Pointer<'a>: RawHrTimerCallback;
+ 
+     /// Called by the timer logic when the timer fires.
+     fn run(this: <Self::Pointer<'_> as RawHrTimerCallback>::CallbackTarget<'_>) -> HrTimerRestart
+     where
+         Self: Sized;
+ }
+ 
+ /// A handle representing a potentially running timer.
+ ///
+ /// More than one handle representing the same timer might exist.
+ ///
+ /// # Safety
+ ///
+ /// When dropped, the timer represented by this handle must be cancelled, if it
+ /// is running. If the timer handler is running when the handle is dropped, the
+ /// drop method must wait for the handler to return before returning.
+ ///
+ /// Note: One way to satisfy the safety requirement is to call `Self::cancel` in
+ /// the drop implementation for `Self.`
+ pub unsafe trait HrTimerHandle {
+     /// Cancel the timer. If the timer is in the running state, block till the
+     /// handler has returned.
+     ///
+     /// Note that the timer might be started by a concurrent start operation. If
+     /// so, the timer might not be in the **stopped** state when this function
+     /// returns.
+     fn cancel(&mut self) -> bool;
+ }
+ 
+ /// Implemented by structs that contain timer nodes.
+ ///
+ /// Clients of the timer API would usually safely implement this trait by using
+ /// the [`crate::impl_has_hr_timer`] macro.
+ ///
+ /// # Safety
+ ///
+ /// Implementers of this trait must ensure that the implementer has a
+ /// [`HrTimer`] field and that all trait methods are implemented according to
+ /// their documentation. All the methods of this trait must operate on the same
+ /// field.
+ pub unsafe trait HasHrTimer<T> {
+     /// Return a pointer to the [`HrTimer`] within `Self`.
+     ///
+     /// This function is useful to get access to the value without creating
+     /// intermediate references.
+     ///
+     /// # Safety
+     ///
+     /// `this` must be a valid pointer.
+     unsafe fn raw_get_timer(this: *const Self) -> *const HrTimer<T>;
+ 
+     /// Return a pointer to the struct that is containing the [`HrTimer`] pointed
+     /// to by `ptr`.
+     ///
+     /// This function is useful to get access to the value without creating
+     /// intermediate references.
+     ///
+     /// # Safety
+     ///
+     /// `ptr` must point to a [`HrTimer<T>`] field in a struct of type `Self`.
+     unsafe fn timer_container_of(ptr: *mut HrTimer<T>) -> *mut Self
+     where
+         Self: Sized;
+ 
+     /// Get pointer to the contained `bindings::hrtimer` struct.
+     ///
+     /// This function is useful to get access to the value without creating
+     /// intermediate references.
+     ///
+     /// # Safety
+     ///
+     /// `this` must be a valid pointer.
+     unsafe fn c_timer_ptr(this: *const Self) -> *const bindings::hrtimer {
+         // SAFETY: `this` is a valid pointer to a `Self`.
+         let timer_ptr = unsafe { Self::raw_get_timer(this) };
+ 
+         // SAFETY: timer_ptr points to an allocation of at least `HrTimer` size.
+         unsafe { HrTimer::raw_get(timer_ptr) }
+     }
+ 
+     /// Start the timer contained in the `Self` pointed to by `self_ptr`. If
+     /// it is already running it is removed and inserted.
+     ///
+     /// # Safety
+     ///
+     /// - `this` must point to a valid `Self`.
+     /// - Caller must ensure that the pointee of `this` lives until the timer
+     ///   fires or is canceled.
+     unsafe fn start(this: *const Self, expires: Ktime) {
+         // SAFETY: By function safety requirement, `this` is a valid `Self`.
+         unsafe {
+             bindings::hrtimer_start_range_ns(
+                 Self::c_timer_ptr(this).cast_mut(),
+                 expires.to_ns(),
+                 0,
+                 (*Self::raw_get_timer(this)).mode.into_c(),
+             );
+         }
+     }
+ }
+ 
+ /// Restart policy for timers.
+ #[derive(Copy, Clone, PartialEq, Eq, Debug)]
+ #[repr(u32)]
+ pub enum HrTimerRestart {
+     /// Timer should not be restarted.
+     NoRestart = bindings::hrtimer_restart_HRTIMER_NORESTART,
+     /// Timer should be restarted.
+     Restart = bindings::hrtimer_restart_HRTIMER_RESTART,
+ }
+ 
+ impl HrTimerRestart {
+     fn into_c(self) -> bindings::hrtimer_restart {
+         self as bindings::hrtimer_restart
+     }
+ }
+ 
+ /// Operational mode of [`HrTimer`].
+ // NOTE: Some of these have the same encoding on the C side, so we keep
+ // `repr(Rust)` and convert elsewhere.
+ #[derive(Clone, Copy, PartialEq, Eq, Debug)]
+ pub enum HrTimerMode {
+     /// Timer expires at the given expiration time.
+     Absolute,
+     /// Timer expires after the given expiration time interpreted as a duration from now.
+     Relative,
+     /// Timer does not move between CPU cores.
+     Pinned,
+     /// Timer handler is executed in soft irq context.
+     Soft,
+     /// Timer handler is executed in hard irq context.
+     Hard,
+     /// Timer expires at the given expiration time.
+     /// Timer does not move between CPU cores.
+     AbsolutePinned,
+     /// Timer expires after the given expiration time interpreted as a duration from now.
+     /// Timer does not move between CPU cores.
+     RelativePinned,
+     /// Timer expires at the given expiration time.
+     /// Timer handler is executed in soft irq context.
+     AbsoluteSoft,
+     /// Timer expires after the given expiration time interpreted as a duration from now.
+     /// Timer handler is executed in soft irq context.
+     RelativeSoft,
+     /// Timer expires at the given expiration time.
+     /// Timer does not move between CPU cores.
+     /// Timer handler is executed in soft irq context.
+     AbsolutePinnedSoft,
+     /// Timer expires after the given expiration time interpreted as a duration from now.
+     /// Timer does not move between CPU cores.
+     /// Timer handler is executed in soft irq context.
+     RelativePinnedSoft,
+     /// Timer expires at the given expiration time.
+     /// Timer handler is executed in hard irq context.
+     AbsoluteHard,
+     /// Timer expires after the given expiration time interpreted as a duration from now.
+     /// Timer handler is executed in hard irq context.
+     RelativeHard,
+     /// Timer expires at the given expiration time.
+     /// Timer does not move between CPU cores.
+     /// Timer handler is executed in hard irq context.
+     AbsolutePinnedHard,
+     /// Timer expires after the given expiration time interpreted as a duration from now.
+     /// Timer does not move between CPU cores.
+     /// Timer handler is executed in hard irq context.
+     RelativePinnedHard,
+ }
+ 
+ impl HrTimerMode {
+     fn into_c(self) -> bindings::hrtimer_mode {
+         use bindings::*;
+         match self {
+             HrTimerMode::Absolute => hrtimer_mode_HRTIMER_MODE_ABS,
+             HrTimerMode::Relative => hrtimer_mode_HRTIMER_MODE_REL,
+             HrTimerMode::Pinned => hrtimer_mode_HRTIMER_MODE_PINNED,
+             HrTimerMode::Soft => hrtimer_mode_HRTIMER_MODE_SOFT,
+             HrTimerMode::Hard => hrtimer_mode_HRTIMER_MODE_HARD,
+             HrTimerMode::AbsolutePinned => hrtimer_mode_HRTIMER_MODE_ABS_PINNED,
+             HrTimerMode::RelativePinned => hrtimer_mode_HRTIMER_MODE_REL_PINNED,
+             HrTimerMode::AbsoluteSoft => hrtimer_mode_HRTIMER_MODE_ABS_SOFT,
+             HrTimerMode::RelativeSoft => hrtimer_mode_HRTIMER_MODE_REL_SOFT,
+             HrTimerMode::AbsolutePinnedSoft => hrtimer_mode_HRTIMER_MODE_ABS_PINNED_SOFT,
+             HrTimerMode::RelativePinnedSoft => hrtimer_mode_HRTIMER_MODE_REL_PINNED_SOFT,
+             HrTimerMode::AbsoluteHard => hrtimer_mode_HRTIMER_MODE_ABS_HARD,
+             HrTimerMode::RelativeHard => hrtimer_mode_HRTIMER_MODE_REL_HARD,
+             HrTimerMode::AbsolutePinnedHard => hrtimer_mode_HRTIMER_MODE_ABS_PINNED_HARD,
+             HrTimerMode::RelativePinnedHard => hrtimer_mode_HRTIMER_MODE_REL_PINNED_HARD,
+         }
+     }
+ }
+ 
+ /// Use to implement the [`HasHrTimer<T>`] trait.
+ ///
+ /// See [`module`] documentation for an example.
+ ///
+ /// [`module`]: crate::time::hrtimer
+ #[macro_export]
+ macro_rules! impl_has_hr_timer {
+     (
+         impl$({$($generics:tt)*})?
+             HasHrTimer<$timer_type:ty>
+             for $self:ty
+         { self.$field:ident }
+         $($rest:tt)*
+     ) => {
+         // SAFETY: This implementation of `raw_get_timer` only compiles if the
+         // field has the right type.
+         unsafe impl$(<$($generics)*>)? $crate::time::hrtimer::HasHrTimer<$timer_type> for $self {
+ 
+             #[inline]
+             unsafe fn raw_get_timer(
+                 this: *const Self,
+             ) -> *const $crate::time::hrtimer::HrTimer<$timer_type> {
+                 // SAFETY: The caller promises that the pointer is not dangling.
+                 unsafe { ::core::ptr::addr_of!((*this).$field) }
+             }
+ 
+             #[inline]
+             unsafe fn timer_container_of(
+                 ptr: *mut $crate::time::hrtimer::HrTimer<$timer_type>,
+             ) -> *mut Self {
+                 // SAFETY: As per the safety requirement of this function, `ptr`
+                 // is pointing inside a `$timer_type`.
+                 unsafe { ::kernel::container_of!(ptr, $timer_type, $field).cast_mut() }
+             }
+         }
+     }
+ }
+ 
+ mod arc;
+ pub use arc::ArcHrTimerHandle;
+ mod pin;
+ pub use pin::PinHrTimerHandle;
+ mod pin_mut;
+ pub use pin_mut::PinMutHrTimerHandle;
+ // `box` is a reserved keyword, so prefix with `t` for timer
+ mod tbox;
+ pub use tbox::BoxHrTimerHandle;

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

[Miguel Ojeda]

On Tue, Mar 18, 2025 at 12:37 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> When I merge the rust tree into linux-next, the complete resolution now
> looks like this:
> (the hunk in rust/kernel/sync.rs is needed due to a commit in the tip
> tree)

Thanks!

I have redone the 2 merges on my side again, following the ones you
did (i.e. starting on the previous merge you had on 20250318, then
rust-next, then hrtimer-next) and then compared. I saved it for you
at:

    https://github.com/ojeda/linux.git rust-test-merge

There are a few differences, a couple important, another one not much
-- all coming from the first merge (rust-next one).

1) When merging rust-next, the first one is needed to pass `rustfmt`
in `rust/kernel/sync.rs`:

-use pin_init;
 use crate::prelude::*;
 use crate::types::Opaque;
+use pin_init;

Would it be possible for you to run `make ...... rustfmt` after
merges? It is quite fast (with the amount of code we have :). As far
as I know, Linus is also doing it, so it is not a huge deal, but it is
nicer nevertheless to have it clean in linux-next so that CIs can do
`make ....... rustfmtcheck` (which checks if it is clean).

By the way, concerning this change, we could actually remove that
line, but since it was in the original commit, I kept it in the merge
-- we can clean it up in a proper commit later on.

2) More importantly, there are a couple changed needed to keep the
examples building (which are KUnit tests, i.e. under
`CONFIG_RUST_KERNEL_DOCTESTS`). In `rust/kernel/sync.rs`:

-    /// # use kernel::{c_str, stack_pin_init};
+    /// # use kernel::c_str;
     /// # use kernel::alloc::KBox;
     /// # use kernel::types::ForeignOwnable;
     /// # use kernel::sync::{LockClassKey, SpinLock};
+    /// # use pin_init::stack_pin_init;

And in `rust/kernel/sync/lock.rs`:

-    /// # use kernel::{new_spinlock, stack_pin_init,
sync::lock::{Backend, Guard, Lock}};
+    /// # use kernel::{new_spinlock, sync::lock::{Backend, Guard, Lock}};
+    /// # use pin_init::stack_pin_init;

3) A trivial difference is that I kept the removal of this newline in
`rust/pin-init/src/lib.rs`, because the original fix did so (which was
likely done because the "SAFETY" comment is supposed to "cover" it
too), but it is not a big deal to keep it as you have it.

     Option<NonZeroI128>, Option<NonZeroIsize>,
-
     {<T>} Option<NonNull<T>>,

Would it be possible to fix at least 1) and 2)? Thanks a lot!

With these changes, it all passes my usual tests for x86_64 (I found
an issue, unrelated to linux-next, in hrtimer-next, for riscv64 and
loongarch64, but Andreas and I agreed to fix it when I merge his tag
with a commit on top).

Cc'ing Benno, Boqun, and Andreas so that they are all aware of these
resolutions and can check if they see any issue.

Cheers,
Miguel

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

[Stephen Rothwell]

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

Hi Miguel,

On Wed, 19 Mar 2025 00:47:40 +0100 Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Tue, Mar 18, 2025 at 12:37 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > When I merge the rust tree into linux-next, the complete resolution now
> > looks like this:
> > (the hunk in rust/kernel/sync.rs is needed due to a commit in the tip
> > tree)  
> 
> Thanks!
> 
> I have redone the 2 merges on my side again, following the ones you
> did (i.e. starting on the previous merge you had on 20250318, then
> rust-next, then hrtimer-next) and then compared. I saved it for you
> at:
> 
>     https://github.com/ojeda/linux.git rust-test-merge

Thanks for checking it out.

> There are a few differences, a couple important, another one not much
> -- all coming from the first merge (rust-next one).
> 
> 1) When merging rust-next, the first one is needed to pass `rustfmt`
> in `rust/kernel/sync.rs`:
> 
> -use pin_init;
>  use crate::prelude::*;
>  use crate::types::Opaque;
> +use pin_init;
> 
> Would it be possible for you to run `make ...... rustfmt` after
> merges? It is quite fast (with the amount of code we have :). As far
> as I know, Linus is also doing it, so it is not a huge deal, but it is
> nicer nevertheless to have it clean in linux-next so that CIs can do
> `make ....... rustfmtcheck` (which checks if it is clean).

I have a look into it.

> By the way, concerning this change, we could actually remove that
> line, but since it was in the original commit, I kept it in the merge
> -- we can clean it up in a proper commit later on.
> 
> 2) More importantly, there are a couple changed needed to keep the
> examples building (which are KUnit tests, i.e. under
> `CONFIG_RUST_KERNEL_DOCTESTS`). In `rust/kernel/sync.rs`:
> 
> -    /// # use kernel::{c_str, stack_pin_init};
> +    /// # use kernel::c_str;
>      /// # use kernel::alloc::KBox;
>      /// # use kernel::types::ForeignOwnable;
>      /// # use kernel::sync::{LockClassKey, SpinLock};
> +    /// # use pin_init::stack_pin_init;
> 
> And in `rust/kernel/sync/lock.rs`:
> 
> -    /// # use kernel::{new_spinlock, stack_pin_init,
> sync::lock::{Backend, Guard, Lock}};
> +    /// # use kernel::{new_spinlock, sync::lock::{Backend, Guard, Lock}};
> +    /// # use pin_init::stack_pin_init;
> 
> 3) A trivial difference is that I kept the removal of this newline in
> `rust/pin-init/src/lib.rs`, because the original fix did so (which was
> likely done because the "SAFETY" comment is supposed to "cover" it
> too), but it is not a big deal to keep it as you have it.
> 
>      Option<NonZeroI128>, Option<NonZeroIsize>,
> -
>      {<T>} Option<NonNull<T>>,
> 
> Would it be possible to fix at least 1) and 2)? Thanks a lot!

I added all three to my resolution 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 tree

[Miguel Ojeda]

On Wed, Mar 19, 2025 at 10:07 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Thanks for checking it out.
>
> I have a look into it.
>
> I added all three to my resolution today.

Thanks a lot!

Cheers,
Miguel

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

[Stephen Rothwell]

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

Hi all,

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

error[E0423]: expected function, found macro `kernel::build_error`
   --> rust/kernel/miscdevice.rs:159:9
    |
159 |         kernel::build_error(VTABLE_DEFAULT_ERROR)
    |         ^^^^^^^^^^^^^^^^^^^ not a function
    |
help: use `!` to invoke the macro
    |
159 |         kernel::build_error!(VTABLE_DEFAULT_ERROR)
    |                            +
help: consider importing one of these functions instead
    |
11  + use crate::build_assert::build_error;
    |
11  + use build_error::build_error;
    |
help: if you import `build_error`, refer to it directly
    |
159 -         kernel::build_error(VTABLE_DEFAULT_ERROR)
159 +         build_error(VTABLE_DEFAULT_ERROR)
    |

error: aborting due to 1 previous error

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

Caused by commit

  614724e780f5 ("rust: kernel: move `build_error` hidden function to prevent mistakes")

interacting with commit

  5bcc8bfe841b ("rust: miscdevice: add fops->show_fdinfo() hook")

from the driver-core tree.

I have added the following merge resolution patch.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 10 Jan 2025 16:02:19 +1100
Subject: [PATCH] fix up for "rust: kernel: move `build_error` hidden function
 to prevent mistakes"

interacting with commit

  5bcc8bfe841b ("rust: miscdevice: add fops->show_fdinfo() hook")

from the driver-core tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 rust/kernel/miscdevice.rs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rust/kernel/miscdevice.rs b/rust/kernel/miscdevice.rs
index 9685e50b100d..3ba018651bc0 100644
--- a/rust/kernel/miscdevice.rs
+++ b/rust/kernel/miscdevice.rs
@@ -156,7 +156,7 @@ fn show_fdinfo(
         _m: &SeqFile,
         _file: &File,
     ) {
-        kernel::build_error(VTABLE_DEFAULT_ERROR)
+        build_error!(VTABLE_DEFAULT_ERROR)
     }
 }
 
-- 
2.45.2

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

[Alice Ryhl]

On Fri, Jan 10, 2025 at 6:28 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the rust tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> error[E0423]: expected function, found macro `kernel::build_error`
>    --> rust/kernel/miscdevice.rs:159:9
>     |
> 159 |         kernel::build_error(VTABLE_DEFAULT_ERROR)
>     |         ^^^^^^^^^^^^^^^^^^^ not a function
>     |
> help: use `!` to invoke the macro
>     |
> 159 |         kernel::build_error!(VTABLE_DEFAULT_ERROR)
>     |                            +
> help: consider importing one of these functions instead
>     |
> 11  + use crate::build_assert::build_error;
>     |
> 11  + use build_error::build_error;
>     |
> help: if you import `build_error`, refer to it directly
>     |
> 159 -         kernel::build_error(VTABLE_DEFAULT_ERROR)
> 159 +         build_error(VTABLE_DEFAULT_ERROR)
>     |
>
> error: aborting due to 1 previous error
>
> For more information about this error, try `rustc --explain E0423`.
>
> Caused by commit
>
>   614724e780f5 ("rust: kernel: move `build_error` hidden function to prevent mistakes")
>
> interacting with commit
>
>   5bcc8bfe841b ("rust: miscdevice: add fops->show_fdinfo() hook")
>
> from the driver-core tree.
>
> I have added the following merge resolution patch.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 10 Jan 2025 16:02:19 +1100
> Subject: [PATCH] fix up for "rust: kernel: move `build_error` hidden function
>  to prevent mistakes"
>
> interacting with commit
>
>   5bcc8bfe841b ("rust: miscdevice: add fops->show_fdinfo() hook")
>
> from the driver-core tree.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  rust/kernel/miscdevice.rs | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/rust/kernel/miscdevice.rs b/rust/kernel/miscdevice.rs
> index 9685e50b100d..3ba018651bc0 100644
> --- a/rust/kernel/miscdevice.rs
> +++ b/rust/kernel/miscdevice.rs
> @@ -156,7 +156,7 @@ fn show_fdinfo(
>          _m: &SeqFile,
>          _file: &File,
>      ) {
> -        kernel::build_error(VTABLE_DEFAULT_ERROR)
> +        build_error!(VTABLE_DEFAULT_ERROR)
>      }
>  }

Thank you, this fix is correct. Greg, can you pick this up directly,
or do you want a real patch?

Alice

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

[Greg Kroah-Hartman]

On Fri, Jan 10, 2025 at 10:28:46AM +0100, Alice Ryhl wrote:
> On Fri, Jan 10, 2025 at 6:28 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > After merging the rust tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > error[E0423]: expected function, found macro `kernel::build_error`
> >    --> rust/kernel/miscdevice.rs:159:9
> >     |
> > 159 |         kernel::build_error(VTABLE_DEFAULT_ERROR)
> >     |         ^^^^^^^^^^^^^^^^^^^ not a function
> >     |
> > help: use `!` to invoke the macro
> >     |
> > 159 |         kernel::build_error!(VTABLE_DEFAULT_ERROR)
> >     |                            +
> > help: consider importing one of these functions instead
> >     |
> > 11  + use crate::build_assert::build_error;
> >     |
> > 11  + use build_error::build_error;
> >     |
> > help: if you import `build_error`, refer to it directly
> >     |
> > 159 -         kernel::build_error(VTABLE_DEFAULT_ERROR)
> > 159 +         build_error(VTABLE_DEFAULT_ERROR)
> >     |
> >
> > error: aborting due to 1 previous error
> >
> > For more information about this error, try `rustc --explain E0423`.
> >
> > Caused by commit
> >
> >   614724e780f5 ("rust: kernel: move `build_error` hidden function to prevent mistakes")
> >
> > interacting with commit
> >
> >   5bcc8bfe841b ("rust: miscdevice: add fops->show_fdinfo() hook")
> >
> > from the driver-core tree.
> >
> > I have added the following merge resolution patch.
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Fri, 10 Jan 2025 16:02:19 +1100
> > Subject: [PATCH] fix up for "rust: kernel: move `build_error` hidden function
> >  to prevent mistakes"
> >
> > interacting with commit
> >
> >   5bcc8bfe841b ("rust: miscdevice: add fops->show_fdinfo() hook")
> >
> > from the driver-core tree.
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> >  rust/kernel/miscdevice.rs | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/rust/kernel/miscdevice.rs b/rust/kernel/miscdevice.rs
> > index 9685e50b100d..3ba018651bc0 100644
> > --- a/rust/kernel/miscdevice.rs
> > +++ b/rust/kernel/miscdevice.rs
> > @@ -156,7 +156,7 @@ fn show_fdinfo(
> >          _m: &SeqFile,
> >          _file: &File,
> >      ) {
> > -        kernel::build_error(VTABLE_DEFAULT_ERROR)
> > +        build_error!(VTABLE_DEFAULT_ERROR)
> >      }
> >  }
> 
> Thank you, this fix is correct. Greg, can you pick this up directly,
> or do you want a real patch?

Can I take this as a real patch for my tree?  Or is this only an issue
due to the trees being merged?

thanks,

greg k-h

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

[Alice Ryhl]

On Fri, Jan 10, 2025 at 10:34 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Fri, Jan 10, 2025 at 10:28:46AM +0100, Alice Ryhl wrote:
> > On Fri, Jan 10, 2025 at 6:28 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > Hi all,
> > >
> > > After merging the rust tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > >
> > > error[E0423]: expected function, found macro `kernel::build_error`
> > >    --> rust/kernel/miscdevice.rs:159:9
> > >     |
> > > 159 |         kernel::build_error(VTABLE_DEFAULT_ERROR)
> > >     |         ^^^^^^^^^^^^^^^^^^^ not a function
> > >     |
> > > help: use `!` to invoke the macro
> > >     |
> > > 159 |         kernel::build_error!(VTABLE_DEFAULT_ERROR)
> > >     |                            +
> > > help: consider importing one of these functions instead
> > >     |
> > > 11  + use crate::build_assert::build_error;
> > >     |
> > > 11  + use build_error::build_error;
> > >     |
> > > help: if you import `build_error`, refer to it directly
> > >     |
> > > 159 -         kernel::build_error(VTABLE_DEFAULT_ERROR)
> > > 159 +         build_error(VTABLE_DEFAULT_ERROR)
> > >     |
> > >
> > > error: aborting due to 1 previous error
> > >
> > > For more information about this error, try `rustc --explain E0423`.
> > >
> > > Caused by commit
> > >
> > >   614724e780f5 ("rust: kernel: move `build_error` hidden function to prevent mistakes")
> > >
> > > interacting with commit
> > >
> > >   5bcc8bfe841b ("rust: miscdevice: add fops->show_fdinfo() hook")
> > >
> > > from the driver-core tree.
> > >
> > > I have added the following merge resolution patch.
> > >
> > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Date: Fri, 10 Jan 2025 16:02:19 +1100
> > > Subject: [PATCH] fix up for "rust: kernel: move `build_error` hidden function
> > >  to prevent mistakes"
> > >
> > > interacting with commit
> > >
> > >   5bcc8bfe841b ("rust: miscdevice: add fops->show_fdinfo() hook")
> > >
> > > from the driver-core tree.
> > >
> > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > ---
> > >  rust/kernel/miscdevice.rs | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/rust/kernel/miscdevice.rs b/rust/kernel/miscdevice.rs
> > > index 9685e50b100d..3ba018651bc0 100644
> > > --- a/rust/kernel/miscdevice.rs
> > > +++ b/rust/kernel/miscdevice.rs
> > > @@ -156,7 +156,7 @@ fn show_fdinfo(
> > >          _m: &SeqFile,
> > >          _file: &File,
> > >      ) {
> > > -        kernel::build_error(VTABLE_DEFAULT_ERROR)
> > > +        build_error!(VTABLE_DEFAULT_ERROR)
> > >      }
> > >  }
> >
> > Thank you, this fix is correct. Greg, can you pick this up directly,
> > or do you want a real patch?
>
> Can I take this as a real patch for my tree?  Or is this only an issue
> due to the trees being merged?

You can take it as a real patch. That will make your tree compile both
with and without rust-next merged.

Though I guess it would be nice to update all three instances of
build_error! if we make a real patch. (The other two instances are
updated in rust-next, so they don't cause the failure.)

Alice

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

[Alice Ryhl]

On Fri, Jan 10, 2025 at 10:41 AM Alice Ryhl <aliceryhl@google.com> wrote:
>
> On Fri, Jan 10, 2025 at 10:34 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Fri, Jan 10, 2025 at 10:28:46AM +0100, Alice Ryhl wrote:
> > > On Fri, Jan 10, 2025 at 6:28 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > After merging the rust tree, today's linux-next build (x86_64
> > > > allmodconfig) failed like this:
> > > >
> > > > error[E0423]: expected function, found macro `kernel::build_error`
> > > >    --> rust/kernel/miscdevice.rs:159:9
> > > >     |
> > > > 159 |         kernel::build_error(VTABLE_DEFAULT_ERROR)
> > > >     |         ^^^^^^^^^^^^^^^^^^^ not a function
> > > >     |
> > > > help: use `!` to invoke the macro
> > > >     |
> > > > 159 |         kernel::build_error!(VTABLE_DEFAULT_ERROR)
> > > >     |                            +
> > > > help: consider importing one of these functions instead
> > > >     |
> > > > 11  + use crate::build_assert::build_error;
> > > >     |
> > > > 11  + use build_error::build_error;
> > > >     |
> > > > help: if you import `build_error`, refer to it directly
> > > >     |
> > > > 159 -         kernel::build_error(VTABLE_DEFAULT_ERROR)
> > > > 159 +         build_error(VTABLE_DEFAULT_ERROR)
> > > >     |
> > > >
> > > > error: aborting due to 1 previous error
> > > >
> > > > For more information about this error, try `rustc --explain E0423`.
> > > >
> > > > Caused by commit
> > > >
> > > >   614724e780f5 ("rust: kernel: move `build_error` hidden function to prevent mistakes")
> > > >
> > > > interacting with commit
> > > >
> > > >   5bcc8bfe841b ("rust: miscdevice: add fops->show_fdinfo() hook")
> > > >
> > > > from the driver-core tree.
> > > >
> > > > I have added the following merge resolution patch.
> > > >
> > > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > Date: Fri, 10 Jan 2025 16:02:19 +1100
> > > > Subject: [PATCH] fix up for "rust: kernel: move `build_error` hidden function
> > > >  to prevent mistakes"
> > > >
> > > > interacting with commit
> > > >
> > > >   5bcc8bfe841b ("rust: miscdevice: add fops->show_fdinfo() hook")
> > > >
> > > > from the driver-core tree.
> > > >
> > > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > ---
> > > >  rust/kernel/miscdevice.rs | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/rust/kernel/miscdevice.rs b/rust/kernel/miscdevice.rs
> > > > index 9685e50b100d..3ba018651bc0 100644
> > > > --- a/rust/kernel/miscdevice.rs
> > > > +++ b/rust/kernel/miscdevice.rs
> > > > @@ -156,7 +156,7 @@ fn show_fdinfo(
> > > >          _m: &SeqFile,
> > > >          _file: &File,
> > > >      ) {
> > > > -        kernel::build_error(VTABLE_DEFAULT_ERROR)
> > > > +        build_error!(VTABLE_DEFAULT_ERROR)
> > > >      }
> > > >  }
> > >
> > > Thank you, this fix is correct. Greg, can you pick this up directly,
> > > or do you want a real patch?
> >
> > Can I take this as a real patch for my tree?  Or is this only an issue
> > due to the trees being merged?
>
> You can take it as a real patch. That will make your tree compile both
> with and without rust-next merged.
>
> Though I guess it would be nice to update all three instances of
> build_error! if we make a real patch. (The other two instances are
> updated in rust-next, so they don't cause the failure.)

Actually, it looks like I am mistaken. This patch doesn't build without
https://lore.kernel.org/all/20241123222849.350287-3-ojeda@kernel.org/

I'll send a real patch.

Alice

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

[Miguel Ojeda]

On Fri, Jan 10, 2025 at 10:41 AM Alice Ryhl <aliceryhl@google.com> wrote:
>
> You can take it as a real patch. That will make your tree compile both
> with and without rust-next merged.

I don't think it builds without `rust-next` since the tree does not
have `build_error!` imported (from the prelude).

Greg: if you want to pick it as a patch, please do instead:

-        kernel::build_error(VTABLE_DEFAULT_ERROR)
+        kernel::build_error!(VTABLE_DEFAULT_ERROR).

Cheers,
Miguel

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

[Miguel Ojeda]

On Fri, Jan 10, 2025 at 10:34 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> Can I take this as a real patch for my tree?  Or is this only an issue
> due to the trees being merged?

The issue appears when the trees are merged, i.e. the code is on its
own OK, though it is also true the code should be using the function
but the macro (even if both work), so you could take the patch as an
independent cleanup to the tree, I guess. In that case, I would clean
the 3 cases (i.e. adding `!` but not removing `kernel::`).

I can also drop a couple bits in `rust-next` and do the cleanup early
next cycle.

Context:

    15f2f9313a39 ("rust: use the `build_error!` macro, not the hidden function")
    614724e780f5 ("rust: kernel: move `build_error` hidden function to
prevent mistakes")

Thanks!

Cheers,
Miguel

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

[Miguel Ojeda]

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

On Fri, Jan 10, 2025 at 11:16 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> independent cleanup to the tree, I guess. In that case, I would clean
> the 3 cases (i.e. adding `!` but not removing `kernel::`).

The patch that Alice sent for this looks good.

Stephen: I did a quick build test with a merge with `rust-next` using
the following resolution (attached).

Cheers,
Miguel

[-- Attachment #2: driver-core-next_rust-next.diff --]
[-- Type: application/x-patch, Size: 2869 bytes --]

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

[Stephen Rothwell]

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

Hi all,

My first rust build error!  ;-)

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

error[E0308]: mismatched types
     --> rust/kernel/device.rs:176:17
      |
175   |             bindings::_dev_printk(
      |             --------------------- arguments to this function are incorrect
176   |                 klevel as *const _ as *const core::ffi::c_char,
      |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `*const u8`, found `*const i8`
      |
      = note: expected raw pointer `*const u8`
                 found raw pointer `*const i8`
note: function defined here
     --> /home/sfr/next/x86_64_allmodconfig/rust/bindings/bindings_generated.rs:60521:12
      |
60521 |     pub fn _dev_printk(level: *const ffi::c_char, dev: *const device, fmt: *const ffi::c_char, ...);
      |            ^^^^^^^^^^^

error[E0308]: mismatched types
   --> rust/kernel/miscdevice.rs:159:52
    |
159 |             unlocked_ioctl: maybe_fn(T::HAS_IOCTL, fops_ioctl::<T>),
    |                             --------               ^^^^^^^^^^^^^^^ expected fn pointer, found fn item
    |                             |
    |                             arguments to this function are incorrect
    |
    = note: expected fn pointer `unsafe extern "C" fn(_, _, usize) -> isize`
                  found fn item `unsafe extern "C" fn(_, _, u64) -> i64 {fops_ioctl::<T>}`
help: the return type of this call is `unsafe extern "C" fn(*mut bindings::file, u32, u64) -> i64 {fops_ioctl::<T>}` due to the type of the argument passed
   --> rust/kernel/miscdevice.rs:159:29
    |
159 |             unlocked_ioctl: maybe_fn(T::HAS_IOCTL, fops_ioctl::<T>),
    |                             ^^^^^^^^^^^^^^^^^^^^^^^---------------^
    |                                                    |
    |                                                    this argument influences the return type of `maybe_fn`
note: function defined here
   --> rust/kernel/miscdevice.rs:144:14
    |
144 |     const fn maybe_fn<T: Copy>(check: bool, func: T) -> Option<T> {
    |              ^^^^^^^^                       -------

error[E0308]: mismatched types
   --> rust/kernel/miscdevice.rs:162:22
    |
162 |                 Some(fops_compat_ioctl::<T>)
    |                 ---- ^^^^^^^^^^^^^^^^^^^^^^ expected fn pointer, found fn item
    |                 |
    |                 arguments to this enum variant are incorrect
    |
    = note: expected fn pointer `unsafe extern "C" fn(_, _, usize) -> isize`
                  found fn item `unsafe extern "C" fn(_, _, u64) -> i64 {fops_compat_ioctl::<T>}`
help: the type constructed contains `unsafe extern "C" fn(*mut bindings::file, u32, u64) -> i64 {fops_compat_ioctl::<T>}` due to the type of the argument passed
   --> rust/kernel/miscdevice.rs:162:17
    |
162 |                 Some(fops_compat_ioctl::<T>)
    |                 ^^^^^----------------------^
    |                      |
    |                      this argument influences the type of `Some`
note: tuple variant defined here
   --> /usr/lib/rustlib/src/rust/library/core/src/option.rs:579:5
    |
579 |     Some(#[stable(feature = "rust1", since = "1.0.0")] T),
    |     ^^^^

error[E0308]: mismatched types
  --> rust/kernel/security.rs:36:13
   |
32 |         to_result(unsafe { bindings::security_secid_to_secctx(secid, &mut secdata, &mut seclen) })?;
   |                                                                           ------- here the type of `secdata` is inferred to be `*mut u8`
...
36 |             secdata,
   |             ^^^^^^^ expected `*mut i8`, found `*mut u8`
   |
   = note: expected raw pointer `*mut i8`
              found raw pointer `*mut u8`

error[E0308]: mismatched types
     --> rust/kernel/security.rs:72:52
      |
72    |         unsafe { bindings::security_release_secctx(self.secdata, self.seclen as u32) };
      |                  --------------------------------- ^^^^^^^^^^^^ expected `*mut u8`, found `*mut i8`
      |                  |
      |                  arguments to this function are incorrect
      |
      = note: expected raw pointer `*mut u8`
                 found raw pointer `*mut i8`
note: function defined here
     --> /home/sfr/next/x86_64_allmodconfig/rust/bindings/bindings_generated.rs:87586:12
      |
87586 |     pub fn security_release_secctx(secdata: *mut ffi::c_char, seclen: u32_);
      |            ^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to 5 previous errors

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

Presumably caused by my merge resolutions involving commit

  d072acda4862 ("rust: use custom FFI integer types")

I have used the rust tree from next-20241108 for today.

Any help with the merge resolutions would be much appreciated.

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

[Miguel Ojeda]

On Mon, Nov 11, 2024 at 7:58 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> My first rust build error!  ;-)

:)

> error[E0308]: mismatched types
>      --> rust/kernel/device.rs:176:17
>       |
> 175   |             bindings::_dev_printk(
>       |             --------------------- arguments to this function are incorrect
> 176   |                 klevel as *const _ as *const core::ffi::c_char,
>       |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `*const u8`, found `*const i8`
>       |
>       = note: expected raw pointer `*const u8`
>                  found raw pointer `*const i8`

Yeah, sorry about that, this had very high chances of happening. For
instance, here we would need `crate::ffi::c_char`.

I am thinking perhaps the easiest way for everyone is to take for the
moment only the patches up to introducing the new `ffi::` crate (which
includes most of the changes), i.e. up to commit d072acda4862 ("rust:
use custom FFI integer types") but without doing the big remapping
just yet, so that others have it available for their branches, and
then take that last part later, ideally early in a cycle.

Gary: what do you think?

Thanks!

(Relatedly, I have been thinking of moving the `c_*` types into the prelude).

Cheers,
Miguel

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

[Miguel Ojeda]

On Mon, Nov 11, 2024 at 9:16 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> moment only the patches up to introducing the new `ffi::` crate (which
> includes most of the changes), i.e. up to commit d072acda4862 ("rust:
> use custom FFI integer types") but without doing the big remapping
> just yet, so that others have it available for their branches, and

"without doing the big remapping" is ambiguous -- I meant "actual
remapping", i.e. taking the commit as-is without the next commit,
since we should be able to do most of the renames already.

But the other interpretation, i.e. skipping most of the
changes/renames `core` -> `ffi` in that commit and do those later when
we do the actual remapping (which is most of the changes, in fact), is
also fine. They are not needed right away.

I will check how it would look like on top of next.

Cheers,
Miguel

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

[Gary Guo]

On Mon, 11 Nov 2024 09:28:53 +0100
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:

> On Mon, Nov 11, 2024 at 9:16 AM Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
> >
> > moment only the patches up to introducing the new `ffi::` crate (which
> > includes most of the changes), i.e. up to commit d072acda4862 ("rust:
> > use custom FFI integer types") but without doing the big remapping
> > just yet, so that others have it available for their branches, and  
> 
> "without doing the big remapping" is ambiguous -- I meant "actual
> remapping", i.e. taking the commit as-is without the next commit,
> since we should be able to do most of the renames already.

That sounds reasonable to me. So for next cycles we have a commit that
fixes up remaining renames, and then apply the other commits?

Best,
Gary

> 
> But the other interpretation, i.e. skipping most of the
> changes/renames `core` -> `ffi` in that commit and do those later when
> we do the actual remapping (which is most of the changes, in fact), is
> also fine. They are not needed right away.
> 
> I will check how it would look like on top of next.
> 
> Cheers,
> Miguel

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

[Miguel Ojeda]

On Mon, Nov 11, 2024 at 3:15 PM Gary Guo <gary@garyguo.net> wrote:
>
> That sounds reasonable to me. So for next cycles we have a commit that
> fixes up remaining renames, and then apply the other commits?

Yeah -- that way at least we get the new infrastructure there.

We may need to give other trees a branch with the commits that change
the mapping, so that they can write new code that does not break when
we all merge.

Or perhaps we may just simplify and do a final remapping right after a
merge window as a special case even if it is not a pure fix -- that
would be easier to successfully do at once.

Either that or we do something fancier to avoid a flag day, but
hopefully we will not need it.

Thanks!

Cheers,
Miguel

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

[Miguel Ojeda]

On Mon, Nov 11, 2024 at 9:28 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> remapping", i.e. taking the commit as-is without the next commit,
> since we should be able to do most of the renames already.

Stephen: I went with this, since unless I did something wrong, you
should see those build failures are gone, i.e. your build resolutions
were fine.

The hashes didn't change, I just dropped the top two commits.

You should be able to reuse the resolutions from yesterday.

If needed, we may simplify further, but let's see if this way works.

Thanks!

Cheers,
Miguel

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

[Stephen Rothwell]

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

Hi Miguel,

On Tue, 12 Nov 2024 00:58:47 +0100 Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Mon, Nov 11, 2024 at 9:28 AM Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
> >
> > remapping", i.e. taking the commit as-is without the next commit,
> > since we should be able to do most of the renames already.  
> 
> Stephen: I went with this, since unless I did something wrong, you
> should see those build failures are gone, i.e. your build resolutions
> were fine.
> 
> The hashes didn't change, I just dropped the top two commits.
> 
> You should be able to reuse the resolutions from yesterday.
> 
> If needed, we may simplify further, but let's see if this way works.

Thanks, I will let you know.

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

[Stephen Rothwell]

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

Hi Miguel,

On Tue, 12 Nov 2024 00:58:47 +0100 Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
>
> Stephen: I went with this, since unless I did something wrong, you
> should see those build failures are gone, i.e. your build resolutions
> were fine.
> 
> The hashes didn't change, I just dropped the top two commits.
> 
> You should be able to reuse the resolutions from yesterday.
> 
> If needed, we may simplify further, but let's see if this way works.

Its all good, no build failures and conflicts still there (but rerere
took care of those).

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

[Miguel Ojeda]

On Tue, Nov 12, 2024 at 7:30 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Its all good, no build failures and conflicts still there (but rerere
> took care of those).

Great, thanks!

Cheers,
Miguel

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

[Stephen Rothwell]

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

Hi all,

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

scripts/kconfig/confdata.c: In function 'rustc_cfg_print_symbol':
scripts/kconfig/confdata.c:669:9: warning: implicit declaration of function 'sym_escape_string_value'; did you mean 'sym_set_string_value'? [-Wimplicit-function-declaration]
  669 |   str = sym_escape_string_value(value);
      |         ^~~~~~~~~~~~~~~~~~~~~~~
      |         sym_set_string_value
scripts/kconfig/confdata.c:669:7: warning: assignment to 'const char *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
  669 |   str = sym_escape_string_value(value);
      |       ^
/usr/bin/ld: scripts/kconfig/confdata.o: in function `rustc_cfg_print_symbol':
confdata.c:(.text+0x738): undefined reference to `sym_escape_string_value'

Caused by commit

  dc08d49444e9 ("Kbuild: add Rust support")

interacting with commit

  420a2bdbead2 ("kconfig: Refactor sym_escape_string_value")

from the kbuild tree.

I applied the following patch, but it doesn't seem quite right.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 28 Sep 2021 14:02:54 +1000
Subject: [PATCH] fixup for "kconfig: Refactor sym_escape_string_value"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 scripts/kconfig/confdata.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index e1a739897d5a..096222531954 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -666,7 +666,7 @@ static void rustc_cfg_print_symbol(FILE *fp, struct symbol *sym, const char *val
 	case S_HEX:
 	case S_BOOLEAN:
 	case S_TRISTATE:
-		str = sym_escape_string_value(value);
+		str = sym_escape_string(sym);
 
 		/*
 		 * We don't care about disabled ones, i.e. no need for
-- 
2.33.0

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

[Gary Guo]

On Tue, 28 Sep 2021 14:09:32 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the rust tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> scripts/kconfig/confdata.c: In function 'rustc_cfg_print_symbol':
> scripts/kconfig/confdata.c:669:9: warning: implicit declaration of
> function 'sym_escape_string_value'; did you mean
> 'sym_set_string_value'? [-Wimplicit-function-declaration] 669 |   str
> = sym_escape_string_value(value); |         ^~~~~~~~~~~~~~~~~~~~~~~ |
>         sym_set_string_value scripts/kconfig/confdata.c:669:7:
> warning: assignment to 'const char *' from 'int' makes pointer from
> integer without a cast [-Wint-conversion] 669 |   str =
> sym_escape_string_value(value); |       ^ /usr/bin/ld:
> scripts/kconfig/confdata.o: in function `rustc_cfg_print_symbol':
> confdata.c:(.text+0x738): undefined reference to
> `sym_escape_string_value'
> 
> Caused by commit
> 
>   dc08d49444e9 ("Kbuild: add Rust support")
> 
> interacting with commit
> 
>   420a2bdbead2 ("kconfig: Refactor sym_escape_string_value")
> 
> from the kbuild tree.
> 
> I applied the following patch, but it doesn't seem quite right.

That's indeed incorrect, if we have `CONFIG_FOO=bar` then sym here is
`FOO` and value is `bar`. I think to resolve the conflict, 420a2bdbead2
would have to be reverted.

> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 28 Sep 2021 14:02:54 +1000
> Subject: [PATCH] fixup for "kconfig: Refactor sym_escape_string_value"
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  scripts/kconfig/confdata.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
> index e1a739897d5a..096222531954 100644
> --- a/scripts/kconfig/confdata.c
> +++ b/scripts/kconfig/confdata.c
> @@ -666,7 +666,7 @@ static void rustc_cfg_print_symbol(FILE *fp,
> struct symbol *sym, const char *val case S_HEX:
>  	case S_BOOLEAN:
>  	case S_TRISTATE:
> -		str = sym_escape_string_value(value);
> +		str = sym_escape_string(sym);
>  
>  		/*
>  		 * We don't care about disabled ones, i.e. no need
> for

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

[Stephen Rothwell]

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

Hi Gary,

On Tue, 28 Sep 2021 05:18:49 +0100 Gary Guo <gary@garyguo.net> wrote:
>
> On Tue, 28 Sep 2021 14:09:32 +1000
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi all,
> > 
> > After merging the rust tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > scripts/kconfig/confdata.c: In function 'rustc_cfg_print_symbol':
> > scripts/kconfig/confdata.c:669:9: warning: implicit declaration of
> > function 'sym_escape_string_value'; did you mean
> > 'sym_set_string_value'? [-Wimplicit-function-declaration] 669 |   str
> > = sym_escape_string_value(value); |         ^~~~~~~~~~~~~~~~~~~~~~~ |
> >         sym_set_string_value scripts/kconfig/confdata.c:669:7:
> > warning: assignment to 'const char *' from 'int' makes pointer from
> > integer without a cast [-Wint-conversion] 669 |   str =
> > sym_escape_string_value(value); |       ^ /usr/bin/ld:
> > scripts/kconfig/confdata.o: in function `rustc_cfg_print_symbol':
> > confdata.c:(.text+0x738): undefined reference to
> > `sym_escape_string_value'
> > 
> > Caused by commit
> > 
> >   dc08d49444e9 ("Kbuild: add Rust support")
> > 
> > interacting with commit
> > 
> >   420a2bdbead2 ("kconfig: Refactor sym_escape_string_value")
> > 
> > from the kbuild tree.
> > 
> > I applied the following patch, but it doesn't seem quite right.  
> 
> That's indeed incorrect, if we have `CONFIG_FOO=bar` then sym here is
> `FOO` and value is `bar`. I think to resolve the conflict, 420a2bdbead2
> would have to be reverted.

OK, I have done that for today.  (I needed to revert
16f3610168218ed5e2eafa6978bb7f10c175c7a9 as well).

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

[Stephen Rothwell]

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

Hi All,

On Tue, 28 Sep 2021 15:52:47 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Tue, 28 Sep 2021 05:18:49 +0100 Gary Guo <gary@garyguo.net> wrote:
> >
> > On Tue, 28 Sep 2021 14:09:32 +1000
> > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >   
> > > Hi all,
> > > 
> > > After merging the rust tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > > 
> > > scripts/kconfig/confdata.c: In function 'rustc_cfg_print_symbol':
> > > scripts/kconfig/confdata.c:669:9: warning: implicit declaration of
> > > function 'sym_escape_string_value'; did you mean
> > > 'sym_set_string_value'? [-Wimplicit-function-declaration] 669 |   str
> > > = sym_escape_string_value(value); |         ^~~~~~~~~~~~~~~~~~~~~~~ |
> > >         sym_set_string_value scripts/kconfig/confdata.c:669:7:
> > > warning: assignment to 'const char *' from 'int' makes pointer from
> > > integer without a cast [-Wint-conversion] 669 |   str =
> > > sym_escape_string_value(value); |       ^ /usr/bin/ld:
> > > scripts/kconfig/confdata.o: in function `rustc_cfg_print_symbol':
> > > confdata.c:(.text+0x738): undefined reference to
> > > `sym_escape_string_value'
> > > 
> > > Caused by commit
> > > 
> > >   dc08d49444e9 ("Kbuild: add Rust support")
> > > 
> > > interacting with commit
> > > 
> > >   420a2bdbead2 ("kconfig: Refactor sym_escape_string_value")
> > > 
> > > from the kbuild tree.
> > > 
> > > I applied the following patch, but it doesn't seem quite right.    
> > 
> > That's indeed incorrect, if we have `CONFIG_FOO=bar` then sym here is
> > `FOO` and value is `bar`. I think to resolve the conflict, 420a2bdbead2
> > would have to be reverted.  
> 
> OK, I have done that for today.  (I needed to revert
> 16f3610168218ed5e2eafa6978bb7f10c175c7a9 as well).

Today, I have applied the following patch to the kbuild tree.
Masahiro, would you consider adding this to the kbuild tree itself?  Or
is there a betters solution for what the rust tree wants to do?

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 29 Sep 2021 09:30:02 +1000
Subject: [PATCH] kconfig: restore sym_escape_string_value()

This function will be used by the rust tree.

Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Gary Guo <gary@garyguo.net>
Cc: Richard Weinberger <richard@nod.at>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 scripts/kconfig/lkc_proto.h |  1 +
 scripts/kconfig/symbol.c    | 11 +++++++----
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
index 7ce4b666bba8..62e0ed773f41 100644
--- a/scripts/kconfig/lkc_proto.h
+++ b/scripts/kconfig/lkc_proto.h
@@ -18,6 +18,7 @@ extern struct symbol * symbol_hash[SYMBOL_HASHSIZE];
 
 struct symbol * sym_lookup(const char *name, int flags);
 struct symbol * sym_find(const char *name);
+char *sym_escape_string_value(const char *in);
 char *sym_escape_string(struct symbol *sym);
 struct symbol ** sym_re_search(const char *pattern);
 const char * sym_type_name(enum symbol_type type);
diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
index 2dc251b0930e..ca115569d497 100644
--- a/scripts/kconfig/symbol.c
+++ b/scripts/kconfig/symbol.c
@@ -872,15 +872,13 @@ struct symbol *sym_find(const char *name)
 }
 
 /* The returned pointer must be freed on the caller side */
-char *sym_escape_string(struct symbol *sym)
+char *sym_escape_string_value(const char *in)
 {
-	const char *in, *p;
+	const char *p;
 	size_t reslen;
 	char *res;
 	size_t l;
 
-	in = sym_get_string_value(sym);
-
 	reslen = strlen(in) + strlen("\"\"") + 1;
 
 	p = in;
@@ -917,6 +915,11 @@ char *sym_escape_string(struct symbol *sym)
 	return res;
 }
 
+char *sym_escape_string(struct symbol *sym)
+{
+	return sym_escape_string_value(sym_get_string_value(sym));
+}
+
 struct sym_match {
 	struct symbol	*sym;
 	off_t		so, eo;
-- 
2.33.0

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

[Masahiro Yamada]

On Wed, Sep 29, 2021 at 8:38 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi All,
>
> On Tue, 28 Sep 2021 15:52:47 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Tue, 28 Sep 2021 05:18:49 +0100 Gary Guo <gary@garyguo.net> wrote:
> > >
> > > On Tue, 28 Sep 2021 14:09:32 +1000
> > > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > > Hi all,
> > > >
> > > > After merging the rust tree, today's linux-next build (x86_64
> > > > allmodconfig) failed like this:
> > > >
> > > > scripts/kconfig/confdata.c: In function 'rustc_cfg_print_symbol':
> > > > scripts/kconfig/confdata.c:669:9: warning: implicit declaration of
> > > > function 'sym_escape_string_value'; did you mean
> > > > 'sym_set_string_value'? [-Wimplicit-function-declaration] 669 |   str
> > > > = sym_escape_string_value(value); |         ^~~~~~~~~~~~~~~~~~~~~~~ |
> > > >         sym_set_string_value scripts/kconfig/confdata.c:669:7:
> > > > warning: assignment to 'const char *' from 'int' makes pointer from
> > > > integer without a cast [-Wint-conversion] 669 |   str =
> > > > sym_escape_string_value(value); |       ^ /usr/bin/ld:
> > > > scripts/kconfig/confdata.o: in function `rustc_cfg_print_symbol':
> > > > confdata.c:(.text+0x738): undefined reference to
> > > > `sym_escape_string_value'
> > > >
> > > > Caused by commit
> > > >
> > > >   dc08d49444e9 ("Kbuild: add Rust support")
> > > >
> > > > interacting with commit
> > > >
> > > >   420a2bdbead2 ("kconfig: Refactor sym_escape_string_value")
> > > >
> > > > from the kbuild tree.
> > > >
> > > > I applied the following patch, but it doesn't seem quite right.
> > >
> > > That's indeed incorrect, if we have `CONFIG_FOO=bar` then sym here is
> > > `FOO` and value is `bar`. I think to resolve the conflict, 420a2bdbead2
> > > would have to be reverted.
> >
> > OK, I have done that for today.  (I needed to revert
> > 16f3610168218ed5e2eafa6978bb7f10c175c7a9 as well).
>
> Today, I have applied the following patch to the kbuild tree.
> Masahiro, would you consider adding this to the kbuild tree itself?  Or
> is there a betters solution for what the rust tree wants to do?


I dropped those two offending commits from my tree for now
(with a different reason).

I will try my best to avoid complex conflicts next time.






>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 29 Sep 2021 09:30:02 +1000
> Subject: [PATCH] kconfig: restore sym_escape_string_value()
>
> This function will be used by the rust tree.
>
> Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
> Cc: Gary Guo <gary@garyguo.net>
> Cc: Richard Weinberger <richard@nod.at>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  scripts/kconfig/lkc_proto.h |  1 +
>  scripts/kconfig/symbol.c    | 11 +++++++----
>  2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
> index 7ce4b666bba8..62e0ed773f41 100644
> --- a/scripts/kconfig/lkc_proto.h
> +++ b/scripts/kconfig/lkc_proto.h
> @@ -18,6 +18,7 @@ extern struct symbol * symbol_hash[SYMBOL_HASHSIZE];
>
>  struct symbol * sym_lookup(const char *name, int flags);
>  struct symbol * sym_find(const char *name);
> +char *sym_escape_string_value(const char *in);
>  char *sym_escape_string(struct symbol *sym);
>  struct symbol ** sym_re_search(const char *pattern);
>  const char * sym_type_name(enum symbol_type type);
> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
> index 2dc251b0930e..ca115569d497 100644
> --- a/scripts/kconfig/symbol.c
> +++ b/scripts/kconfig/symbol.c
> @@ -872,15 +872,13 @@ struct symbol *sym_find(const char *name)
>  }
>
>  /* The returned pointer must be freed on the caller side */
> -char *sym_escape_string(struct symbol *sym)
> +char *sym_escape_string_value(const char *in)
>  {
> -       const char *in, *p;
> +       const char *p;
>         size_t reslen;
>         char *res;
>         size_t l;
>
> -       in = sym_get_string_value(sym);
> -
>         reslen = strlen(in) + strlen("\"\"") + 1;
>
>         p = in;
> @@ -917,6 +915,11 @@ char *sym_escape_string(struct symbol *sym)
>         return res;
>  }
>
> +char *sym_escape_string(struct symbol *sym)
> +{
> +       return sym_escape_string_value(sym_get_string_value(sym));
> +}
> +
>  struct sym_match {
>         struct symbol   *sym;
>         off_t           so, eo;
> --
> 2.33.0
>
> --
> Cheers,
> Stephen Rothwell



-- 
Best Regards
Masahiro Yamada

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

[Miguel Ojeda]

On Wed, Sep 29, 2021 at 7:14 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> I dropped those two offending commits from my tree for now
> (with a different reason).
>
> I will try my best to avoid complex conflicts next time.

Thanks Masahiro -- let me know if you need anything from my side or if
you prefer another solution etc.

Cheers,
Miguel