[RFC PATCH] rust: block: Use 32-bit atomics

Not all architectures have core::sync::atomic::AtomicU64 available. In particular, 32-bit x86 doesn't support it. AtomicU32 is available everywhere, so use that instead. Hopefully we can add AtomicU64 to Rust-for-Linux more broadly, so this won't be an issue, but it's not supported in core from up

[PATCH v2 4/4] x86: enable llvm-cov support

Set ARCH_HAS_* options to "y" in kconfig and include section description in linker script. Signed-off-by: Wentao Zhang Reviewed-by: Chuck Wolber Tested-by: Chuck Wolber --- arch/x86/Kconfig | 2 ++ arch/x86/kernel/vmlinux.lds.S | 2 ++ 2 files changed, 4 insertions(+) diff --git

[PATCH v2 1/4] llvm-cov: add Clang's Source-based Code Coverage support

Add infrastructure to support Clang's source-based code coverage [1]. This includes debugfs entries for serializing profiles and resetting counters/bitmaps. Also adds coverage flags and kconfig options. The newly added kernel/llvm-cov/ directory complements the existing gcov implementation. Gcov

[PATCH v2 2/4] llvm-cov: add Clang's MC/DC support

Add infrastructure to enable Clang's Modified Condition/Decision Coverage (MC/DC) [1]. Clang has added MC/DC support as of its 18.1.0 release. MC/DC is a fine- grained coverage metric required by many automotive and aviation industrial standards for certifying mission-critical software [2]. In th

[PATCH v2 3/4] x86: disable llvm-cov instrumentation

Disable instrumentation for arch/x86/crypto/curve25519-x86_64.c. Otherwise compilation would fail with "error: inline assembly requires more registers than available". Similar behavior was reported with gcov as well. See c390c452ebeb ("crypto: x86/curve25519 - disable gcov"). Signed-off-by: Wenta

[PATCH v2 0/4] Enable measuring the kernel's Source-based Code Coverage and MC/DC with Clang

From: Wentao Zhang This series adds support for building x86-64 kernels with Clang's Source- based Code Coverage[1] in order to facilitate Modified Condition/Decision Coverage (MC/DC)[2] that provably correlates to source code for all levels of compiler optimization. The newly added kernel/llvm-

Re: [PATCH 2/2] mm: make copy_to_kernel_nofault() not fault on user addresses

On Wed, Sep 04, 2024 at 09:50:56AM +0200, Christophe Leroy wrote: > Hi, > > Le 02/09/2024 à 07:31, Omar Sandoval a écrit : > > [Vous ne recevez pas souvent de courriers de osan...@osandov.com. Découvrez > > pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification > > ] > > >

Re: [PATCH] um: kunit: resolve missing prototypes warning

First of all, thanks for the quick reply > I get that you have this on kunit on ARCH=um, but that makes it > neither > a kunit nor a um patch :) Well, yes I wasn't entirely sure how to put it, sure people from UM/KUnit know what this is about, but I agree perhaps the patch title can be a bit mi

Re: [PATCH] um: kunit: resolve missing prototypes warning

On Wed, 2024-09-04 at 15:50 +0200, Gabriele Monaco wrote: > While building for KUnit with default settings, the build is generating > the following compilation warnings. > > ``` > $ make ARCH=um O=.kunit --jobs=16 > ../lib/iomap.c:156:5: warning: no previous prototype for > ‘ioread64_lo_hi’ [-Wmis

[PATCH] um: kunit: resolve missing prototypes warning

While building for KUnit with default settings, the build is generating the following compilation warnings. ``` $ make ARCH=um O=.kunit --jobs=16 ../lib/iomap.c:156:5: warning: no previous prototype for ‘ioread64_lo_hi’ [-Wmissing-prototypes] 156 | u64 ioread64_lo_hi(const void __iomem *addr)

Re: [PATCH 1/2] rust: arch/um: use 'static' relocation model for uml modules

On Wed, Sep 04, 2024 at 11:30:12AM +0200, Geert Stappers wrote: > I failed to match the actual change with the commit message. Consider > that ignorance on my side. FYI, I'm using the master branch of the upstream, but yes it's in the 'rust-next' or other branches as well, so maybe not a big deal

Re: [PATCH 1/2] rust: arch/um: use 'static' relocation model for uml modules

On Tue, Sep 03, 2024 at 09:06:05PM +0800, Zigit Zo wrote: > In the x86_64 UML, kernel modules compiled with Rust will currently > generate some R_X86_64_GOTPCREL relocations, which will then be rejected > by the kernel. > > And because of the kernel modules of UML are only got handled by the UML >

Re: [PATCH 3/3] rust: Enable for MIPS

On Wed, Sep 4, 2024 at 9:38 AM Jiaxun Yang wrote: > > Reported at: > https://github.com/rust-embedded/wg/issues/792#issuecomment-2328133517 Thanks for the link! Added to our bullet point about the target spec file in https://github.com/Rust-for-Linux/linux/issues/2. Cheers, Miguel

Re: [PATCH 2/3] MIPS: Rename mips_instruction type to workaround bindgen issue

Hi Jiaxun, Thanks for your patch! On Tue, Sep 3, 2024 at 7:15 PM Jiaxun Yang wrote: > We have a union and a type both named after mips_instruction, > rust bindgen is not happy with this kind of naming alias. > > Given that union mips_instruction is a part of UAPI, the only > thing we can do is t

Re: [PATCH 2/2] mm: make copy_to_kernel_nofault() not fault on user addresses

Hi, Le 02/09/2024 à 07:31, Omar Sandoval a écrit : [Vous ne recevez pas souvent de courriers de osan...@osandov.com. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ] From: Omar Sandoval I found that on x86, copy_to_kernel_nofault() still faults on addre

Re: [PATCH 3/3] rust: Enable for MIPS

在2024年9月3日九月 下午8:01，Miguel Ojeda写道： > On Tue, Sep 3, 2024 at 8:32 PM Jiaxun Yang wrote: >> >> Ahh thanks for the elaboration. > > You're welcome! > >> However, kernel supports many ISA variants that are not defined by any rust >> target >> triple, I'm not really sure if it's appropriate to def