Changes in Kconfig

d1b99cdf - init: remove unused CONFIG_CC_CAN_LINK_STATIC

Fri, 09 May 2025 13:23:59 +0000

init: remove unused CONFIG_CC_CAN_LINK_STATICThis is a leftover from commit 98e20e5e13d2 ("bpfilter: remove bpfilter").Signed-off-by: Masahiro Yamada List of files: /linux-6.15/init/Kconfig

7129ea6e - rust: clean Rust 1.88.0's `unnecessary_transmutes` lint

Fri, 02 May 2025 14:02:35 +0000

rust: clean Rust 1.88.0's `unnecessary_transmutes` lintStarting with Rust 1.88.0 (expected 2025-06-26) [1][2], `rustc` mayintroduce a new lint that catches unnecessary transmutes, e.g.: error: unnecessary transmute --> rust/uapi/uapi_generated.rs:23242:18 | 23242 | unsafe { ::core::mem::transmute(self._bitfield_1.get(0usize, 1u8) as u8) } | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: replace this with: `(self._bitfield_1.get(0usize, 1u8) as u8 == 1)` | = note: `-D unnecessary-transmutes` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(unnecessary_transmutes)]`There are a lot of them (at least 300), but luckily they are all in`bindgen`-generated code.Thus clean all up by allowing it there.Since unknown lints trigger a lint itself in older compilers, do itconditionally so that we can keep the `unknown_lints` lint enabled.Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).Link: https://github.com/rust-lang/rust/pull/136083 [1]Link: https://github.com/rust-lang/rust/issues/136067 [2]Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20250502140237.1659624-4-ojeda@kernel.orgSigned-off-by: Miguel Ojeda List of files: /linux-6.15/init/Kconfig

c443279a - Kconfig: switch CONFIG_SYSFS_SYCALL default to n

Tue, 15 Apr 2025 08:22:04 +0000

Kconfig: switch CONFIG_SYSFS_SYCALL default to nThis odd system call will be removed in the future. Let's decouple itfrom CONFIG_EXPERT and switch the default to n as a first step.Link: https://lore.kernel.org/20250415-dezimieren-wertpapier-9fd18a211a41@braunerSigned-off-by: Christian Brauner List of files: /linux-6.15/init/Kconfig

97577684 - sched/isolation: Make CONFIG_CPU_ISOLATION depend on CONFIG_SMP

Sun, 30 Mar 2025 13:49:55 +0000

sched/isolation: Make CONFIG_CPU_ISOLATION depend on CONFIG_SMPkernel/sched/isolation.c obviously makes no sense without CONFIG_SMP, butthe Kconfig entry we have right now: config CPU_ISOLATION bool "CPU isolation" depends on SMP || COMPILE_TESTallows the creation of pointless .config's which causebuild failures.Reported-by: kernel test robot Signed-off-by: Oleg Nesterov Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20250330134955.GA7910@redhat.comCloses: https://lore.kernel.org/oe-kbuild-all/202503260646.lrUqD3j5-lkp@intel.com/ List of files: /linux-6.15/init/Kconfig

5796d396 - mseal sysmap: kernel config and header change

Wed, 05 Mar 2025 02:17:05 +0000

mseal sysmap: kernel config and header changePatch series "mseal system mappings", v9.As discussed during mseal() upstream process [1], mseal() protects theVMAs of a given virtual memory range against modifications, such as theread/write (RW) and no-execute (NX) bits. For complete descriptions ofmemory sealing, please see mseal.rst [2].The mseal() is useful to mitigate memory corruption issues where acorrupted pointer is passed to a memory management system. For example,such an attacker primitive can break control-flow integrity guaranteessince read-only memory that is supposed to be trusted can become writableor .text pages can get remapped.The system mappings are readonly only, memory sealing can protect themfrom ever changing to writable or unmmap/remapped as different attributes.System mappings such as vdso, vvar, vvar_vclock, vectors (armcompat-mode), sigpage (arm compat-mode), are created by the kernel duringprogram initialization, and could be sealed after creation.Unlike the aforementioned mappings, the uprobe mapping is not establishedduring program startup. However, its lifetime is the same as theprocess's lifetime [3]. It could be sealed from creation.The vsyscall on x86-64 uses a special address (0xffffffffff600000), whichis outside the mm managed range. This means mprotect, munmap, and mremapwon't work on the vsyscall. Since sealing doesn't enhance the vsyscall'ssecurity, it is skipped in this patch. If we ever seal the vsyscall, itis probably only for decorative purpose, i.e. showing the 'sl' flag inthe /proc/pid/smaps. For this patch, it is ignored.It is important to note that the CHECKPOINT_RESTORE feature (CRIU) mayalter the system mappings during restore operations. UML(User Mode Linux)and gVisor, rr are also known to change the vdso/vvar mappings. Consequently, this feature cannot be universally enabled across allsystems. As such, CONFIG_MSEAL_SYSTEM_MAPPINGS is disabled by default.To support mseal of system mappings, architectures must defineCONFIG_ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS and update their specialmappings calls to pass mseal flag. Additionally, architectures mustconfirm they do not unmap/remap system mappings during the processlifetime. The existence of this flag for an architecture implies that itdoes not require the remapping of thest system mappings during processlifetime, so sealing these mappings is safe from a kernel perspective.This version covers x86-64 and arm64 archiecture as minimum viable feature.While no specific CPU hardware features are required for enable thisfeature on an archiecture, memory sealing requires a 64-bit kernel. Otherarchitectures can choose whether or not to adopt this feature. Currently,I'm not aware of any instances in the kernel code that activelymunmap/mremap a system mapping without a request from userspace. The PPCdoes call munmap when _install_special_mapping fails for vdso; however,it's uncertain if this will ever fail for PPC - this needs to beinvestigated by PPC in the future [4]. The UML kernel can add thissupport when KUnit tests require it [5].In this version, we've improved the handling of system mapping sealingfrom previous versions, instead of modifying the _install_special_mappingfunction itself, which would affect all architectures, we now call_install_special_mapping with a sealing flag only within the specificarchitecture that requires it. This targeted approach offers two keyadvantages: 1) It limits the code change's impact to the necessaryarchitectures, and 2) It aligns with the software architecture by keepingthe core memory management within the mm layer, while delegating thedecision of sealing system mappings to the individual architecture, whichis particularly relevant since 32-bit architectures never require sealing.Prior to this patch series, we explored sealing special mappings fromuserspace using glibc's dynamic linker. This approach revealed severalissues:- The PT_LOAD header may report an incorrect length for vdso, (smaller than its actual size). The dynamic linker, which relies on PT_LOAD information to determine mapping size, would then split and partially seal the vdso mapping. Since each architecture has its own vdso/vvar code, fixing this in the kernel would require going through each archiecture. Our initial goal was to enable sealing readonly mappings, e.g. .text, across all architectures, sealing vdso from kernel since creation appears to be simpler than sealing vdso at glibc.- The [vvar] mapping header only contains address information, not length information. Similar issues might exist for other special mappings.- Mappings like uprobe are not covered by the dynamic linker, and there is no effective solution for them.This feature's security enhancements will benefit ChromeOS, Android, andother high security systems.Testing:This feature was tested on ChromeOS and Android for both x86-64 and ARM64.- Enable sealing and verify vdso/vvar, sigpage, vector are sealed properly, i.e. "sl" shown in the smaps for those mappings, and mremap is blocked.- Passing various automation tests (e.g. pre-checkin) on ChromeOS and Android to ensure the sealing doesn't affect the functionality of Chromebook and Android phone.I also tested the feature on Ubuntu on x86-64:- With config disabled, vdso/vvar is not sealed,- with config enabled, vdso/vvar is sealed, and booting up Ubuntu is OK, normal operations such as browsing the web, open/edit doc are OK.Link: https://lore.kernel.org/all/20240415163527.626541-1-jeffxu@chromium.org/ [1]Link: Documentation/userspace-api/mseal.rst [2]Link: https://lore.kernel.org/all/CABi2SkU9BRUnqf70-nksuMCQ+yyiWjo3fM4XkRkL-NrCZxYAyg@mail.gmail.com/ [3]Link: https://lore.kernel.org/all/CABi2SkV6JJwJeviDLsq9N4ONvQ=EFANsiWkgiEOjyT9TQSt+HA@mail.gmail.com/ [4]Link: https://lore.kernel.org/all/202502251035.239B85A93@keescook/ [5]This patch (of 7):Provide infrastructure to mseal system mappings. Establish two kernelconfigs (CONFIG_MSEAL_SYSTEM_MAPPINGS,ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS) and VM_SEALED_SYSMAP macro for futurepatches.Link: https://lkml.kernel.org/r/20250305021711.3867874-1-jeffxu@google.comLink: https://lkml.kernel.org/r/20250305021711.3867874-2-jeffxu@google.comSigned-off-by: Jeff Xu Reviewed-by: Kees Cook Reviewed-by: Liam R. Howlett Reviewed-by: Lorenzo Stoakes Cc: Adhemerval Zanella Cc: Alexander Mikhalitsyn Cc: Alexey Dobriyan Cc: Andrei Vagin Cc: Anna-Maria Behnsen Cc: Ard Biesheuvel Cc: Benjamin Berg Cc: Christoph Hellwig Cc: Dave Hansen Cc: David Rientjes Cc: David S. Miller Cc: Elliot Hughes Cc: Florian Faineli Cc: Greg Ungerer Cc: Guenter Roeck Cc: Heiko Carstens Cc: Helge Deller Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>Cc: Ingo Molnar Cc: Jann Horn Cc: Jason A. Donenfeld Cc: Johannes Berg Cc: Jorge Lucangeli Obes Cc: Linus Waleij Cc: Mark Rutland Cc: Matthew Wilcow (Oracle) Cc: Michael Ellerman Cc: Michal Hocko Cc: Miguel Ojeda Cc: Mike Rapoport Cc: Oleg Nesterov Cc: Pedro Falcato Cc: Peter Xu Cc: Randy Dunlap Cc: Stephen Röttger Cc: Thomas Weißschuh Cc: Vlastimil Babka Signed-off-by: Andrew Morton List of files: /linux-6.15/init/Kconfig

e7607f7d - ARM: 9443/1: Require linker to support KEEP within OVERLAY for DCE

Thu, 20 Mar 2025 21:33:49 +0000

ARM: 9443/1: Require linker to support KEEP within OVERLAY for DCEld.lld prior to 21.0.0 does not support using the KEEP keyword within anoverlay description, which may be needed to avoid discarding necessarysections within an overlay with '--gc-sections', which can be enabledfor the kernel via CONFIG_LD_DEAD_CODE_DATA_ELIMINATION.Disallow CONFIG_LD_DEAD_CODE_DATA_ELIMINATION without support for KEEPwithin OVERLAY and introduce a macro, OVERLAY_KEEP, that can be used toconditionally add KEEP when it is properly supported to avoid breakingold versions of ld.lld.Cc: stable@vger.kernel.orgLink: https://github.com/llvm/llvm-project/commit/381599f1fe973afad3094e55ec99b1620dba7d8cReviewed-by: Linus Walleij Signed-off-by: Nathan Chancellor Signed-off-by: Russell King (Oracle) List of files: /linux-6.15/init/Kconfig

b688f369 - compiler_types: Introduce __nonstring_array

Mon, 10 Mar 2025 21:42:48 +0000

compiler_types: Introduce __nonstring_arrayGCC has expanded support of the "nonstring" attribute so that it can beapplied to arrays of character arrays[1], which is needed to identifycorrect static initialization of those kinds of objects. Since this wasnot supported prior to GCC 15, we need to distinguish the usage of Linux'sexisting __nonstring macro for the attribute for non-multi-dimensionalchar arrays. Until GCC 15 is the minimum version, use __nonstring_array tomark arrays of non-string character arrays. (Regular non-string characterarrays can continue to use __nonstring.) Once GCC 15 is the minimumcompiler version we can replace all uses of __nonstring_array with just__nonstring and remove this macro.This allows for changes like this:-static const char table_sigs[][ACPI_NAMESEG_SIZE] __initconst = {+static const char table_sigs[][ACPI_NAMESEG_SIZE] __nonstring_array __initconst = { ACPI_SIG_BERT, ACPI_SIG_BGRT, ACPI_SIG_CPEP, ACPI_SIG_ECDT,Which will silence the coming -Wunterminated-string-initializationwarnings in GCC 15:In file included from ../include/acpi/actbl.h:371, from ../include/acpi/acpi.h:26, from ../include/linux/acpi.h:26, from ../drivers/acpi/tables.c:19:../include/acpi/actbl1.h:30:33: warning: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (5 chars into 4 available) [-Wunterminated-string-initialization] 30 | #define ACPI_SIG_BERT "BERT" /* Boot Error Record Table */ | ^~~~~~ ../drivers/acpi/tables.c:400:9: note: in expansion of macro 'ACPI_SIG_BERT' 400 | ACPI_SIG_BERT, ACPI_SIG_BGRT, ACPI_SIG_CPEP, ACPI_SIG_ECDT, | ^~~~~~~~~~~~~ ../include/acpi/actbl1.h:31:33: warning: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (5 chars into 4 available) [-Wunterminated-string-initialization] 31 | #define ACPI_SIG_BGRT "BGRT" /* Boot Graphics Resource Table */ | ^~~~~~Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 [1]Acked-by: Miguel Ojeda Link: https://lore.kernel.org/r/20250310214244.work.194-kees@kernel.orgSigned-off-by: Kees Cook List of files: /linux-6.15/init/Kconfig

5daa0c35 - rust: Disallow BTF generation with Rust + LTO

Wed, 08 Jan 2025 23:35:08 +0000

rust: Disallow BTF generation with Rust + LTOThe kernel cannot currently self-parse BTF containing Rust debuginformation. pahole uses the language of the CU to determine whether tofilter out debug information when generating the BTF. When LTO isenabled, Rust code can cross CU boundaries, resulting in Rust debuginformation in CUs labeled as C. This results in a system which cannotparse its own BTF.Signed-off-by: Matthew Maurer Cc: stable@vger.kernel.orgFixes: c1177979af9c ("btf, scripts: Exclude Rust CUs with pahole")Link: https://lore.kernel.org/r/20250108-rust-btf-lto-incompat-v1-1-60243ff6d820@google.comSigned-off-by: Miguel Ojeda List of files: /linux-6.15/init/Kconfig

83c0b272 - initramfs_test: kunit tests for initramfs unpacking

Tue, 04 Mar 2025 05:57:45 +0000

initramfs_test: kunit tests for initramfs unpackingProvide some basic initramfs unpack sanity tests covering:- simple file / dir extraction- filename field overrun, as reported and fixed separately via https://lore.kernel.org/r/20241030035509.20194-2-ddiss@suse.de- "070702" cpio data checksums- hardlinksSigned-off-by: David Disseldorp Link: https://lore.kernel.org/r/20250304061020.9815-3-ddiss@suse.deSigned-off-by: Christian Brauner List of files: /linux-6.15/init/Kconfig

01157ddc - kallsyms: Remove KALLSYMS_ABSOLUTE_PERCPU

Thu, 23 Jan 2025 19:07:47 +0000

kallsyms: Remove KALLSYMS_ABSOLUTE_PERCPUx86-64 was the only user.Signed-off-by: Brian Gerst Signed-off-by: Ingo Molnar Reviewed-by: Ard Biesheuvel Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250123190747.745588-16-brgerst@gmail.com List of files: /linux-6.15/init/Kconfig

9d7de2aa - x86/percpu/64: Use relative percpu offsets

Thu, 23 Jan 2025 19:07:40 +0000

x86/percpu/64: Use relative percpu offsetsThe percpu section is currently linked at absolute address 0, becauseolder compilers hard-coded the stack protector canary value at a fixedoffset from the start of the GS segment. Now that the canary is anormal percpu variable, the percpu section does not need to be linkedat a specific address.x86-64 will now calculate the percpu offsets as the delta between theinitial percpu address and the dynamically allocated memory, like otherarchitectures. Note that GSBASE is limited to the canonical addresswidth (48 or 57 bits, sign-extended). As long as the kernel text,modules, and the dynamically allocated percpu memory are all in thenegative address space, the delta will not overflow this limit.Signed-off-by: Brian Gerst Signed-off-by: Ingo Molnar Reviewed-by: Ard Biesheuvel Reviewed-by: Uros Bizjak Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250123190747.745588-9-brgerst@gmail.com List of files: /linux-6.15/init/Kconfig

dae68fba - cgroup/cpuset: Move procfs cpuset attribute under cgroup-v1.c

Mon, 20 Jan 2025 14:57:49 +0000

cgroup/cpuset: Move procfs cpuset attribute under cgroup-v1.cThe cpuset file is a legacy attribute that is bound primarily to cpusetv1 hierarchy (equivalent information is available in /proc/$pid/cgroup pathon the unified hierarchy in conjunction with respectivecgroup.controllers showing where cpuset controller is enabled).Followup to commit b0ced9d378d49 ("cgroup/cpuset: move v1 interfaces tocpuset-v1.c") and hide CONFIG_PROC_PID_CPUSET under CONFIG_CPUSETS_V1.Drop an obsolete comment too.Signed-off-by: Michal Koutný Acked-by: Waiman Long Signed-off-by: Tejun Heo List of files: /linux-6.15/init/Kconfig

ac61506b - rust: Use gendwarfksyms + extended modversions for CONFIG_MODVERSIONS

Fri, 03 Jan 2025 17:37:05 +0000

rust: Use gendwarfksyms + extended modversions for CONFIG_MODVERSIONSPreviously, two things stopped Rust from using MODVERSIONS:1. Rust symbols are occasionally too long to be represented in the original versions table2. Rust types cannot be properly hashed by the existing genksyms approach because: * Looking up type definitions in Rust is more complex than C * Type layout is potentially dependent on the compiler in Rust, not just the source type declaration.CONFIG_EXTENDED_MODVERSIONS addresses the first point, andCONFIG_GENDWARFKSYMS the second. If Rust wants to use MODVERSIONS, allowit to do so by selecting both features.Signed-off-by: Sami Tolvanen Co-developed-by: Matthew Maurer Signed-off-by: Matthew Maurer Signed-off-by: Masahiro Yamada List of files: /linux-6.15/init/Kconfig

bea6afc1 - cgroup/rdma: Drop bogus PAGE_COUNTER select

Thu, 16 Jan 2025 09:56:35 +0000

cgroup/rdma: Drop bogus PAGE_COUNTER selectWhen adding the Device memory controller (DMEM), "select PAGE_COUNTER"was added to CGROUP_RDMA, presumably instead of CGROUP_DMEM.While commit e33b51499a0a6bca ("cgroup/dmem: Select PAGE_COUNTER") addedthe missing select to CGROUP_DMEM, the bogus select is still there.Remove it.Fixes: b168ed458ddecc17 ("kernel/cgroup: Add "dmem" memory accounting cgroup")Closes: https://lore.kernel.org/CAMuHMdUmPfahsnZwx2iB5yfh8rjjW25LNcnYujNBgcKotUXBNg@mail.gmail.comSigned-off-by: Geert Uytterhoeven Acked-by: Tejun Heo Link: https://patchwork.freedesktop.org/patch/msgid/b4d462f038a2f895f30ae759928397c8183f6f7e.1737020925.git.geert+renesas@glider.beSigned-off-by: Maxime Ripard List of files: /linux-6.15/init/Kconfig

e33b5149 - cgroup/dmem: Select PAGE_COUNTER

Mon, 13 Jan 2025 09:26:05 +0000

cgroup/dmem: Select PAGE_COUNTERThe dmem cgroup the page counting API implemented behing thePAGE_COUNTER kconfig option. However, it doesn't select it, resulting inpotential build breakages. Select PAGE_COUNTER.Fixes: b168ed458dde ("kernel/cgroup: Add "dmem" memory accounting cgroup")Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202501111330.3VuUx8vf-lkp@intel.com/Acked-by: Tejun Heo Reviewed-by: Simona Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20250113092608.1349287-1-mripard@kernel.orgSigned-off-by: Maxime Ripard List of files: /linux-6.15/init/Kconfig

47cb6bf7 - rust: use derive(CoercePointee) on rustc >= 1.84.0

Tue, 03 Dec 2024 20:47:49 +0000

rust: use derive(CoercePointee) on rustc >= 1.84.0The `kernel` crate relies on both `coerce_unsized` and `dispatch_from_dyn`unstable features.Alice Ryhl has proposed [1] the introduction of the unstable macro`SmartPointer` to reduce such dependence, along with a RFC patch [2].Since Rust 1.81.0 this macro, later renamed to `CoercePointee` inRust 1.84.0 [3], has been fully implemented with the naming discussionresolved.This feature is now on track to stabilization in the language.In order to do so, we shall start using this macro in the `kernel` crateto prove the functionality and utility of the macro as the justificationof its stabilization.This patch makes this switch in such a way that the crate remainsbackward compatible with older Rust compiler versions,via the new Kconfig option `RUSTC_HAS_COERCE_POINTEE`.A minimal demonstration example is added to the`samples/rust/rust_print_main.rs` module.Link: https://rust-lang.github.io/rfcs/3621-derive-smart-pointer.html [1]Link: https://lore.kernel.org/all/20240823-derive-smart-pointer-v1-1-53769cd37239@google.com/ [2]Link: https://github.com/rust-lang/rust/pull/131284 [3]Signed-off-by: Xiangfei Ding Reviewed-by: Fiona Behrens Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20241203205050.679106-2-dingxiangfei2009@gmail.com[ Fixed version to 1.84. Renamed option to `RUSTC_HAS_COERCE_POINTEE` to match `CC_HAS_*` ones. Moved up new config option, closer to the `CC_HAS_*` ones. Simplified Kconfig line. Fixed typos and slightly reworded example and commit. Added Link to PR. - Miguel ]Signed-off-by: Miguel Ojeda List of files: /linux-6.15/init/Kconfig

c23d1f7e - rust: document `bindgen` 0.71.0 regression

Mon, 09 Dec 2024 21:25:44 +0000

rust: document `bindgen` 0.71.0 regression`bindgen` 0.71.0 regressed [1] on the "`--version` requires header"issue which appeared in 0.69.0 first [2] and was fixed in 0.69.1. Ithas been fixed again in 0.71.1 [3].Thus document it so that, when we upgrade the minimum past 0.69.0 in thefuture, we do not forget that we cannot remove the workaround until wearrive at 0.71.1 at least.Link: https://github.com/rust-lang/rust-bindgen/issues/3039 [1]Link: https://github.com/rust-lang/rust-bindgen/issues/2677 [2]Link: https://github.com/rust-lang/rust-bindgen/blob/main/CHANGELOG.md#v0711-2024-12-09 [3]Reviewed-by: Fiona Behrens Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20241209212544.1977065-1-ojeda@kernel.orgSigned-off-by: Miguel Ojeda List of files: /linux-6.15/init/Kconfig

b168ed45 - kernel/cgroup: Add "dmem" memory accounting cgroup

Wed, 04 Dec 2024 14:31:11 +0000

kernel/cgroup: Add "dmem" memory accounting cgroupThis code is based on the RDMA and misc cgroup initially, but nowuses page_counter. It uses the same min/low/max semantics as the memorycgroup as a result.There's a small mismatch as TTM uses u64, and page_counter long pages.In practice it's not a problem. 32-bits systems don't really come with>=4GB cards and as long as we're consistently wrong with units, it'sfine. The device page size may not be in the same units as kernel pagesize, and each region might also have a different page size (VRAM vs GARTfor example).The interface is simple:- Call dmem_cgroup_register_region()- Use dmem_cgroup_try_charge to check if you can allocate a chunk of memory, use dmem_cgroup__uncharge when freeing it. This may return an error code, or -EAGAIN when the cgroup limit is reached. In that case a reference to the limiting pool is returned.- The limiting cs can be used as compare function for dmem_cgroup_state_evict_valuable.- After having evicted enough, drop reference to limiting cs with dmem_cgroup_pool_state_put.This API allows you to limit device resources with cgroups.You can see the supported cards in /sys/fs/cgroup/dmem.capacityYou need to echo +dmem to cgroup.subtree_control, and then you canpartition device memory.Co-developed-by: Friedrich Vock Signed-off-by: Friedrich Vock Co-developed-by: Maxime Ripard Signed-off-by: Maarten Lankhorst Acked-by: Tejun Heo Link: https://lore.kernel.org/r/20241204143112.1250983-1-dev@lankhorst.seSigned-off-by: Maxime Ripard List of files: /linux-6.15/init/Kconfig

f06e108a - Compiler Attributes: disable __counted_by for clang < 19.1.3

Tue, 29 Oct 2024 14:00:36 +0000

Compiler Attributes: disable __counted_by for clang < 19.1.3This patch disables __counted_by for clang versions < 19.1.3 becauseof the two issues listed below. It does this by introducingCONFIG_CC_HAS_COUNTED_BY.1. clang < 19.1.2 has a bug that can lead to __bdos returning 0:https://github.com/llvm/llvm-project/pull/1104972. clang < 19.1.3 has a bug that can lead to __bdos being off by 4:https://github.com/llvm/llvm-project/pull/112636Fixes: c8248faf3ca2 ("Compiler Attributes: counted_by: Adjust name and identifier expansion")Cc: stable@vger.kernel.org # 6.6.x: 16c31dd7fdf6: Compiler Attributes: counted_by: bump min gcc versionCc: stable@vger.kernel.org # 6.6.x: 2993eb7a8d34: Compiler Attributes: counted_by: fixup clang URLCc: stable@vger.kernel.org # 6.6.x: 231dc3f0c936: lkdtm/bugs: Improve warning message for compilers without counted_by supportCc: stable@vger.kernel.org # 6.6.xReported-by: Nathan Chancellor Closes: https://lore.kernel.org/all/20240913164630.GA4091534@thelio-3990X/Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202409260949.a1254989-oliver.sang@intel.comLink: https://lore.kernel.org/all/Zw8iawAF5W2uzGuh@archlinux/T/#m204c09f63c076586a02d194b87dffc7e81b8de7bSuggested-by: Nathan Chancellor Signed-off-by: Jan Hendrik Farr Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Reviewed-by: Miguel Ojeda Reviewed-by: Thorsten Blum Link: https://lore.kernel.org/r/20241029140036.577804-2-kernel@jfarr.ccSigned-off-by: Kees Cook List of files: /linux-6.15/init/Kconfig

bf9850f6 - lib/Makefile: make union-find compilation conditional on CONFIG_CPUSETS

Fri, 11 Oct 2024 14:12:14 +0000

lib/Makefile: make union-find compilation conditional on CONFIG_CPUSETSCurrently, cpuset is the only user of the union-find implementation. Compiling union-find in all configurations unnecessarily increases thecode size when building the kernel without cgroup support. Modify thebuild system to compile union-find only when CONFIG_CPUSETS is enabled.Link: https://lore.kernel.org/lkml/1ccd6411-5002-4574-bb8e-3e64bba6a757@redhat.com/Link: https://lkml.kernel.org/r/20241011141214.87096-1-visitorckw@gmail.comSigned-off-by: Kuan-Wei Chiu Suggested-by: Waiman Long Acked-by: Waiman Long Acked-by: Tejun Heo Reviewed-by: Christoph Hellwig Cc: Ching-Chun (Jim) Huang Cc: Johannes Weiner Cc: Michal Koutný Cc: Xavier Cc: Zefan Li Signed-off-by: Andrew Morton List of files: /linux-6.15/init/Kconfig