[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABgObfbCg1wiZJmnXFihmRLvPiJq2bCQH3MNVMfiUJphz4JW3g@mail.gmail.com>
Date: Wed, 28 May 2025 07:37:57 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Stephen Rothwell <sfr@...b.auug.org.au>, Miguel Ojeda <ojeda@...nel.org>
Cc: Maxim Levitsky <mlevitsk@...hat.com>, KVM <kvm@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the kvm tree
On Wed, May 28, 2025 at 7:28 AM Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>
> Hi all,
>
> After merging the kvm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> error[E0425]: cannot find function `mutex_trylock` in crate `bindings`
> --> rust/kernel/sync/lock/mutex.rs:129:41
> |
> 129 | let result = unsafe { bindings::mutex_trylock(ptr) };
> | ^^^^^^^^^^^^^ help: a function with a similar name exists: `mutex_lock`
> |
> ::: /home/sfr/next/x86_64_allmodconfig/rust/bindings/bindings_helpers_generated.rs:265:5
> |
> 265 | pub fn mutex_lock(lock: *mut mutex);
> | ------------------------------------ similarly named function `mutex_lock` defined here
>
> error: aborting due to 1 previous error
I thought that since Rust failures wouldn't have to be fixed by
non-Rust maintainers, they wouldn't block merging of non-Rust trees in
linux-next?
In this case it's not a problem to fix it up at all (I'll send a patch
to Miguel as soon as I've taken the little guy to school); it's just
to understand what's to expect.
Paolo
Powered by blists - more mailing lists