Hello!

When PREEMPT_RT=y, spin locks are mapped to rt_mutex types, so using
spinlock_check() + __raw_spin_lock_init() to initialize spin locks is
incorrect, and would cause build errors. 

This v3 patch introduces __spin_lock_init() to initialize a spin lock with
lockdep rquired information for PREEMPT_RT builds, and use it in the Rust
helper.

This patch was developed on top of linux-next/master.

As a note, at the time of writing, RUST support for x86_64 depends on
!(MITIGATION_RETHUNK && KASAN) || RUSTC_VERSION >= 108300. Miguel Ojeda
pointed out that this can be avoided with Rust 1.83, to be released in 3
weeks (2024-11-28).

In order to reproduce the problem rust must be available on the system.

  $ make LLVM=1 rustavailable

With CONFIG_PREEMPT_RT=y, CONFIG_RUST=y, and CONFIG_DEBUG_SPINLOCK=y a
x86_64 kernel can be built with

  $ make LLVM=1 -j$(nproc) bzImage 

The problem was reported at least in:
https://lore.kernel.org/oe-kbuild-all/202409251238.vetlgXE9-lkp@intel.com/
https://lore.kernel.org/all/20241107182411.57e2b418@canb.auug.org.au/

Links to v1 and v2 where improvement suggestions were made:
https://lore.kernel.org/all/20241014195253.1704625-1-ezulian@redhat.com/
https://lore.kernel.org/all/20241106211215.2005909-1-ezulian@redhat.com/

Version 2 changes:

- Cleaned up style and incorporated feedback from reviewers Boqun Feng and
  Miguel Ojeda.

Version 3 changes:

- Addressed review comments from Boqun Feng. Improved commit title and
  description and used a proper 'Fixed:' tag.

Thanks,

Eder Zulian (1):
  rust: helpers: Avoid raw_spin_lock initialization for PREEMPT_RT

 include/linux/spinlock_rt.h | 15 +++++++--------
 rust/helpers/spinlock.c     |  8 ++++++--
 2 files changed, 13 insertions(+), 10 deletions(-)

-- 
2.47.0

On Thu, Nov 7, 2024 at 5:33 PM Eder Zulian <ezulian@redhat.com> wrote:
>
> As a note, at the time of writing, RUST support for x86_64 depends on
> !(MITIGATION_RETHUNK && KASAN) || RUSTC_VERSION >= 108300. Miguel Ojeda
> pointed out that this can be avoided with Rust 1.83, to be released in 3
> weeks (2024-11-28).

I was referring there to the "or" in that condition, i.e. the "||
RUSTC_VERSION >= 108300" part. In other words, it was just a comment I
made to explain in the other thread that disabling KASAN or RETHUNK is
not needed anymore when you use 1.83 in the future. :)

But that seems unrelated to the patch here, so normally you wouldn't
add it to the cover letter. Or am I missing something? Same for the
`make rustavailable` note below (i.e. `RUST=y` already implies that).

(Of course, no need to resend anything for this -- it is just a note
to clarify, and anyway the cover letter does not go into the
repository :)

Thanks!

Cheers,
Miguel

Hi Miguel,

On Thu, Nov 07, 2024 at 05:50:50PM +0100, Miguel Ojeda wrote:
> On Thu, Nov 7, 2024 at 5:33 PM Eder Zulian <ezulian@redhat.com> wrote:
> >
> > As a note, at the time of writing, RUST support for x86_64 depends on
> > !(MITIGATION_RETHUNK && KASAN) || RUSTC_VERSION >= 108300. Miguel Ojeda
> > pointed out that this can be avoided with Rust 1.83, to be released in 3
> > weeks (2024-11-28).
> 
> I was referring there to the "or" in that condition, i.e. the "||
> RUSTC_VERSION >= 108300" part. In other words, it was just a comment I
> made to explain in the other thread that disabling KASAN or RETHUNK is
> not needed anymore when you use 1.83 in the future. :)
> 

Yes, I thought that was clear all along.

> But that seems unrelated to the patch here, so normally you wouldn't
> add it to the cover letter. Or am I missing something? Same for the
> `make rustavailable` note below (i.e. `RUST=y` already implies that).
> 

Noted. I don't think you're missing anything. Thank you for the hints.

> (Of course, no need to resend anything for this -- it is just a note
> to clarify, and anyway the cover letter does not go into the
> repository :)
> 
> Thanks!
> 
> Cheers,
> Miguel
> 

Thank you,
Eder