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: <ZxBXDhZXNgCwAHzN@f39>
Date: Thu, 17 Oct 2024 02:15:10 +0200
From: Eder Zulian <ezulian@...hat.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.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

Hi Miguel,
On Mon, Oct 14, 2024 at 10:38:45PM +0200, Miguel Ojeda wrote:
> On Mon, Oct 14, 2024 at 9:54 PM Eder Zulian <ezulian@...hat.com> wrote:
> >
> > Error observed while building a rt-debug kernel for aarch64.
> 
> Thanks for testing with Rust enabled!
Sure, it's been fun!
> 
> > Suggested-by: Clark Williams <williams@...hat.com>
> 
> Do you mean `Reported-by`?
Yes, my mistake.
> 
> Also, I am not sure which `Fixes:` tag would fit best here, since
> `PREEMPT_RT` has been around for quite a while, but only enabled very
> recently. Thomas: do you have a preference?
> 
I can try to find a culprit and add a 'Fixes:' tag. In my opnion, at first
glance, it would be the patch that introduced the Rust helper for spinlocks.
Not sure.
> In addition (sorry, it was in my backlog):
> 
> Reported-by: kernel test robot <lkp@...el.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202409251238.vetlgXE9-lkp@intel.com/
> 
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)?
> Finally, I think we should perhaps put a helper in `spinlock{_,rt}.h`
> that takes the `key` (instead of having this `#ifdef` here) and then
> just use that from the Rust helpers, because we don't want to
> duplicate such logic (conditionals) in helpers. And with the RT init
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'?
> open coding that Boqun mentioned, even more. After all, helpers are
> meant to be as straightforward as possible, and if we have this sort
> of thing in helpers, it is harder for everyone to keep them in sync.
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?
> 
> In other words, I see helpers as following the same "avoid `#ifdef`s"
> rule that we prefer in C source files vs. headers.
> 
> What do you think, Thomas?
> 
> >
> 
> Spurious newline.
Thanks, I'll fix the spurious new line.
> 
Thank you.
> Cheers,
> Miguel
>