Changes in Kconfig

9b400d17 - kbuild: Introduce Kconfig symbol for linking vmlinux with relocations

Tue, 11 Mar 2025 11:06:19 +0000

kbuild: Introduce Kconfig symbol for linking vmlinux with relocationsSome architectures build vmlinux with static relocations preserved, butstrip them again from the final vmlinux image. Arch specific toolsconsume these static relocations in order to construct relocation tablesfor KASLR.The fact that vmlinux is created, consumed and subsequently updated goesagainst the typical, declarative paradigm used by Make, which is basedon rules and dependencies. So as a first step towards cleaning this up,introduce a Kconfig symbol to declare that the arch wants to consume thestatic relocations emitted into vmlinux. This will be wired up furtherin subsequent patches.Signed-off-by: Ard Biesheuvel Signed-off-by: Masahiro Yamada List of files: /linux-6.15/arch/Kconfig

365841e1 - vdso: Add generic architecture-specific data storage

Tue, 04 Feb 2025 12:05:39 +0000

vdso: Add generic architecture-specific data storageSome architectures need to expose architecture-specific data to the vDSO.Enable the generic vDSO storage mechanism to both store and map thisdata. Some architectures require more than a single page, like LoongArch,so prepare for that usecase, too.Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20250204-vdso-store-rng-v3-7-13a4669dfc8c@linutronix.de List of files: /linux-6.15/arch/Kconfig

e419ddea - m68k: Use kernel's generic muldi3 libgcc function

Mon, 13 Nov 2023 13:32:09 +0000

m68k: Use kernel's generic muldi3 libgcc functionUse the kernels own generic lib/muldi3.c implementation of muldi3 for68K machines. Some 68K CPUs support 64bit multiplies so move the archspecific umul_ppmm() macro into a header file that is included bylib/muldi3.c. That way it can take advantage of the single instructionwhen available.There does not appear to be any existing mechanism for the genericlib/muldi3.c code to pick up an external arch definition of umul_ppmm().Create an arch specific libgcc.h that can optionally be included bythe system include/linux/libgcc.h to allow for this.Somewhat oddly there is also a similar definition of umul_ppmm() inthe non-architecture code in lib/crypto/mpi/longlong.h for a wide rangeor machines. Its presence ends up complicating the include setup andmeans not being able to use something like compiler.h instead. Actuallythere is a few other defines of umul_ppmm() macros spread around invarious architectures, but not directly usable for the m68k case.Signed-off-by: Greg Ungerer Link: https://lore.kernel.org/20231113133209.1367286-1-gerg@linux-m68k.orgReviewed-by: Geert Uytterhoeven Reviewed-by: Arnd Bergmann Signed-off-by: Geert Uytterhoeven List of files: /linux-6.15/arch/Kconfig

d5dc9583 - kbuild: Add Propeller configuration for kernel build

Sat, 02 Nov 2024 17:51:14 +0000

kbuild: Add Propeller configuration for kernel buildAdd the build support for using Clang's Propeller optimizer. LikeAutoFDO, Propeller uses hardware sampling to gather informationabout the frequency of execution of different code paths within abinary. This information is then used to guide the compiler'soptimization decisions, resulting in a more efficient binary.The support requires a Clang compiler LLVM 19 or later, and thecreate_llvm_prof tool(https://github.com/google/autofdo/releases/tag/v0.30.1). Thiscommit is limited to x86 platforms that support PMU featureslike LBR on Intel machines and AMD Zen3 BRS.Here is an example workflow for building an AutoFDO+Propelleroptimized kernel:1) Build the kernel on the host machine, with AutoFDO and Propeller build config CONFIG_AUTOFDO_CLANG=y CONFIG_PROPELLER_CLANG=y then $ make LLVM=1 CLANG_AUTOFDO_PROFILE=“” is the profile collected when doing a non-PropellerAutoFDO build. This step builds a kernel that has the same optimizationlevel as AutoFDO, plus a metadata section that records basic blockinformation. This kernel image runs as fast as an AutoFDO optimizedkernel.2) Install the kernel on test/production machines.3) Run the load tests. The '-c' option in perf specifies the sample event period. We suggest using a suitable prime number, like 500009, for this purpose. For Intel platforms: $ perf record -e BR_INST_RETIRED.NEAR_TAKEN:k -a -N -b -c \ -o -- For AMD platforms: The supported system are: Zen3 with BRS, or Zen4 with amd_lbr_v2 # To see if Zen3 support LBR: $ cat proc/cpuinfo | grep " brs" # To see if Zen4 support LBR: $ cat proc/cpuinfo | grep amd_lbr_v2 # If the result is yes, then collect the profile using: $ perf record --pfm-events RETIRED_TAKEN_BRANCH_INSTRUCTIONS:k -a \ -N -b -c -o -- 4) (Optional) Download the raw perf file to the host machine.5) Generate Propeller profile: $ create_llvm_prof --binary= --profile= \ --format=propeller --propeller_output_module_name \ --out=_cc_profile.txt \ --propeller_symorder=_ld_profile.txt “create_llvm_prof” is the profile conversion tool, and a prebuilt binary for linux can be found on https://github.com/google/autofdo/releases/tag/v0.30.1 (can also build from source). "" can be something like "/home/user/dir/any_string". This command generates a pair of Propeller profiles: "_cc_profile.txt" and "_ld_profile.txt".6) Rebuild the kernel using the AutoFDO and Propeller profile files. CONFIG_AUTOFDO_CLANG=y CONFIG_PROPELLER_CLANG=y and $ make LLVM=1 CLANG_AUTOFDO_PROFILE= \ CLANG_PROPELLER_PROFILE_PREFIX=Co-developed-by: Han Shen Signed-off-by: Han Shen Signed-off-by: Rong Xu Suggested-by: Sriraman Tallam Suggested-by: Krzysztof Pszeniczny Suggested-by: Nick Desaulniers Suggested-by: Stephane Eranian Tested-by: Yonghong Song Tested-by: Nathan Chancellor Reviewed-by: Kees Cook Signed-off-by: Masahiro Yamada List of files: /linux-6.15/arch/Kconfig

2e45474a - execmem: add support for cache of large ROX pages

Wed, 23 Oct 2024 16:27:10 +0000

execmem: add support for cache of large ROX pagesUsing large pages to map text areas reduces iTLB pressure and improvesperformance.Extend execmem_alloc() with an ability to use huge pages with ROXpermissions as a cache for smaller allocations.To populate the cache, a writable large page is allocated from vmallocwith VM_ALLOW_HUGE_VMAP, filled with invalid instructions and thenremapped as ROX.The direct map alias of that large page is exculded from the direct map.Portions of that large page are handed out to execmem_alloc() callerswithout any changes to the permissions.When the memory is freed with execmem_free() it is invalidated again sothat it won't contain stale instructions.An architecture has to implement execmem_fill_trapping_insns() callbackand select ARCH_HAS_EXECMEM_ROX configuration option to be able to use theROX cache.The cache is enabled on per-range basis when an architecture setsEXECMEM_ROX_CACHE flag in definition of an execmem_range.Link: https://lkml.kernel.org/r/20241023162711.2579610-8-rppt@kernel.orgSigned-off-by: Mike Rapoport (Microsoft) Reviewed-by: Luis Chamberlain Tested-by: kdevops Cc: Andreas Larsson Cc: Andy Lutomirski Cc: Ard Biesheuvel Cc: Arnd Bergmann Cc: Borislav Petkov (AMD) Cc: Brian Cain Cc: Catalin Marinas Cc: Christophe Leroy Cc: Christoph Hellwig Cc: Dave Hansen Cc: Dinh Nguyen Cc: Geert Uytterhoeven Cc: Guo Ren Cc: Helge Deller Cc: Huacai Chen Cc: Ingo Molnar Cc: Johannes Berg Cc: John Paul Adrian Glaubitz Cc: Kent Overstreet Cc: Liam R. Howlett Cc: Mark Rutland Cc: Masami Hiramatsu (Google) Cc: Matt Turner Cc: Max Filippov Cc: Michael Ellerman Cc: Michal Simek Cc: Oleg Nesterov Cc: Palmer Dabbelt Cc: Peter Zijlstra Cc: Richard Weinberger Cc: Russell King Cc: Song Liu Cc: Stafford Horne Cc: Steven Rostedt (Google) Cc: Suren Baghdasaryan Cc: Thomas Bogendoerfer Cc: Thomas Gleixner Cc: Uladzislau Rezki (Sony) Cc: Vineet Gupta Cc: Will Deacon Signed-off-by: Andrew Morton List of files: /linux-6.15/arch/Kconfig

315ad878 - kbuild: Add AutoFDO support for Clang build

Sat, 02 Nov 2024 17:51:08 +0000

kbuild: Add AutoFDO support for Clang buildAdd the build support for using Clang's AutoFDO. Building the kernelwith AutoFDO does not reduce the optimization level from thecompiler. AutoFDO uses hardware sampling to gather information aboutthe frequency of execution of different code paths within a binary.This information is then used to guide the compiler's optimizationdecisions, resulting in a more efficient binary. Experimentsshowed that the kernel can improve up to 10% in latency.The support requires a Clang compiler after LLVM 17. This submissionis limited to x86 platforms that support PMU features like LBR onIntel machines and AMD Zen3 BRS. Support for SPE on ARM 1, and BRBE on ARM 1 is part of planned future work.Here is an example workflow for AutoFDO kernel:1) Build the kernel on the host machine with LLVM enabled, for example, $ make menuconfig LLVM=1 Turn on AutoFDO build config: CONFIG_AUTOFDO_CLANG=y With a configuration that has LLVM enabled, use the following command: scripts/config -e AUTOFDO_CLANG After getting the config, build with $ make LLVM=12) Install the kernel on the test machine.3) Run the load tests. The '-c' option in perf specifies the sample event period. We suggest using a suitable prime number, like 500009, for this purpose. For Intel platforms: $ perf record -e BR_INST_RETIRED.NEAR_TAKEN:k -a -N -b -c \ -o -- For AMD platforms: The supported system are: Zen3 with BRS, or Zen4 with amd_lbr_v2 For Zen3: $ cat proc/cpuinfo | grep " brs" For Zen4: $ cat proc/cpuinfo | grep amd_lbr_v2 $ perf record --pfm-events RETIRED_TAKEN_BRANCH_INSTRUCTIONS:k -a \ -N -b -c -o -- 4) (Optional) Download the raw perf file to the host machine.5) To generate an AutoFDO profile, two offline tools are available: create_llvm_prof and llvm_profgen. The create_llvm_prof tool is part of the AutoFDO project and can be found on GitHub (https://github.com/google/autofdo), version v0.30.1 or later. The llvm_profgen tool is included in the LLVM compiler itself. It's important to note that the version of llvm_profgen doesn't need to match the version of Clang. It needs to be the LLVM 19 release or later, or from the LLVM trunk. $ llvm-profgen --kernel --binary= --perfdata= \ -o or $ create_llvm_prof --binary= --profile= \ --format=extbinary --out= Note that multiple AutoFDO profile files can be merged into one via: $ llvm-profdata merge -o ... 6) Rebuild the kernel using the AutoFDO profile file with the same config as step 1, (Note CONFIG_AUTOFDO_CLANG needs to be enabled): $ make LLVM=1 CLANG_AUTOFDO_PROFILE=Co-developed-by: Han Shen Signed-off-by: Han Shen Signed-off-by: Rong Xu Suggested-by: Sriraman Tallam Suggested-by: Krzysztof Pszeniczny Suggested-by: Nick Desaulniers Suggested-by: Stephane Eranian Tested-by: Yonghong Song Tested-by: Yabin Cui Tested-by: Nathan Chancellor Reviewed-by: Kees Cook Tested-by: Peter Jung Signed-off-by: Masahiro Yamada List of files: /linux-6.15/arch/Kconfig

a812eee0 - vdso: Rename struct arch_vdso_data to arch_vdso_time_data

Thu, 10 Oct 2024 07:01:30 +0000

vdso: Rename struct arch_vdso_data to arch_vdso_time_dataThe struct arch_vdso_data is only about vdso time data. So rename it toarch_vdso_time_data to make it obvious.Non time-related data will be migrated out of these structs soon.Signed-off-by: Nam Cao Signed-off-by: Thomas Gleixner Acked-by: Heiko Carstens # s390Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-28-b64f0842d512@linutronix.de List of files: /linux-6.15/arch/Kconfig

1198c9c6 - kbuild: Add generic hook for architectures to use before the final vmlinux link

Wed, 30 Oct 2024 07:08:44 +0000

kbuild: Add generic hook for architectures to use before the final vmlinux linkOn powerpc, we would like to be able to make a pass on vmlinux.o andgenerate a new object file to be linked into vmlinux. Add a generic passin Makefile.vmlinux that architectures can use for this purpose.Architectures need to select CONFIG_ARCH_WANTS_PRE_LINK_VMLINUX and mustprovide arch//tools/Makefile with .arch.vmlinux.o target, whichwill be invoked prior to the final vmlinux link step.Acked-by: Masahiro Yamada Signed-off-by: Naveen N Rao Signed-off-by: Hari Bathini Signed-off-by: Michael Ellerman Link: https://patch.msgid.link/20241030070850.1361304-12-hbathini@linux.ibm.com List of files: /linux-6.15/arch/Kconfig

2313ab74 - cfi: tweak llvm version for HAVE_CFI_ICALL_NORMALIZE_INTEGERS

Wed, 30 Oct 2024 10:31:34 +0000

cfi: tweak llvm version for HAVE_CFI_ICALL_NORMALIZE_INTEGERSThe llvm fix [1] did not make it for 19.0.0, but ended up gettingbackported to llvm 19.1.3 [2]. Thus, fix the version requirement tocorrectly specify which versions have the bug.Link: https://github.com/llvm/llvm-project/pull/104826 [1]Link: https://github.com/llvm/llvm-project/pull/113938 [2]Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202410281414.c351044e-oliver.sang@intel.comFixes: 8b8ca9c25fe6 ("cfi: fix conditions for HAVE_CFI_ICALL_NORMALIZE_INTEGERS")Signed-off-by: Alice Ryhl Reviewed-by: Sami Tolvanen Link: https://lore.kernel.org/r/20241030-cfi-icall-1913-v1-1-ab8a26e13733@google.comSigned-off-by: Miguel Ojeda List of files: /linux-6.15/arch/Kconfig

8b8ca9c2 - cfi: fix conditions for HAVE_CFI_ICALL_NORMALIZE_INTEGERS

Thu, 10 Oct 2024 09:38:27 +0000

cfi: fix conditions for HAVE_CFI_ICALL_NORMALIZE_INTEGERSThe HAVE_CFI_ICALL_NORMALIZE_INTEGERS option has some tricky conditionswhen KASAN or GCOV are turned on, as in that case we need some clang andrustc fixes [1][2] to avoid boot failures. The intent with the currentsetup is that you should be able to override the check and turn on theoption if your clang/rustc has the fix. However, this override does notwork in practice. Thus, use the new RUSTC_LLVM_VERSION to correctlyimplement the check for whether the fix is available.Additionally, remove KASAN_HW_TAGS from the list of incompatibleoptions. The CFI_ICALL_NORMALIZE_INTEGERS option is incompatible withKASAN because LLVM will emit some constructors when using KASAN that areassigned incorrect CFI tags. These constructors are emitted due to useof -fsanitize=kernel-address or -fsanitize=kernel-hwaddress that arerespectively passed when KASAN_GENERIC or KASAN_SW_TAGS are enabled.However, the KASAN_HW_TAGS option relies on hardware support for MTEinstead and does not pass either flag. (Note also that KASAN_HW_TAGSdoes not `select CONSTRUCTORS`.)Link: https://github.com/llvm/llvm-project/pull/104826 [1]Link: https://github.com/rust-lang/rust/pull/129373 [2]Fixes: 4c66f8307ac0 ("cfi: encode cfi normalized integers + kasan/gcov bug in Kconfig")Signed-off-by: Alice Ryhl Reviewed-by: Sami Tolvanen Link: https://lore.kernel.org/r/20241010-icall-detect-vers-v1-2-8f114956aa88@google.comSigned-off-by: Miguel Ojeda List of files: /linux-6.15/arch/Kconfig

87195a1e - uprobes: switch to RCU Tasks Trace flavor for better performance

Tue, 10 Sep 2024 17:43:12 +0000

uprobes: switch to RCU Tasks Trace flavor for better performanceThis patch switches uprobes SRCU usage to RCU Tasks Trace flavor, whichis optimized for more lightweight and quick readers (at the expense ofslower writers, which for uprobes is a fine tradeof) and has betterperformance and scalability with number of CPUs.Similarly to baseline vs SRCU, we've benchmarked SRCU-basedimplementation vs RCU Tasks Trace implementation.SRCU====uprobe-nop ( 1 cpus): 3.276 ± 0.005M/s ( 3.276M/s/cpu)uprobe-nop ( 2 cpus): 4.125 ± 0.002M/s ( 2.063M/s/cpu)uprobe-nop ( 4 cpus): 7.713 ± 0.002M/s ( 1.928M/s/cpu)uprobe-nop ( 8 cpus): 8.097 ± 0.006M/s ( 1.012M/s/cpu)uprobe-nop (16 cpus): 6.501 ± 0.056M/s ( 0.406M/s/cpu)uprobe-nop (32 cpus): 4.398 ± 0.084M/s ( 0.137M/s/cpu)uprobe-nop (64 cpus): 6.452 ± 0.000M/s ( 0.101M/s/cpu)uretprobe-nop ( 1 cpus): 2.055 ± 0.001M/s ( 2.055M/s/cpu)uretprobe-nop ( 2 cpus): 2.677 ± 0.000M/s ( 1.339M/s/cpu)uretprobe-nop ( 4 cpus): 4.561 ± 0.003M/s ( 1.140M/s/cpu)uretprobe-nop ( 8 cpus): 5.291 ± 0.002M/s ( 0.661M/s/cpu)uretprobe-nop (16 cpus): 5.065 ± 0.019M/s ( 0.317M/s/cpu)uretprobe-nop (32 cpus): 3.622 ± 0.003M/s ( 0.113M/s/cpu)uretprobe-nop (64 cpus): 3.723 ± 0.002M/s ( 0.058M/s/cpu)RCU Tasks Trace===============uprobe-nop ( 1 cpus): 3.396 ± 0.002M/s ( 3.396M/s/cpu)uprobe-nop ( 2 cpus): 4.271 ± 0.006M/s ( 2.135M/s/cpu)uprobe-nop ( 4 cpus): 8.499 ± 0.015M/s ( 2.125M/s/cpu)uprobe-nop ( 8 cpus): 10.355 ± 0.028M/s ( 1.294M/s/cpu)uprobe-nop (16 cpus): 7.615 ± 0.099M/s ( 0.476M/s/cpu)uprobe-nop (32 cpus): 4.430 ± 0.007M/s ( 0.138M/s/cpu)uprobe-nop (64 cpus): 6.887 ± 0.020M/s ( 0.108M/s/cpu)uretprobe-nop ( 1 cpus): 2.174 ± 0.001M/s ( 2.174M/s/cpu)uretprobe-nop ( 2 cpus): 2.853 ± 0.001M/s ( 1.426M/s/cpu)uretprobe-nop ( 4 cpus): 4.913 ± 0.002M/s ( 1.228M/s/cpu)uretprobe-nop ( 8 cpus): 5.883 ± 0.002M/s ( 0.735M/s/cpu)uretprobe-nop (16 cpus): 5.147 ± 0.001M/s ( 0.322M/s/cpu)uretprobe-nop (32 cpus): 3.738 ± 0.008M/s ( 0.117M/s/cpu)uretprobe-nop (64 cpus): 4.397 ± 0.002M/s ( 0.069M/s/cpu)Peak throughput for uprobes increases from 8 mln/s to 10.3 mln/s(+28%!), and for uretprobes from 5.3 mln/s to 5.8 mln/s (+11%), as wehave more work to do on uretprobes side.Even single-thread (no contention) performance is slightly better: 3.276mln/s to 3.396 mln/s (+3.5%) for uprobes, and 2.055 mln/s to 2.174 mln/s(+5.8%) for uretprobes.We also select TASKS_TRACE_RCU for UPROBES in Kconfig due to the newdependency.Signed-off-by: Andrii Nakryiko Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Oleg Nesterov Link: https://lkml.kernel.org/r/20240910174312.3646590-1-andrii@kernel.org List of files: /linux-6.15/arch/Kconfig

4c66f830 - cfi: encode cfi normalized integers + kasan/gcov bug in Kconfig

Wed, 25 Sep 2024 08:10:18 +0000

cfi: encode cfi normalized integers + kasan/gcov bug in KconfigThere is a bug in the LLVM implementation of KASAN and GCOV that makesthese options incompatible with the CFI_ICALL_NORMALIZE_INTEGERS option.The bug has already been fixed in llvm/clang [1] and rustc [2]. However,Kconfig currently has no way to gate features on the LLVM version insiderustc, so we cannot write down a precise `depends on` clause in thiscase. Instead, a `def_bool` option is defined for whetherCFI_ICALL_NORMALIZE_INTEGERS is available, and its default value is setto false when GCOV or KASAN are turned on. End users using a patchedclang/rustc can turn on the HAVE_CFI_ICALL_NORMALIZE_INTEGERS optiondirectly to override this.An alternative solution is to inspect a binary created by clang or rustcto see whether the faulty CFI tags are in the binary. This would be aprecise check, but it would involve hard-coding the *hashed* version ofthe CFI tag. This is because there's no way to get clang or rustc tooutput the unhased version of the CFI tag. Relying on the precisehashing algorithm using by CFI seems too fragile, so I have not pursuedthis option. Besides, this kind of hack is exactly what lead to the LLVMbug in the first place.If the CFI_ICALL_NORMALIZE_INTEGERS option is used without CONFIG_RUST,then we actually can perform a precise check today: just compare theclang version number. This works since clang and llvm are always updatedin lockstep. However, encoding this in Kconfig would give theHAVE_CFI_ICALL_NORMALIZE_INTEGERS option a dependency on CONFIG_RUST,which is not possible as the reverse dependency already exists.HAVE_CFI_ICALL_NORMALIZE_INTEGERS is defined to be a `def_bool` insteadof `bool` to avoid asking end users whether they want to turn on theoption. Turning it on explicitly is something only experts should do, somaking it hard to do so is not an issue.I added a `depends on CFI_CLANG` clause to the new Kconfig option. I'mnot sure whether that makes sense or not, but it doesn't seem to make abig difference.In a future kernel release, I would like to add a Kconfig option similarto CLANG_VERSION/RUSTC_VERSION for inspecting the version of the LLVMinside rustc. Once that feature lands, this logic will be replaced witha precise version check. This check is not being introduced here toavoid introducing a new _VERSION constant in a fix.Link: https://github.com/llvm/llvm-project/pull/104826 [1]Link: https://github.com/rust-lang/rust/pull/129373 [2]Fixes: ce4a2620985c ("cfi: add CONFIG_CFI_ICALL_NORMALIZE_INTEGERS")Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202409231044.4f064459-oliver.sang@intel.comSigned-off-by: Alice Ryhl Reviewed-by: Sami Tolvanen Link: https://lore.kernel.org/r/20240925-cfi-norm-kasan-fix-v1-1-0328985cdf33@google.comSigned-off-by: Miguel Ojeda List of files: /linux-6.15/arch/Kconfig

ce4a2620 - cfi: add CONFIG_CFI_ICALL_NORMALIZE_INTEGERS

Thu, 01 Aug 2024 13:35:17 +0000

cfi: add CONFIG_CFI_ICALL_NORMALIZE_INTEGERSIntroduce a Kconfig option for enabling the experimental option tonormalize integer types. This ensures that integer types of the samesize and signedness are considered compatible by the Control FlowIntegrity sanitizer.The security impact of this flag is minimal. When Sami Tolvanen lookedinto it, he found that integer normalization reduced the number ofunique type hashes in the kernel by ~1%, which is acceptable.This option exists for compatibility with Rust, as C and Rust do nothave the same set of integer types. There are cases where C has twodifferent integer types of the same size and signedness, but Rust onlyhas one integer type of that size and signedness. When Rust calls intoC functions using such types in their signature, this results in CFIfailures. One example is 'unsigned long long' and 'unsigned long' whichare both 64-bit on LP64 targets, so on those targets this flag will giveboth types the same CFI tag.This flag changes the ABI heavily. It is not applied automatically whenCONFIG_RUST is turned on to make sure that the CONFIG_RUST option doesnot change the ABI of C code. For example, some build may need to makeother changes atomically with toggling this flag. Having it be aseparate option makes it possible to first turn on normalized integertags, and then later turn on CONFIG_RUST.Similarly, when turning on CONFIG_RUST in a build, you may need a fewattempts where the RUST=y commit gets reverted a few times. It isinconvenient if reverting RUST=y also requires reverting the changes youmade to support normalized integer tags.To avoid having this flag impact builds that don't care about this, thenext patch in this series will make CONFIG_RUST turn on this optionusing `select` rather than `depends on`.Signed-off-by: Alice Ryhl Reviewed-by: Sami Tolvanen Tested-by: Gatlin Newhouse Acked-by: Kees Cook Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20240801-kcfi-v2-1-c93caed3d121@google.comSigned-off-by: Miguel Ojeda List of files: /linux-6.15/arch/Kconfig

de6c85bf - dma-mapping: clearly mark DMA ops as an architecture feature

Wed, 28 Aug 2024 06:02:47 +0000

dma-mapping: clearly mark DMA ops as an architecture featureDMA ops are a helper for architectures and not for drivers to overridethe DMA implementation.Unfortunately driver authors keep ignoring this. Make the fact moreclear by renaming the symbol to ARCH_HAS_DMA_OPS and having the two driversoverriding their dma_ops depend on that. These drivers should probably bemarked broken, but we can give them a bit of a grace period for that.Signed-off-by: Christoph Hellwig Reviewed-by: Thomas Gleixner Acked-by: Sakari Ailus # for IPU6Acked-by: Robin Murphy List of files: /linux-6.15/arch/Kconfig

d65d411c - treewide: context_tracking: Rename CONTEXT_* into CT_STATE_*

Tue, 25 Jul 2023 11:08:50 +0000

treewide: context_tracking: Rename CONTEXT_* into CT_STATE_*Context tracking state related symbols currently use a mix of theCONTEXT_ (e.g. CONTEXT_KERNEL) and CT_SATE_ (e.g. CT_STATE_MASK) prefixes.Clean up the naming and make the ctx_state enum use the CT_STATE_ prefix.Suggested-by: Frederic Weisbecker Signed-off-by: Valentin Schneider Acked-by: Frederic Weisbecker Acked-by: Thomas Gleixner Signed-off-by: Neeraj Upadhyay List of files: /linux-6.15/arch/Kconfig

14d7c92f - Revert "mm: mmap: allow for the maximum number of bits for randomizing mmap_base by default"

Mon, 17 Jun 2024 19:57:03 +0000

Revert "mm: mmap: allow for the maximum number of bits for randomizing mmap_base by default"This reverts commit 3afb76a66b5559a7b595155803ce23801558a7a9.This was a wrongheaded workaround for an issue that had already beenfixed much better by commit 4ef9ad19e176 ("mm: huge_memory: don't forcehuge page alignment on 32 bit").Asking users questions at kernel compile time that they can't make senseof is not a viable strategy. And the fact that even the kernel VMmaintainers apparently didn't catch that this "fix" is not a fix anymore pretty much proves the point that people can't be expected tounderstand the implications of the question.It may well be the case that we could improve things further, and that__thp_get_unmapped_area() should take the mapping randomization intoaccount even for 64-bit kernels. Maybe we should not be so eager to useTHP mappings.But in no case should this be a kernel config option.Cc: Rafael Aquini Cc: Andrew Morton Cc: Jiri Slaby Cc: Suren Baghdasaryan Cc: Matthew Wilcox (Oracle) Signed-off-by: Linus Torvalds List of files: /linux-6.15/arch/Kconfig

3afb76a6 - mm: mmap: allow for the maximum number of bits for randomizing mmap_base by default

Thu, 06 Jun 2024 18:06:22 +0000

mm: mmap: allow for the maximum number of bits for randomizing mmap_base by defaultAn ASLR regression was noticed [1] and tracked down to file-mapped areasbeing backed by THP in recent kernels. The 21-bit alignment constraintfor such mappings reduces the entropy for randomizing the placement of64-bit library mappings and breaks ASLR completely for 32-bit libraries.The reported issue is easily addressed by increasing vm.mmap_rnd_bits andvm.mmap_rnd_compat_bits. This patch just provides a simple way to setARCH_MMAP_RND_BITS and ARCH_MMAP_RND_COMPAT_BITS to their maximum valuesallowed by the architecture at build time.[1] https://zolutal.github.io/aslrnt/[akpm@linux-foundation.org: default to `y' if 32-bit, per Rafael]Link: https://lkml.kernel.org/r/20240606180622.102099-1-aquini@redhat.comFixes: 1854bc6e2420 ("mm/readahead: Align file mappings for non-DAX")Signed-off-by: Rafael Aquini Cc: Arnd Bergmann Cc: Heiko Carstens Cc: Mike Rapoport (IBM) Cc: Paul E. McKenney Cc: Petr Mladek Cc: Samuel Holland Cc: Signed-off-by: Andrew Morton List of files: /linux-6.15/arch/Kconfig

6cbd1d6d - arch: add ARCH_HAS_KERNEL_FPU_SUPPORT

Fri, 29 Mar 2024 07:18:16 +0000

arch: add ARCH_HAS_KERNEL_FPU_SUPPORTSeveral architectures provide an API to enable the FPU and runfloating-point SIMD code in kernel space. However, the function names,header locations, and semantics are inconsistent across architectures, andFPU support may be gated behind other Kconfig options.provide a standard way for architectures to declare that kernel spaceFPU support is available. Architectures selecting this option mustimplement what is currently the most common API (kernel_fpu_begin() andkernel_fpu_end(), plus a new function kernel_fpu_available()) andprovide the appropriate CFLAGS for compiling floating-point C code.Link: https://lkml.kernel.org/r/20240329072441.591471-2-samuel.holland@sifive.comSigned-off-by: Samuel Holland Suggested-by: Christoph Hellwig Reviewed-by: Christoph Hellwig Acked-by: Christian König Cc: Alex Deucher Cc: Borislav Petkov (AMD) Cc: Catalin Marinas Cc: Dave Hansen Cc: Huacai Chen Cc: Ingo Molnar Cc: Jonathan Corbet Cc: Masahiro Yamada Cc: Michael Ellerman Cc: Nathan Chancellor Cc: Nicolas Schier Cc: Palmer Dabbelt Cc: Russell King Cc: Thomas Gleixner Cc: WANG Xuerui Cc: Will Deacon Signed-off-by: Andrew Morton List of files: /linux-6.15/arch/Kconfig

7582b7be - kprobes: remove dependency on CONFIG_MODULES

Sun, 05 May 2024 16:06:27 +0000

kprobes: remove dependency on CONFIG_MODULESkprobes depended on CONFIG_MODULES because it has to allocate memory forcode.Since code allocations are now implemented with execmem, kprobes can beenabled in non-modular kernels.Add #ifdef CONFIG_MODULE guards for the code dealing with kprobes insidemodules, make CONFIG_KPROBES select CONFIG_EXECMEM and drop thedependency of CONFIG_KPROBES on CONFIG_MODULES.Signed-off-by: Mike Rapoport (IBM) Acked-by: Masami Hiramatsu (Google) [mcgrof: rebase in light of NEED_TASKS_RCU ]Signed-off-by: Luis Chamberlain List of files: /linux-6.15/arch/Kconfig

223b5e57 - mm/execmem, arch: convert remaining overrides of module_alloc to execmem

Sun, 05 May 2024 16:06:20 +0000

mm/execmem, arch: convert remaining overrides of module_alloc to execmemExtend execmem parameters to accommodate more complex overrides ofmodule_alloc() by architectures.This includes specification of a fallback range required by arm, arm64and powerpc, EXECMEM_MODULE_DATA type required by powerpc, support forallocation of KASAN shadow required by s390 and x86 and support forlate initialization of execmem required by arm64.The core implementation of execmem_alloc() takes care of suppressingwarnings when the initial allocation fails but there is a fallback rangedefined.Signed-off-by: Mike Rapoport (IBM) Acked-by: Will Deacon Acked-by: Song Liu Tested-by: Liviu Dudau Signed-off-by: Luis Chamberlain List of files: /linux-6.15/arch/Kconfig