On Fri, Sep 13, 2024 at 11:18 PM Conor Dooley <conor@xxxxxxxxxx> wrote: > > On Fri, Sep 13, 2024 at 12:08:20AM +0200, Miguel Ojeda wrote: > > On Thu, Aug 29, 2024 at 10:23 AM Alice Ryhl <aliceryhl@xxxxxxxxxx> wrote: > > > > > > Add all of the flags that are needed to support the shadow call stack > > > (SCS) sanitizer with Rust, and updates Kconfig to allow only > > > configurations that work. > > > > Applied to `rust-next` -- thanks everyone! > > > > Paul/Palmer/Albert/RISC-V: I think you were not Cc'd (at least in this > > version?), so please shout if you have a problem with this. > > For some reason I deleted the series from my mailbox, must've been in > dt-binding review mode and hit ctrl + d. I've been away and busy, so my > apologies Alice for not trying this out sooner. > It's sorta annoying to test rust + scs on riscv, cos you need (unless I > am mistaken) llvm-19. llvm-18 + rust built fine, but has no SCS. > > llvm-19 + rust failed to build for me riscv, producing: > > In file included from /stuff/linux/rust/helpers/helpers.c:22: > /stuff/linux/rust/helpers/spinlock.c:10:23: error: call to undeclared function 'spinlock_check'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] > __raw_spin_lock_init(spinlock_check(lock), name, key, LD_WAIT_CONFIG); > ^ > /stuff/linux/rust/helpers/spinlock.c:10:23: error: incompatible integer to pointer conversion passing 'int' to parameter of type 'raw_spinlock_t *' (aka 'struct raw_spinlock *') [-Wint-conversion] > __raw_spin_lock_init(spinlock_check(lock), name, key, LD_WAIT_CONFIG); > ^~~~~~~~~~~~~~~~~~~~ > /stuff/linux/include/linux/spinlock.h:101:52: note: passing argument to parameter 'lock' here > extern void __raw_spin_lock_init(raw_spinlock_t *lock, const char *name, > ^ > 2 errors generated. > > This occurs because I have DEBUG_SPINLOCK enabled. I didn't check why, > but Andreas seems to have introduced that code - luckily he's already on > CC here :) > > With that disabled, there are dozens of warnings along the lines of: > /stuff/linux/rust/helpers/err.c:6:14: warning: symbol 'rust_helper_ERR_PTR' was not declared. Should it be static? > If those are okay for rust code, it would be rather helpful if the > warnings could be disabled - otherwise they should really be fixed. > > Following that, I got a build error: > > error[E0425]: cannot find function `__mutex_init` in crate `bindings` > --> /stuff/linux/rust/kernel/sync/lock/mutex.rs:104:28 > | > 104 | unsafe { bindings::__mutex_init(ptr, name, key) } > | ^^^^^^^^^^^^ help: a function with a similar name exists: `__mutex_rt_init` > | > ::: /stuff/brsdk/work/linux/rust/bindings/bindings_generated.rs:12907:5 > | > 12907 | / pub fn __mutex_rt_init( > 12908 | | lock: *mut mutex, > 12909 | | name: *const core::ffi::c_char, > 12910 | | key: *mut lock_class_key, > 12911 | | ); > | |_____- similarly named function `__mutex_rt_init` defined here > > error: aborting due to 1 previous error This looks like an unrelated problem to me. This patch only changes the rustc flags, but these errors have to do with the Rust helpers/bindings, which get generated before the rustc flags are used at all. Most likely, there is a problem under the particular configuration you are using. Were you able to reproduce these errors without this patch? > I stopped there, Space Marine 2 awaits. > > Hopefully I'll get to say hello next week, > Conor. Thanks for taking a look, and see you at Plumbers! Alice