Re: [RFC PATCH] rust: block: Use 32-bit atomics
On Thu, Sep 5, 2024 at 8:12 AM David Gow wrote:
>
> 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 upstream Rust:
> https://doc.rust-lang.org/std/sync/atomic/#portability
>
> This can be tested on 32-bit x86 UML via:
> ./tools/testing/kunit/kunit.py run --make_options LLVM=1 --kconfig_add
> CONFIG_RUST=y --kconfig_add CONFIG_64BIT=n --kconfig_add
> CONFIG_FORTIFY_SOURCE=n
>
> Fixes: 3253aba3408a ("rust: block: introduce `kernel::block::mq` module")
> Signed-off-by: David Gow
> ---
>
> Hi all,
>
> I encountered this build error with Rust/UML since the kernel::block::mq
> stuff landed. I'm not 100% sure just swapping AtomicU64 with AtomicU32
> is correct -- please correct me if not -- but this does at least get the
> Rust/UML/x86-32 builds here compiling and running again.
>
> (And gives me more encouragement to go to the Rust atomics talk at
> Plumbers.)
I would probably go with AtomicUsize over AtomicU32 in this case.
Alice
Re: [PATCH v2 0/4] Enable measuring the kernel's Source-based Code Coverage and MC/DC with Clang
On Wed, Sep 04, 2024 at 11:32:41PM -0500, Wentao Zhang wrote:
> 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-cov/ directory complements the existing gcov
> implementation. Gcov works at the object code level which may better
> reflect actual execution. However, Gcov lacks the necessary information to
> correlate coverage measurement with source code location when compiler
> optimization level is non-zero (which is the default when building the
> kernel). In addition, gcov reports are occasionally ambiguous when
> attempting to compare with source code level developer intent.
>
> In the following gcov example from drivers/firmware/dmi_scan.c, an
> expression with four conditions is reported to have six branch outcomes,
> which is not ideally informative in many safety related use cases, such as
> automotive, medical, and aerospace.
>
> 5: 1068: if (s == e || *e != '/' || !month || month > 12) {
> branch 0 taken 5 (fallthrough)
> branch 1 taken 0
> branch 2 taken 5 (fallthrough)
> branch 3 taken 0
> branch 4 taken 0 (fallthrough)
> branch 5 taken 5
>
> On the other hand, Clang's Source-based Code Coverage instruments at the
> compiler frontend which maintains an accurate mapping from coverage
> measurement to source code location. Coverage reports reflect exactly how
> the code is written regardless of optimization and can present advanced
> metrics like branch coverage and MC/DC in a clearer way. Coverage report
> for the same snippet by llvm-cov would look as follows:
>
> 1068| 5|if (s == e || *e != '/' || !month || month > 12) {
> --
> | Branch (1068:6): [True: 0, False: 5]
> | Branch (1068:16): [True: 0, False: 5]
> | Branch (1068:29): [True: 0, False: 5]
> | Branch (1068:39): [True: 0, False: 5]
> --
>
> 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 [3].
>
> In the following example from arch/x86/events/probe.c, llvm-cov gives the
> MC/DC measurement for the compound logic decision at line 43.
>
>43| 12|if (msr[bit].test &&
> !msr[bit].test(bit, data))
> --
> |---> MC/DC Decision Region (43:8) to (43:50)
> |
> | Number of Conditions: 2
> | Condition C1 --> (43:8)
> | Condition C2 --> (43:25)
> |
> | Executed MC/DC Test Vectors:
> |
> | C1, C2Result
> | 1 { T, F = F }
> | 2 { T, T = T }
> |
> | C1-Pair: not covered
> | C2-Pair: covered: (1,2)
> | MC/DC Coverage for Decision: 50.00%
> |
> --
>44| 5|continue;
>
> As the results suggest, during the span of measurement, only condition C2
> (!msr[bit].test(bit, data)) is covered. That means C2 was evaluated to both
> true and false, and in those test vectors C2 affected the decision outcome
> independently. Therefore MC/DC for this decision is 1 out of 2 (50.00%).
>
> To do a full kernel measurement, instrument the kernel with
> LLVM_COV_KERNEL_MCDC enabled, and optionally set a
> LLVM_COV_KERNEL_MCDC_MAX_CONDITIONS value (the default is six). Run the
> testsuites, and collect the raw profile data under
> /sys/kernel/debug/llvm-cov/profraw. Such raw profile data can be merged and
> indexed, and used for generating coverage reports in various formats.
>
> $ cp /sys/kernel/debug/llvm-cov/profraw vmlinux.profraw
> $ llvm-profdata merge vmlinux.profraw -o vmlinux.profdata
> $ llvm-cov show --show-mcdc --show-mcdc-summary \
> --format=text --use-color=false -output-dir=coverage_reports \
> -instr-profile vmlinux.profdata vmlinux
>
> The first two patches enable the llvm-cov infrastructure, where the first
> enables source based code coverage and the second adds MC/DC support. The
> next patch disables instrumentation for curve25519-x86_64.c for the same
> reason as gcov. The final patch enables coverage for x86-64.
>
> The choice to use a new Makefile variable LLVM_COV_PROFILE, instead of
> reusing GCOV_PROFILE, was deliberate. More work needs to be done to
> determine if it is appropriate to reuse the same flag. In addition, given
> the fundamentally different approaches to instrumentation and the resulting
> variation in coverage reports, there is a strong likelihood that coverage
> type will need to be managed separately.
>
> This work reuses code from a previous effort by Sami Tolvanen et al. [4].
> Our aim is for source-based *code coverage* required for high assurance
> (MC/DC) while [4] focused more on performance op
Re: FW: [EXTERNAL] Re: [PATCH v2 0/4] Enable measuring the kernel's Source-based Code Coverage and MC/DC with Clang
Resending as plain text so that lists can accept. On Thu, Sep 5, 2024 at 8:21 AM Vanderleest (US), Steven H wrote: > > From: Vanderleest (US), Steven H > Date: Thursday, September 5, 2024 at 8:13 AM > To: Peter Zijlstra , Wentao Zhang > > Cc: Kelly (US), Matt , a...@linux-foundation.org > , Oppelt (US), Andrew J > , anton.iva...@cambridgegreys.com > , a...@kernel.org , > a...@arndb.de , bhelg...@google.com , > b...@alien8.de , Wolber (US), Chuck > , dave.han...@linux.intel.com > , dvyu...@google.com , > h...@zytor.com , jingh...@illinois.edu > , johan...@sipsolutions.net > , jpoim...@kernel.org , > justinst...@google.com , k...@kernel.org > , kent.overstr...@linux.dev , > linux-a...@vger.kernel.org , > linux-...@vger.kernel.org , > linux-kbu...@vger.kernel.org , > linux-ker...@vger.kernel.org , > linux-trace-ker...@vger.kernel.org , > linux-um@lists.infradead.org , > l...@lists.linux.dev , l...@kernel.org > , mari...@illinois.edu , > masahi...@kernel.org , mask...@google.com > , mathieu.desnoy...@efficios.com > , Weber (US), Matthew L > , mhira...@kernel.org , > mi...@redhat.com , mo...@google.com , > nat...@kernel.org , ndesaulni...@google.com > , ober...@linux.ibm.com , > paul...@kernel.org , rich...@nod.at , > rost...@goodmis.org , samitolva...@google.com > , Sarkisian (US), Samuel > , t...@linutronix.de , > ting...@illinois.edu , t...@illinois.edu > , x...@kernel.org > Subject: Re: [EXTERNAL] Re: [PATCH v2 0/4] Enable measuring the kernel's > Source-based Code Coverage and MC/DC with Clang > > I’ll answer Peter’s last question: “What is the impact on certification of > not covering the noinstr code.” > > > > Any code in the target image that is not executed by a test (and thus not > covered) must be analyzed and justified as an exception. For example, > defensive code is often impossible to exercise by test, but can be included > in the image with a justification to the regulatory authority such as the > Federal Aviation Administration (FAA). In practice, this means the number of > unique instances of non-instrumented code needs to be manageable. I say > “unique instances” because there may be many instances of a particular > category, but justified by the same analysis/rationale. Where we specifically > mark a section of code with noinstr, it is typically because the > instrumentation would change the behavior of the code, perturbing the test > results. With some analysis for each distinct category of this issue, we > could then write justification(s) to show the overall coverage is sufficient. > > > > Regards, > > Steve > > > > > > From: Peter Zijlstra > Date: Thursday, September 5, 2024 at 7:42 AM > To: Wentao Zhang > Cc: Kelly (US), Matt , a...@linux-foundation.org > , Oppelt (US), Andrew J > , anton.iva...@cambridgegreys.com > , a...@kernel.org , > a...@arndb.de , bhelg...@google.com , > b...@alien8.de , Wolber (US), Chuck > , dave.han...@linux.intel.com > , dvyu...@google.com , > h...@zytor.com , jingh...@illinois.edu > , johan...@sipsolutions.net > , jpoim...@kernel.org , > justinst...@google.com , k...@kernel.org > , kent.overstr...@linux.dev , > linux-a...@vger.kernel.org , > linux-...@vger.kernel.org , > linux-kbu...@vger.kernel.org , > linux-ker...@vger.kernel.org , > linux-trace-ker...@vger.kernel.org , > linux-um@lists.infradead.org , > l...@lists.linux.dev , l...@kernel.org > , mari...@illinois.edu , > masahi...@kernel.org , mask...@google.com > , mathieu.desnoy...@efficios.com > , Weber (US), Matthew L > , mhira...@kernel.org , > mi...@redhat.com , mo...@google.com , > nat...@kernel.org , ndesaulni...@google.com > , ober...@linux.ibm.com , > paul...@kernel.org , rich...@nod.at , > rost...@goodmis.org , samitolva...@google.com > , Sarkisian (US), Samuel > , Vanderleest (US), Steven H > , t...@linutronix.de , > ting...@illinois.edu , t...@illinois.edu > , x...@kernel.org > Subject: [EXTERNAL] Re: [PATCH v2 0/4] Enable measuring the kernel's > Source-based Code Coverage and MC/DC with Clang > > EXT email: be mindful of links/attachments. > > > > On Wed, Sep 04, 2024 at 11:32:41PM -0500, Wentao Zhang wrote: > > 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-cov/ directory complements the existing gcov > > implementation. Gcov works at the object code level which may better > > reflect actual execution. However, Gcov lacks the necessary information to > > correlate coverage measurement with source code location when compiler > > optimization level is non-zero (which is the default when building the > > kernel). In addition, gcov reports are occasionally ambiguous when > > attempting to compare with source code level developer inte
[PATCH v2 0/3] rust: Initial MIPS support
Hi Folks, This series added MIPS arch support to rust for linux, hopefully MIPS is not too late to the party :-) Sample rust module tested on R4000(el),mips32,mips32r2el,mips64, mips64r2el,mips64r6el. Please review. Thanks Signed-off-by: Jiaxun Yang --- Changes in v2: - Address review comments on wording & style (See individual commit messages) - Add microMIPS support - Link to v1: https://lore.kernel.org/r/20240903-mips-rust-v1-0-0fdf0b2fd...@flygoat.com --- Jiaxun Yang (3): rust: Introduce HAVE_GENERATE_RUST_TARGET config option MIPS: Rename mips_instruction type to workaround bindgen issue rust: Enable for MIPS Documentation/rust/arch-support.rst| 1 + .../translations/zh_CN/rust/arch-support.rst | 1 + Makefile | 3 + arch/Kconfig | 8 +++ arch/mips/Kconfig | 2 + arch/mips/include/asm/dsemul.h | 2 +- arch/mips/include/asm/inst.h | 6 +- arch/mips/kernel/ftrace.c | 2 +- arch/mips/kernel/kprobes.c | 2 +- arch/mips/math-emu/cp1emu.c| 18 +++--- arch/mips/math-emu/dsemul.c| 8 +-- arch/um/Kconfig| 1 + arch/x86/Makefile | 1 - arch/x86/Makefile.um | 1 - rust/Makefile | 2 +- scripts/Makefile | 4 +- scripts/generate_rust_target.rs| 68 ++ 17 files changed, 105 insertions(+), 25 deletions(-) --- base-commit: 469f1bad3c1c6e268059f78c0eec7e9552b3894c change-id: 20240903-mips-rust-fa8efd836ce9 Best regards, -- Jiaxun Yang
[PATCH v2 1/3] rust: Introduce HAVE_GENERATE_RUST_TARGET config option
scripts/generate_rust_target.rs is used by several architectures to generate target.json target spec file. However the enablement of this feature was controlled by target specific Makefile pieces spreading everywhere. Introduce HAVE_GENERATE_RUST_TARGET config option as a centralized switch to control the per-arch usage of generate_rust_target.rs. Signed-off-by: Jiaxun Yang --- v2: - Reword Kconfig help - Remove x86 specific condition for UM --- Makefile | 3 +++ arch/Kconfig | 8 arch/um/Kconfig | 1 + arch/x86/Makefile| 1 - arch/x86/Makefile.um | 1 - rust/Makefile| 2 +- scripts/Makefile | 4 +--- 7 files changed, 14 insertions(+), 6 deletions(-) diff --git a/Makefile b/Makefile index 2c1db7a6f793..b183855c34ea 100644 --- a/Makefile +++ b/Makefile @@ -807,6 +807,9 @@ KBUILD_CFLAGS += -Os KBUILD_RUSTFLAGS += -Copt-level=s endif +ifdef CONFIG_HAVE_GENERATE_RUST_TARGET +KBUILD_RUSTFLAGS += --target=$(objtree)/scripts/target.json +endif # Always set `debug-assertions` and `overflow-checks` because their default # depends on `opt-level` and `debug-assertions`, respectively. KBUILD_RUSTFLAGS += -Cdebug-assertions=$(if $(CONFIG_RUST_DEBUG_ASSERTIONS),y,n) diff --git a/arch/Kconfig b/arch/Kconfig index 4e2eaba9e305..0865ff4796e7 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -377,6 +377,14 @@ config HAVE_RUST This symbol should be selected by an architecture if it supports Rust. +config HAVE_GENERATE_RUST_TARGET + bool + depends on HAVE_RUST + help + This symbol should be selected by an architecture if it + needs generating Rust target.json file with + scripts/generate_rust_target.rs. + config HAVE_FUNCTION_ARG_ACCESS_API bool help diff --git a/arch/um/Kconfig b/arch/um/Kconfig index dca84fd6d00a..6b1c8ae2422d 100644 --- a/arch/um/Kconfig +++ b/arch/um/Kconfig @@ -32,6 +32,7 @@ config UML select TTY # Needed for line.c select HAVE_ARCH_VMAP_STACK select HAVE_RUST + select HAVE_GENERATE_RUST_TARGET select ARCH_HAS_UBSAN config MMU diff --git a/arch/x86/Makefile b/arch/x86/Makefile index a1883a30a5d8..cbd707f88a63 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -75,7 +75,6 @@ export BITS #https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383 # KBUILD_CFLAGS += -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -KBUILD_RUSTFLAGS += --target=$(objtree)/scripts/target.json KBUILD_RUSTFLAGS += -Ctarget-feature=-sse,-sse2,-sse3,-ssse3,-sse4.1,-sse4.2,-avx,-avx2 # diff --git a/arch/x86/Makefile.um b/arch/x86/Makefile.um index a46b1397ad01..2106a2bd152b 100644 --- a/arch/x86/Makefile.um +++ b/arch/x86/Makefile.um @@ -9,7 +9,6 @@ core-y += arch/x86/crypto/ # ifeq ($(CONFIG_CC_IS_CLANG),y) KBUILD_CFLAGS += -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -KBUILD_RUSTFLAGS += --target=$(objtree)/scripts/target.json KBUILD_RUSTFLAGS += -Ctarget-feature=-sse,-sse2,-sse3,-ssse3,-sse4.1,-sse4.2,-avx,-avx2 endif diff --git a/rust/Makefile b/rust/Makefile index 99204e33f1dd..fe3640b98011 100644 --- a/rust/Makefile +++ b/rust/Makefile @@ -378,7 +378,7 @@ $(obj)/core.o: private rustc_objcopy = $(foreach sym,$(redirect-intrinsics),--re $(obj)/core.o: private rustc_target_flags = $(core-cfgs) $(obj)/core.o: $(RUST_LIB_SRC)/core/src/lib.rs FORCE +$(call if_changed_rule,rustc_library) -ifneq ($(or $(CONFIG_X86_64),$(CONFIG_X86_32)),) +ifdef CONFIG_HAVE_GENERATE_RUST_TARGET $(obj)/core.o: scripts/target.json endif diff --git a/scripts/Makefile b/scripts/Makefile index dccef663ca82..33258a856a1a 100644 --- a/scripts/Makefile +++ b/scripts/Makefile @@ -12,13 +12,11 @@ hostprogs-always-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += insert-sys-cert hostprogs-always-$(CONFIG_RUST_KERNEL_DOCTESTS)+= rustdoc_test_builder hostprogs-always-$(CONFIG_RUST_KERNEL_DOCTESTS)+= rustdoc_test_gen -ifneq ($(or $(CONFIG_X86_64),$(CONFIG_X86_32)),) -always-$(CONFIG_RUST) += target.json +always-$(CONFIG_HAVE_GENERATE_RUST_TARGET) += target.json filechk_rust_target = $< < include/config/auto.conf $(obj)/target.json: scripts/generate_rust_target include/config/auto.conf FORCE $(call filechk,rust_target) -endif hostprogs += generate_rust_target generate_rust_target-rust := y -- 2.46.0
[PATCH v2 3/3] rust: Enable for MIPS
Enable rust for linux by implement generate_rust_target.rs
and select relevant Kconfig options.
We don't use builtin target as there is no sutiable baremetal
target for us that can cover all ISA variants supported by kernel.
Link: https://github.com/Rust-for-Linux/linux/issues/107
Signed-off-by: Jiaxun Yang
---
v2:
- Add micromips flags
- Sync issues with upstream
---
Documentation/rust/arch-support.rst| 1 +
.../translations/zh_CN/rust/arch-support.rst | 1 +
arch/mips/Kconfig | 2 +
scripts/generate_rust_target.rs| 68 ++
4 files changed, 72 insertions(+)
diff --git a/Documentation/rust/arch-support.rst
b/Documentation/rust/arch-support.rst
index 750ff371570a..ab6c0ae5a407 100644
--- a/Documentation/rust/arch-support.rst
+++ b/Documentation/rust/arch-support.rst
@@ -17,6 +17,7 @@ Architecture Level of support Constraints
= ==
``arm64`` MaintainedLittle Endian only.
``loongarch`` Maintained\-
+``mips`` Maintained\-
``riscv`` Maintained``riscv64`` only.
``um`` Maintained\-
``x86``Maintained``x86_64`` only.
diff --git a/Documentation/translations/zh_CN/rust/arch-support.rst
b/Documentation/translations/zh_CN/rust/arch-support.rst
index abd708d48f82..1eaa6c3297ac 100644
--- a/Documentation/translations/zh_CN/rust/arch-support.rst
+++ b/Documentation/translations/zh_CN/rust/arch-support.rst
@@ -21,6 +21,7 @@
= ==
``arm64`` Maintained只有小端序
``loongarch`` Maintained\-
+``mips`` Maintained\-
``riscv`` Maintained只有 ``riscv64``
``um`` Maintained只有 ``x86_64``
``x86``Maintained只有 ``x86_64``
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 43da6d596e2b..a91f0a4fd8e9 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -90,6 +90,8 @@ config MIPS
select HAVE_PERF_USER_STACK_DUMP
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_RSEQ
+ select HAVE_RUST
+ select HAVE_GENERATE_RUST_TARGET
select HAVE_SPARSE_SYSCALL_NR
select HAVE_STACKPROTECTOR
select HAVE_SYSCALL_TRACEPOINTS
diff --git a/scripts/generate_rust_target.rs b/scripts/generate_rust_target.rs
index 863720777313..bbdf8a4dd169 100644
--- a/scripts/generate_rust_target.rs
+++ b/scripts/generate_rust_target.rs
@@ -141,6 +141,13 @@ fn has(&self, option: &str) -> bool {
let option = "CONFIG_".to_owned() + option;
self.0.contains_key(&option)
}
+
+/// Returns the value of the option in the configuration.
+/// The argument must be passed without the `CONFIG_` prefix.
+fn get(&self, option: &str) -> Option<&String> {
+let option = "CONFIG_".to_owned() + option;
+self.0.get(&option)
+}
}
fn main() {
@@ -203,6 +210,67 @@ fn main() {
ts.push("target-pointer-width", "32");
} else if cfg.has("LOONGARCH") {
panic!("loongarch uses the builtin rustc
loongarch64-unknown-none-softfloat target");
+} else if cfg.has("MIPS") {
+let mut features = "+soft-float,+noabicalls".to_string();
+
+if cfg.has("CPU_MICROMIPS") {
+features += ",+micromips";
+}
+
+if cfg.has("64BIT") {
+ts.push("arch", "mips64");
+ts.push("abi", "abi64");
+cfg.get("TARGET_ISA_REV").map(|isa_rev| {
+let feature = match isa_rev.as_str() {
+"1" => ",+mips64",
+"2" => ",+mips64r2",
+"5" => ",+mips64r5",
+"6" => ",+mips64r6",
+_ => ",+mips3",
+};
+features += feature;
+});
+
+ts.push("features", features);
+if cfg.has("CPU_BIG_ENDIAN") {
+ts.push(
+"data-layout",
+"E-m:e-i8:8:32-i16:16:32-i64:64-n32:64-S128",
+);
+ts.push("llvm-target", "mips64-unknown-linux-gnuabi64");
+} else {
+ts.push(
+"data-layout",
+"e-m:e-i8:8:32-i16:16:32-i64:64-n32:64-S128",
+);
+ts.push("llvm-target", "mips64el-unknown-linux-gnuabi64");
+}
+ts.push("target-pointer-width", "64");
+} else {
+ts.push("arch", "mips");
+cfg.get("TARGET_ISA_REV").map(|isa_rev| {
+let feature = match isa_rev.as_str() {
+"1" => ",+mips32",
+"2" => ",+mips32r2",
+"5" => ",+mips32r5",
+"6" => ",+mips32r6",
+_ => ",+mips2",
+};
+
[PATCH v2 2/3] MIPS: Rename mips_instruction type to workaround bindgen issue
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 best
thing we can do is to rename mips_instruction type.
Rename it as mips_insn, which is not conflicting with anything
and aligned with struct name here.
Signed-off-by: Jiaxun Yang
---
v2:
Reword commit messsage
---
arch/mips/include/asm/dsemul.h | 2 +-
arch/mips/include/asm/inst.h | 6 +++---
arch/mips/kernel/ftrace.c | 2 +-
arch/mips/kernel/kprobes.c | 2 +-
arch/mips/math-emu/cp1emu.c| 18 +-
arch/mips/math-emu/dsemul.c| 8
6 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/mips/include/asm/dsemul.h b/arch/mips/include/asm/dsemul.h
index 08bfe8fa3b40..870597d6d1ad 100644
--- a/arch/mips/include/asm/dsemul.h
+++ b/arch/mips/include/asm/dsemul.h
@@ -34,7 +34,7 @@ struct task_struct;
*
* Return: Zero on success, negative if ir is a NOP, signal number on failure.
*/
-extern int mips_dsemul(struct pt_regs *regs, mips_instruction ir,
+extern int mips_dsemul(struct pt_regs *regs, mips_insn ir,
unsigned long branch_pc, unsigned long cont_pc);
/**
diff --git a/arch/mips/include/asm/inst.h b/arch/mips/include/asm/inst.h
index 2f98ced30263..0616b8eb7401 100644
--- a/arch/mips/include/asm/inst.h
+++ b/arch/mips/include/asm/inst.h
@@ -71,12 +71,12 @@
#define I_FMA_FFMT_SFT 0
#define MIPSInst_FMA_FFMT(x) (MIPSInst(x) & 0x0007)
-typedef unsigned int mips_instruction;
+typedef unsigned int mips_insn;
/* microMIPS instruction decode structure. Do NOT export!!! */
struct mm_decoded_insn {
- mips_instruction insn;
- mips_instruction next_insn;
+ mips_insn insn;
+ mips_insn next_insn;
int pc_inc;
int next_pc_inc;
int micro_mips_mode;
diff --git a/arch/mips/kernel/ftrace.c b/arch/mips/kernel/ftrace.c
index 8c401e42301c..153c9666a77c 100644
--- a/arch/mips/kernel/ftrace.c
+++ b/arch/mips/kernel/ftrace.c
@@ -248,7 +248,7 @@ int ftrace_disable_ftrace_graph_caller(void)
#define S_R_SP (0xafb0 << 16) /* s{d,w} R, offset(sp) */
#define OFFSET_MASK0x /* stack offset range: 0 ~ PT_SIZE */
-unsigned long ftrace_get_parent_ra_addr(unsigned long self_ra, unsigned long
+static long ftrace_get_parent_ra_addr(unsigned long self_ra, unsigned long
old_parent_ra, unsigned long parent_ra_addr, unsigned long fp)
{
unsigned long sp, ip, tmp;
diff --git a/arch/mips/kernel/kprobes.c b/arch/mips/kernel/kprobes.c
index dc39f5b3fb83..7a1b1c3674da 100644
--- a/arch/mips/kernel/kprobes.c
+++ b/arch/mips/kernel/kprobes.c
@@ -90,7 +90,7 @@ int arch_prepare_kprobe(struct kprobe *p)
}
if (copy_from_kernel_nofault(&prev_insn, p->addr - 1,
- sizeof(mips_instruction)) == 0 &&
+ sizeof(kprobe_opcode_t)) == 0 &&
insn_has_delayslot(prev_insn)) {
pr_notice("Kprobes for branch delayslot are not supported\n");
ret = -EINVAL;
diff --git a/arch/mips/math-emu/cp1emu.c b/arch/mips/math-emu/cp1emu.c
index 265bc57819df..bcd6a6f0034c 100644
--- a/arch/mips/math-emu/cp1emu.c
+++ b/arch/mips/math-emu/cp1emu.c
@@ -43,10 +43,10 @@
/* Function which emulates a floating point instruction. */
static int fpu_emu(struct pt_regs *, struct mips_fpu_struct *,
- mips_instruction);
+ mips_insn);
static int fpux_emu(struct pt_regs *,
- struct mips_fpu_struct *, mips_instruction, void __user **);
+ struct mips_fpu_struct *, mips_insn, void __user **);
/* Control registers */
@@ -846,7 +846,7 @@ do {
\
* Emulate a CFC1 instruction.
*/
static inline void cop1_cfc(struct pt_regs *xcp, struct mips_fpu_struct *ctx,
- mips_instruction ir)
+ mips_insn ir)
{
u32 fcr31 = ctx->fcr31;
u32 value = 0;
@@ -903,7 +903,7 @@ static inline void cop1_cfc(struct pt_regs *xcp, struct
mips_fpu_struct *ctx,
* Emulate a CTC1 instruction.
*/
static inline void cop1_ctc(struct pt_regs *xcp, struct mips_fpu_struct *ctx,
- mips_instruction ir)
+ mips_insn ir)
{
u32 fcr31 = ctx->fcr31;
u32 value;
@@ -973,7 +973,7 @@ static int cop1Emulate(struct pt_regs *xcp, struct
mips_fpu_struct *ctx,
{
unsigned long contpc = xcp->cp0_epc + dec_insn.pc_inc;
unsigned int cond, cbit, bit0;
- mips_instruction ir;
+ mips_insn ir;
int likely, pc_inc;
union fpureg *fpr;
u32 __user *wva;
@@ -1461,7 +1461,7 @@ DEF3OP(nmadd, dp, ieee754dp_mul, ieee754dp_add,
ieee754dp_neg);
DEF3OP(nmsub, dp, ieee754dp_mul, ieee754dp_sub, ieee754dp_neg);
static int fpux_emu(struct pt_regs *xcp, struct mips_fpu_struct *ctx,
- mips_instruction ir, void
Re: [PATCH v2 0/4] Enable measuring the kernel's Source-based Code Coverage and MC/DC with Clang
On 2024-09-05 06:41, Peter Zijlstra wrote:
> On Wed, Sep 04, 2024 at 11:32:41PM -0500, Wentao Zhang wrote:
>> 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-cov/ directory complements the existing gcov
>> implementation. Gcov works at the object code level which may better
>> reflect actual execution. However, Gcov lacks the necessary information to
>> correlate coverage measurement with source code location when compiler
>> optimization level is non-zero (which is the default when building the
>> kernel). In addition, gcov reports are occasionally ambiguous when
>> attempting to compare with source code level developer intent.
>>
>> In the following gcov example from drivers/firmware/dmi_scan.c, an
>> expression with four conditions is reported to have six branch outcomes,
>> which is not ideally informative in many safety related use cases, such as
>> automotive, medical, and aerospace.
>>
>> 5: 1068:if (s == e || *e != '/' || !month || month > 12) {
>> branch 0 taken 5 (fallthrough)
>> branch 1 taken 0
>> branch 2 taken 5 (fallthrough)
>> branch 3 taken 0
>> branch 4 taken 0 (fallthrough)
>> branch 5 taken 5
>>
>> On the other hand, Clang's Source-based Code Coverage instruments at the
>> compiler frontend which maintains an accurate mapping from coverage
>> measurement to source code location. Coverage reports reflect exactly how
>> the code is written regardless of optimization and can present advanced
>> metrics like branch coverage and MC/DC in a clearer way. Coverage report
>> for the same snippet by llvm-cov would look as follows:
>>
>> 1068| 5| if (s == e || *e != '/' || !month || month > 12) {
>>--
>>| Branch (1068:6): [True: 0, False: 5]
>>| Branch (1068:16): [True: 0, False: 5]
>>| Branch (1068:29): [True: 0, False: 5]
>>| Branch (1068:39): [True: 0, False: 5]
>>--
>>
>> 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 [3].
>>
>> In the following example from arch/x86/events/probe.c, llvm-cov gives the
>> MC/DC measurement for the compound logic decision at line 43.
>>
>> 43| 12| if (msr[bit].test &&
>> !msr[bit].test(bit, data))
>>--
>>|---> MC/DC Decision Region (43:8) to (43:50)
>>|
>>| Number of Conditions: 2
>>| Condition C1 --> (43:8)
>>| Condition C2 --> (43:25)
>>|
>>| Executed MC/DC Test Vectors:
>>|
>>| C1, C2Result
>>| 1 { T, F = F }
>>| 2 { T, T = T }
>>|
>>| C1-Pair: not covered
>>| C2-Pair: covered: (1,2)
>>| MC/DC Coverage for Decision: 50.00%
>>|
>>--
>> 44| 5| continue;
>>
>> As the results suggest, during the span of measurement, only condition C2
>> (!msr[bit].test(bit, data)) is covered. That means C2 was evaluated to both
>> true and false, and in those test vectors C2 affected the decision outcome
>> independently. Therefore MC/DC for this decision is 1 out of 2 (50.00%).
>>
>> To do a full kernel measurement, instrument the kernel with
>> LLVM_COV_KERNEL_MCDC enabled, and optionally set a
>> LLVM_COV_KERNEL_MCDC_MAX_CONDITIONS value (the default is six). Run the
>> testsuites, and collect the raw profile data under
>> /sys/kernel/debug/llvm-cov/profraw. Such raw profile data can be merged and
>> indexed, and used for generating coverage reports in various formats.
>>
>>$ cp /sys/kernel/debug/llvm-cov/profraw vmlinux.profraw
>>$ llvm-profdata merge vmlinux.profraw -o vmlinux.profdata
>>$ llvm-cov show --show-mcdc --show-mcdc-summary \
>> --format=text --use-color=false -output-dir=coverage_reports \
>> -instr-profile vmlinux.profdata vmlinux
>>
>> The first two patches enable the llvm-cov infrastructure, where the first
>> enables source based code coverage and the second adds MC/DC support. The
>> next patch disables instrumentation for curve25519-x86_64.c for the same
>> reason as gcov. The final patch enables coverage for x86-64.
>>
>> The choice to use a new Makefile variable LLVM_COV_PROFILE, instead of
>> reusing GCOV_PROFILE, was deliberate. More work needs to be done to
>> determine if it is appropriate to reuse the same flag. In addition, given
>> the fundamentally different approaches to instrumentation and the resulting
>> variation in coverage reports, there is a strong likelihood that coverage
>> type will need to be managed separately.
>>
>> This work reuses code from a previous ef
