linux-kernel - Re: [PATCH] rust: Fix build error

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANiq72nqPN64KQat2VhC5EcVBxvNF18Hi19FPz24fqjpaj2LJA@mail.gmail.com>
Date: Thu, 17 Oct 2024 15:24:06 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Eder Zulian <ezulian@...hat.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org, williams@...hat.com, ojeda@...nel.org, 
	alex.gaynor@...il.com, boqun.feng@...il.com, gary@...yguo.net, 
	bjorn3_gh@...tonmail.com, benno.lossin@...ton.me, a.hindborg@...nel.org, 
	aliceryhl@...gle.com, tmgross@...ch.edu
Subject: Re: [PATCH] rust: Fix build error

On Thu, Oct 17, 2024 at 2:15 AM Eder Zulian <ezulian@...hat.com> wrote:
>
> I can fix it and send a v2 if that's ok. Is it valid to add two 'Reported-by'
> tags (Clark and kernel test robot)?

Yeah, I think so, at least if they were independently reported. Please
add a `Closes` if you have it for Clark's report.

> Agreed. We don't want code replicated. In my reply to Boqun I added some
> notes. If that makes sense, we could avoid even the helper in
> 'spinlock{_,rt}.h'?

Hmm... I am not sure I follow your reply to Boqun. In your version,
under `DEBUG_SPINLOCK && PREEMPT_RT`, you call `spin_lock_init`, but
that means we are not passing the given key but creating a new
static/single one, no? That is why Boqun mentioned that.

> Please correct me if I misunderstood. It seems that Rust doesn't have a
> pre-processor step to replace macros in the code and the Rust compiler works
> with 'objects/entities' created for functions and variables, but macros would
> be ignored (since they are string substitution.) Do you have pointers for good
> docs on this?

I am not sure what exactly you are referring to, so perhaps this quick
summary helps (apologies if you already know all this!).

Rust does not understand C, at all. So we use `bindgen`, which is a
tool that internally uses `libclang` to parse C headers and emit Rust
code to use them from Rust. Clang (of course) knows about macros and
can parse them and expand them etc., but those macros (typically)
expand into C code, not Rust code. So (typically) we can't simply use
the macro because it does not generate valid Rust code. Thus we use a
C source file to declare helpers that call the C macros (which is fine
because it is a C file compiled by a C compiler), and then we can call
the C helper function from Rust.

The problem Boqun pointed out is that, now, since you introduced an
extra condition in the same `#ifdef`, then `spin_lock_init` is also
called in a case when `DEBUG_SPINLOCK=y`, which means the key that was
passed as a parameter is not used but the macro will provide a new
one.

Does that help?

As for docs, I am happy to point to some -- do you mean on the Rust
side of things?

Thanks for the patch!

Cheers,
Miguel