summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-08-05RDMA/core: Prevent rereg_mr for dmabuf umemsJacob Moroni
The rereg_mr method has always been explicitly blocked in rdma-core for dmabuf MRs anyway, so add a check to the ib_umem_check_rereg helper so that each driver doesn't need to handle it. Depending on how the driver handled rereg_mr, this also has the benefit of preventing rereg_mr from being used to add the IB_ACCESS_MW_BIND flag to a dmabuf MR. This flag is not allowed during registration, so it seems sensible to prevent it from being added back with rereg_mr. Preventing IB_ACCESS_MW_BIND is important for drivers that support revocable dmabufs and implement "revoke" by issuing a dereg_mr command to the HW because most(?) HW will reject this command if the MR has windows bound to it, and a failure to revoke is supposed to trigger a function reset. Signed-off-by: Jacob Moroni <jmoroni@google.com> Link: https://patch.msgid.link/20260728141501.1425737-1-jmoroni@google.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-08-05sysctl: remove CONFIG_PROC_SYSCTL, it just mirrors CONFIG_SYSCTLOleg Nesterov
CONFIG_SYSCTL used to make sense as a separate hidden bool before commit 61a47c1ad3a4 ("sysctl: Remove the sysctl system call"); it was selected by both CONFIG_SYSCTL_SYSCALL and CONFIG_PROC_SYSCTL. Today CONFIG_PROC_SYSCTL is the only selector, so the two are always equal. Kill the hidden bool, rename the PROC_SYSCTL prompt to SYSCTL, and s/CONFIG_PROC_SYSCTL/CONFIG_SYSCTL/ tree-wide. Signed-off-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Joel Granados <joel.granados@kernel.org>
2026-08-05sysctl: move the "cad_pid" entry from pid_table[] to kern_reboot_table[]Oleg Nesterov
cad_pid is global, and kill_cad_pid() is only used in the root namespace. However, due to pid_table_root_permissions(), a non-root user can unshare pid/user namespaces and modify it from the child namespace. This makes no sense and is simply wrong. Move it to kern_reboot_table[] where it logically belongs; this ensures that only GLOBAL_ROOT_UID can read/modify this sysctl. Note that this patch doesn't preserve "#ifdef CONFIG_PROC_SYSCTL" around the "cad_pid"; CONFIG_PROC_SYSCTL selects CONFIG_SYSCTL, so it is always set when kern_reboot_table[] is compiled. Cc: stable@vger.kernel.org Fixes: e054bcbe7e7a ("sysctl: move cad_pid into kernel/pid.c") Signed-off-by: Oleg Nesterov <oleg@redhat.com> Acked-by: Alexey Gladkov <legion@kernel.org> Reviewed-by: Bradley Morgan <include@grrlz.net> Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Signed-off-by: Joel Granados <joel.granados@kernel.org>
2026-08-05sysctl: repair some kernel-doc commentsRandy Dunlap
Convert a non-kernel-comment to use "/*" instead. Don't use kernel-doc for the nested @type enum values since they aren't part of the struct. Warning: ./include/linux/sysctl.h:62 Cannot find identifier on line: * Warning: ./include/linux/sysctl.h:63 Cannot find identifier on line: * "dir" originates from read_iter (dir = 0) or write_iter (dir = 1) Warning: ./include/linux/sysctl.h:64 This comment starts with '/**', but isn't a kernel-doc comment. * in the file_operations struct at proc/proc_sysctl.c. Its value means Warning: ./include/linux/sysctl.h:274 Excess struct member 'type.SYSCTL_TABLE_TYPE_DEFAULT' description in 'ctl_table_header' Warning: ./include/linux/sysctl.h:274 Excess struct member 'type.SYSCTL_TABLE_TYPE_PERMANENTLY_EMPTY' description in 'ctl_table_header' Note: This still leaves 7 struct members in ctl_table_header that are not described. E.g.: Warning: include/linux/sysctl.h:274 struct member 'unregistering' not described in 'ctl_table_header' Warning: include/linux/sysctl.h:274 struct member 'ctl_table_arg' not described in 'ctl_table_header' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Joel Granados <joel.granados@kernel.org>
2026-08-05sysctl: add Returns: kernel-doc for all functionsRandy Dunlap
Fix kernel-doc warnings in kernel/sysctl.c by adding Returns. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Joel Granados <joel.granados@kernel.org>
2026-08-05sysctl: Update API function documentationJoel Granados
Add colon ":" after argument name where it is missing Add doc for proc_int_conv and proc_dointvec_conv Signed-off-by: Joel Granados <joel.granados@kernel.org>
2026-08-05sysctl: Rename proc_doulongvec_minmax_conv to proc_doulongvec_convJoel Granados
Remove "_minmax" from proc_doulongvec_minmax_conv as it does not enforce min/max limits but serves as a generic converter for unsigned long vectors. Update function declaration in sysctl.h, definition in sysctl.c, and caller in jiffies.c accordingly. Signed-off-by: Joel Granados <joel.granados@kernel.org>
2026-08-05sysctl: Group proc_handler declarations and documentJoel Granados
Make four groups in the sysctl header and document each group with an example of how to use them. 1. proc_handler : All functions that can be passed to the proc_handler pointer in ctl_table 2. proc handler aggregators: Functions to create proc handlers with custom converters 3. bi-directional converters: Functions to create read/write custom converters. Can be passed to proc handler aggregators 4. uni-directional converters: Functions to create read or write custom converters. Can be passed as args to bi-directional converters Use just one naming convention in the declarations: 'write' becomes 'dir' and 'buffer' becomes 'buf'. Signed-off-by: Joel Granados <joel.granados@kernel.org>
2026-08-05sysctl: Replace do_proc_do{int,ulong,uint}vec with do_proc_vecJoel Granados
Make do_proc_vec static and parametrize by proc_vec_type enum which defines the type being processed and selects which converter is "live". Signed-ness and size are calculated based on proc_vec_type and table->data is now walked as raw bytes and advanced by the element size; the converter still performs the actual typed load/store. Pass converter as a union to avoid a cast from void*. The public proc_do{int,uint,ulong}vec_conv() prototypes and all converter signatures in kernel/, fs/ and the header are therefore unchanged. Remove do_proc_doulongvec_minmax. proc_doulongvec_minmax_conv uses a converter callback passed by the caller instead of conversions based on conv{mul,div}. Create uni and bi-direction converters for milliseconds to jiffies in proc_doulongvec_ms_jiffies_minmax; which is the only user of proc_doulongvec_minmax_conv. Replace do_proc_douintvec{,_w,_r} functions with a call to do_proc_vec. Disallow vectors for uint by returning -EINVAL when more than one element is detected. Signed-off-by: Joel Granados <joel.granados@kernel.org>
2026-08-05sysctl: Add negp parameter to douintvec converter functionsJoel Granados
Updates all douintvec converter function signatures to include a bool *negp parameter. This is a preparation commit required to eventually run all converters under the same function. The negp argument will be ignored as it is not relevant for the uint type. Note that do_proc_uint_conv_pipe_maxsz in pipe.c is also modified. Signed-off-by: Joel Granados <joel.granados@kernel.org>
2026-08-05sysctl: Move default converter assignment out of do_proc_dointvecJoel Granados
Move the converter assignment out of do_proc_dointvec into the caller. Both the test for NULL and the assignment are meant to stay within the sysctl.c context. This is in preparation of using a typed macro to for the integer proc vector function. Signed-off-by: Joel Granados <joel.granados@kernel.org>
2026-08-05s390/ap: Fix MAPML computationFinn Callies
When the TAPQ subfunction of PQAP returns a value between 0 and 3 in the ml field, the Principles of Operation states that the Maximum AP Message Length (MAPML) must be 12 KB. The previous code incorrectly calculated smaller sizes for ml values 1-2: - ml=1: 4 KB instead of 12 KB - ml=2: 8 KB instead of 12 KB While no current hardware reports ml=1 or ml=2, this fix ensures correct behavior for specification compliance and future-proofing. The fix ensures all ml values 0-3 correctly use the 12 KB default, with only values 4+ using the formula ml * 4096. Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Finn Callies <fcallies@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-08-05s390/cio: Remove cond_resched() callsHeiko Carstens
Since [1] cond_resched() is a no-op on s390. Remove all calls. [1] commit 7dadeaa6e851 ("sched: Further restrict the preemption modes") Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-08-05s390: Remove cond_resched() callsHeiko Carstens
Since [1] cond_resched() is a no-op on s390. Remove all calls. [1] commit 7dadeaa6e851 ("sched: Further restrict the preemption modes") Reviewed-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-08-05KVM: s390: Remove cond_resched() callsHeiko Carstens
Since [1] cond_resched() is a no-op on s390. Remove all calls. This also entirely removes uv_call_sched() and replaces all call sites with uv_call(), since both functions are identical after the removal of cond_resched(). [1] commit 7dadeaa6e851 ("sched: Further restrict the preemption modes") Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-08-05s390/crypto: Replace cond_resched() with msleep(1)Peter Zijlstra
With [1] cond_resched() is always compiled away and becomes a no-op. The comments for all cond_resched() calls in crypto code however indicate that the current process should be scheduled away to avoid instant re-invocation of a callback. This is not what cond_resched() would do or did. Instead of just removing the cond_resched() calls, replace them with msleep() calls, as suggested by Holger Dengler. This forces the current task to be scheduled away (sleeps) like originally intended. Holger provided information why this intended [2]: " Let me give a bit of background here: The protected key can only get invalid, if the Linux instance (z/VM or KVM guest) is moved to another hypervisor on a different machine (aka life guest relocation). In such a case, the crypto accelerator card and the host has to exchange the "real key", which is wrapped by the host and handed back to the guest as the re-newed protected key. Unfortunately there is no asynchronous trigger on completion, you have to re-try (and maybe get another "in progress" return). And as if that weren't bad enough, if this key exchange between card and host is the first one, card and host has to instantiate a secure communication channel (including a key exchange for the transport layer). " [1] commit 7dadeaa6e851 ("sched: Further restrict the preemption modes") [2] https://lore.kernel.org/all/39570813-27b0-40f9-89c5-8e2dce05e2f0@linux.ibm.com/ [3] https://lore.kernel.org/all/20260731084027.GE776954@noisy.programming.kicks-ass.net/ [hca@linux.ibm.com: took Peter's patch [3] and provided commit message] Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-08-05s390/Kconfig: Select ARCH_SUPPORTS_CFIHeiko Carstens
With all prerequisites in place select ARCH_SUPPORTS_CFI. Note that this support is supposed to work with the generic kCFI support which is provided by clang. This comes with a couple of limitations: The generic kCFI implementation does not generate a .kcfi_traps section, nor is a special instruction used in case a checksum mismatch is detected. This means in case of checksum mismatch the kernel just crashes. It should be quite easy to tell by the surrounding code that a crash happened because of a checksum mismatch. If clang and/or gcc provide a .kcfi_traps section it will be possible to print proper CFI messages instead of just crashing the kernel (enable ARCH_USES_CFI_TRAPS). In addition this also means that CFI_PERMISSIVE does not work. Even if the option is selected the kernel will crash in case of checksum mismatch. However it seems to be acceptable to enable kCFI support to the kernel now even if it is not perfect. Later clang and gcc extensions are required to improve this. As of now a crash caused by a CFI failure looks like this: illegal operation: 0001 ilc:1 [#1]SMP Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 92 Comm: test_progs Tainted: G OE 7.2.0-rc4-00021-gc35ed7a1ca22-dirty #3 PREEMPTLAZY Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: IBM 3931 A01 703 (KVM/Linux) Krnl PSW : 0704e00180000000 00000166d4853a0a (bpf_task_work_callback+0x176/0x290) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0400000069b02e96 000001665471856c 0000000084dc1000 000000008084da58 000000008084da60 000000005ff492bf 0000000000000000 00000000809de300 fffffffffff7ffff 00000000000a0337 00000000809e4d00 000000008437b100 00000000801bc288 00000000801bc280 00000166d48538fc 000000e6d502ba90 Krnl Code: 00000166d48539fa: e320c0400004 lg %r2,64(%r12) 00000166d4853a00: e340c0480004 lg %r4,72(%r12) *00000166d4853a06: a7640001 brc 6,00000166d4853a08 >00000166d4853a0a: 0de1 basr %r14,%r1 00000166d4853a0c: e300b6580095 llh %r0,1624(%r11) 00000166d4853a12: ec040009027e cij %r0,2,4,00000166d4853a24 00000166d4853a18: a70affff ahi %r0,-1 00000166d4853a1c: 4000b658 sth %r0,1624(%r11) Call Trace: [<00000166d4853a0a>] bpf_task_work_callback+0x176/0x290 ... The disassembly contains the brc instruction (branch into the instruction itself with two byte offset to execute an illegal instruction, and the following basr instruction used for an indirect branch. Reviewed-by: Jens Remus <jremus@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-08-05s390/bpf: Add kCFI supportHeiko Carstens
This is the s390 variant of commit 710618c760c0 ("arm64/cfi,bpf: Support kCFI + BPF on arm64"). Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-08-05s390/diag: Generate CFI type information for assembly functionsHeiko Carstens
Use SYM_TYPED_FUNC_START to generate __kcfi_typeid_ symbols for assembler functions which are called indirectly. All assembler functions contained in text_amode31.S are called indirectly and require such annotations. Reviewed-by: Jens Remus <jremus@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-08-05s390: Add ftrace_stub_graphHeiko Carstens
This is the s390 variant of commit f3a0c23f2539 ("riscv: Add ftrace_stub_graph"): "Commit 883bbbffa5a4 ("ftrace,kcfi: Separate ftrace_stub() and ftrace_stub_graph()") added a separate ftrace_stub_graph function for CFI_CLANG. Add the stub to fix FUNCTION_GRAPH_TRACER compatibility with CFI." Reviewed-by: Jens Remus <jremus@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-08-05s390/tools/relocs: Ignore __kcfi_typeid_ relocationsHeiko Carstens
This is the s390 variant of commit ca7e10bff196 ("x86/tools/relocs: Ignore __kcfi_typeid_ relocations"): "The compiler generates __kcfi_typeid_ symbols for annotating assembly functions with type information. These are constants that can be referenced in assembly code and are resolved by the linker. Ignore them in relocs." Reviewed-by: Jens Remus <jremus@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-08-05s390/tools: Pass symbol name to do_relocs()Heiko Carstens
Pass the symbol symbol name which corresponds to a relocation to do_relocs(). This is preparation for kCFI support. Given that the s390 specific relocs tool is a stripped down version of the x86 version, add more code from the x86 version to the s390 version, while keeping coding style, etc. in order to add the required functionality. Reviewed-by: Jens Remus <jremus@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-08-05s390/zcrypt: Pad trailing CCA or EP11 message with zerosHarald Freudenberger
The both functions xcrb_msg_to_type6cprb_msgx() and xcrb_msg_to_type6_ep11cprb_msgx() copy the user space message into a kernel buffer based on the message length. But on further processing the message is supposed to be 4 byte length adjusted. Thus up to 3 bytes of uninitialized kernel memory are forwarded to further processing steps and may unwanted expose kernel memory to the crypto card firmware. This patch contains code to pad the gap between user space copied message and message buffer length sent down to further processing of the CCA or EP11 message to zeros. Fixes: e2c6d91eb8b1 ("s390/zcrypt: Rework domain processing within zcrypt device driver") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 7.1+ Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-08-05s390/zcrypt: Improve EP11 CPRB domain handling with ASN.1 parsingHarald Freudenberger
The zcrypt_msgtype6_send_ep11_cprb() function uses fragile struct overlays to access and modify the domain field in the EP11 CPRB payload, creating maintainability and security concerns: 1. Struct overlay approach (pld_hdr) assumes fixed payload structure and doesn't validate the actual ASN.1 encoding. 2. Complex length format detection logic is error-prone and doesn't properly validate bounds at each parsing step. 3. Direct struct member access bypasses proper ASN.1 validation. Fix by replacing struct overlays with explicit ASN.1 parsing that validates each field (payload tag/length, function tag/length/value, optional domain tag/length/value) with proper bounds checking at every step. Add asn1_int_encode() helper function to safely write integer values with correct endianness conversion. This makes the code consistent with the validation pattern introduced with the rework of the xcrb_msg_to_type6_ep11cprb_msgx() function. Fixes: e2c6d91eb8b1 ("s390/zcrypt: Rework domain processing within zcrypt device driver") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Cc: stable@vger.kernel.org # 7.1+ Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-08-05s390/zcrypt: Improve EP11 CPRB length and overflow checksHarald Freudenberger
The xcrb_msg_to_type6_ep11cprb_msgx() function lacks proper input validation, creating security vulnerabilities: 1. Missing minimum size validation: The ep11_cprb structure and subsequent payload fields (pld_tag, pld_lenfmt) are copied from userspace without verifying sufficient buffer length. 2. Arithmetic overflow in length calculations: CEIL4 alignment could overflow, bypassing size checks and enabling buffer overflows. 3. The payload is asn1 encoded but the function just uses a simple c struct overlay to access some fields of the payload. Fix by using size_t for length calculations, adding U32_MAX boundary checks after alignment, and validating minimum request size and minimum reply size before copying from userspace. Do a very simple asn1 parsing of the payload up to the function value field. Fixes: e2c6d91eb8b1 ("s390/zcrypt: Rework domain processing within zcrypt device driver") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Cc: stable@vger.kernel.org # 7.1+ Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-08-05s390/zcrypt: Improve CCA CPRB length and overflow checksHarald Freudenberger
The xcrb_msg_to_type6cprb_msgx() function lacks proper input validation, creating security vulnerabilities: 1. Integer overflow after CEIL4 alignment: Signed int variables could overflow during 4-byte boundary alignment, causing undersized buffer allocations or incorrect bounds checking. 2. Missing minimum size validation: The CPRBX structure is copied from userspace without verifying sufficient buffer length. Undersized buffers cause uninitialized memory access when reading structure fields like cprbx.cprb_len and cprbx.domain. 3. Arithmetic overflow in sum calculations: Adding control block and data block sizes could overflow, bypassing size checks and enabling buffer overflows. Fix by using size_t for length calculations, adding U32_MAX boundary checks after alignment, validating minimum control block size before copying from userspace, and detecting sum calculation overflows. Fixes: e2c6d91eb8b1 ("s390/zcrypt: Rework domain processing within zcrypt device driver") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 7.1+ Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-08-05s390/zcrypt: Fix CPRB memory allocation in zcrypt misc codeHarald Freudenberger
Both CPRB alloc functions in zcrypt_ccamisc.c and zcrypt_ep11misc.c did not round up the memory allocation to a multiple of 4 bytes as it is needed by the zcrypt layer to process the CPRBs. Now the alloc_and_prep_cprbmem() and alloc_cprbmem() functions guarantee that the base CPRB struct and a possible parameter block are aligned to a 4-byte boundary and the backing memory allocation is rounded up to the next multiple of 4 byte. Also the free_cprbmem() is updated and scrubs the rounded up amount of memory. Fixes: 9bdb5f7e8369 ("s390/zcrypt: Introduce cprb mempool for cca misc functions") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-08-05ACPI: CPPC: Evaluate performance-control PCC use onceChristian Loehle
cppc_set_perf() evaluates the same immutable address-space predicates before and after each phase of a performance-control update. This repeats the three-control PCC test three times for every target request. Evaluate the predicate once after resolving the control descriptors and reuse the result throughout the transaction. Signed-off-by: Christian Loehle <christian.loehle@arm.com> Link: https://patch.msgid.link/20260803210527.1285229-4-christian.loehle@arm.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-08-05ACPI: CPPC: Avoid locking standalone full-width registersChristian Loehle
cpc_write() serializes every SystemMemory write with the per-CPU rmw_lock. The lock is required for read-modify-write fields and for registers whose access units overlap, but not for a full-width register in a standalone access unit. The _CPC layout is immutable after it has been parsed. Classify each SystemMemory register at probe time and retain locking for partial fields, invalid access widths, and overlapping access units. Allow standalone full-width registers to bypass the descriptor lookup and spinlock. Store the classification in existing structure padding so that struct cpc_register_resource does not grow. Signed-off-by: Christian Loehle <christian.loehle@arm.com> Link: https://patch.msgid.link/20260803210527.1285229-3-christian.loehle@arm.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-08-05ACPI: CPPC: Avoid unnecessary reads for full-width writesChristian Loehle
SystemMemory GAS entries may describe a field within a wider access unit, so cpc_write() reads the access unit before updating the field to preserve the surrounding bits. It also does this when the field covers the complete access unit. When the bit offset is zero and the register bit width equals the resolved access width, the previous value cannot affect the result. Skip the MMIO read and mask operation in that case. Retain rmw_lock because another entry in the same _CPC package may share the access unit. Signed-off-by: Christian Loehle <christian.loehle@arm.com> Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Link: https://patch.msgid.link/20260803210527.1285229-2-christian.loehle@arm.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-08-05dt-bindings: display: bridge: Document Renesas RZ/G3L LVDS encoderBiju Das
Document the LVDS encoder IP found on the RZ/G3L SoC. It supports single-link mode. LVDS and the DSI interface share a peripheral clock and the MIPI_DSI_PRESET_N reset signal. However, the LVDS module cannot be used at the same time as MIPI-DSI. Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260729125516.230757-10-biju.das.jz@bp.renesas.com Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
2026-08-05dt-bindings: display: renesas,rzg2l-du: Document RZ/G3L SoCBiju Das
The DU block on the RZ/G3L SoC is identical to the one found on the RZ/G2L SoC. However, it supports the DSI, DPI, and LVDS interfaces, while the RZ/G2L supports only the DSI and DPI interfaces. Due to this difference, a SoC-specific compatible string, 'renesas,r9a08g046-du', is added for the RZ/G3L SoC. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260729125516.230757-8-biju.das.jz@bp.renesas.com Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
2026-08-05dt-bindings: display: bridge: renesas,dsi: Document RZ/G3LBiju Das
The RZ/G3L DSI IP is similar to the RZ/G2L but has different global PHY timings and also the PLLCLK is ungateble clock. Add the compatible string "renesas,r9a08g046-mipi-dsi" to handle these difference for the Renesas RZ/G3L SoC. The power to DSI region is controlled by SYSC block. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260729125516.230757-2-biju.das.jz@bp.renesas.com Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
2026-08-05kbuild: link-vmlinux.sh: improve detection of third pass requirementAndré Draszik
It can happen that symbol sizes within .tmp_vmlinux1.kallsyms.o and .tmp_vmlinux2.kallsyms.o differ, without affecting file size on disk because of section alignment and/or padding emitted by the assembler. link-vmlinux.sh doesn't detect this case currently and keeps using .tmp_vmlinux2.kallsyms.o to link the final vmlinux. Due to the different symbol sizes, other symbols are shifted within the final image compared to .tmp_vmlinux2, and the final comparison of System.map against "${kallsyms_sysmap}" fails with the message: Inconsistent kallsyms data Try "make KALLSYMS_EXTRA_PASS=1" as a workaround This can happen in particular if the linker emits additional symbols that might have different names between our (re-)linking steps, e.g. because those names depend on the virtual address of the symbol. Linker stubs for ARM errata work-arounds are one such case. These changed symbol names can cause the output of the token compression of kallsyms.c to change due to the changed symbol substring count, which in turn can change the size of the kallsyms_names symbol itself, causing the potential shift of subsequent symbol addresses in .tmp_vmlinux2.kallsyms.o and therefore the final image. Update link-vmlinux.sh to not rely on file size of .tmp_vmlinux?.kallsyms.o alone but to also consider symbol offsets within to resolve this, and do a third pass if required. Signed-off-by: André Draszik <andre.draszik@linaro.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nicolas Schier <nsc@kernel.org> Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-08-05kallsyms: add symbol size for kallsyms symbols that can change sizeAndré Draszik
Add symbol size for kallsyms symbols that can change size so that sizes can be determined easily without having to manually calculate them when inspecting the object files (.tmp_vmlinux?.kallsyms.o or .tmp_vmlinux?). Without, the assembler records the symbol size as 0. This is primarily useful as a debugging aid in case of linker errors as part of link-vmlinux.sh, and because symbol size doesn't have to align with the offset to the next symbol due to padding/alignment. Signed-off-by: André Draszik <andre.draszik@linaro.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nicolas Schier <nsc@kernel.org> Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-08-05kbuild: fix modules.builtin(.modinfo) targets in the top-level MakefileYuntao Wang
Commit 7a342e6c7735 ("kbuild: move modules.builtin(.modinfo) rules to Makefile.vmlinux_o") moved the modules.builtin(.modinfo) rules from link-vmlinux.sh to Makefile.vmlinux_o, and added the corresponding targets to the top-level Makefile. Commit 39cfd5b12160 ("kbuild: extract modules.builtin.modinfo from vmlinux.unstripped") later moved these rules from Makefile.vmlinux_o to Makefile.vmlinux, but left the corresponding targets in the top-level Makefile unchanged. These modules.builtin(.modinfo) targets in the top-level Makefile should be moved alongside the vmlinux target, since they are now generated by Makefile.vmlinux. However, simply removing these trivial targets might be a better choice, as it makes the Makefile cleaner and avoids the need to keep them in sync across multiple files, reducing the chance of future mistakes. Fixes: 39cfd5b12160 ("kbuild: extract modules.builtin.modinfo from vmlinux.unstripped") Signed-off-by: Yuntao Wang <yuntao.wang@linux.dev> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20260729071737.818007-1-yuntao.wang@linux.dev Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-08-05ACPI: CPPC: Stop reading desired_perf in cppc_get_perf()Christian Loehle
cppc_get_perf() has one in-tree caller, cppc_cpufreq_get_cpu_data(). It uses the function to preserve existing controls before writing them, but overwrites desired_perf with highest_perf before the first cppc_set_perf(). Consequently, the current Desired Performance value is not consumed. Remove the Desired Performance read from this aggregate getter and document that the field is returned as zero. Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Signed-off-by: Christian Loehle <christian.loehle@arm.com> Link: https://patch.msgid.link/20260803203531.1268651-4-christian.loehle@arm.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-08-05ACPI: CPPC: Skip desired_perf read in cppc_get_perf()Christian Loehle
ACPI 6.5 defines _CPC revision 3 and lists Read/Write as the Optional Attribute of Desired Performance. ACPI 6.6 advances _CPC to revision 4 and lists only Write. cppc_get_perf() nevertheless reads the register when initializing performance controls, even though cppc-cpufreq overwrites the value before using it. Use the _CPC revision check from cppc_get_desired_perf() and leave desired_perf zero instead of reading it for _CPC revision 4 or later. Also exclude the register from PCC read-command detection so it cannot trigger an otherwise unnecessary read command. Fixes: 658fa7b1c47a ("ACPI: CPPC: Add cppc_get_perf() API to read performance controls") Cc: stable@vger.kernel.org Suggested-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Signed-off-by: Christian Loehle <christian.loehle@arm.com> Link: https://patch.msgid.link/20260803203531.1268651-3-christian.loehle@arm.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-08-05ACPI: CPPC: Reject desired_perf reads on _CPC revision 4+Christian Loehle
When CPPC feedback counters cannot provide a usable sample, cppc-cpufreq calls cppc_get_desired_perf() because some platforms repurpose Desired Performance to report actual delivered performance. ACPI 6.5 defines _CPC revision 3 and lists Read/Write as the Optional Attribute of Desired Performance. ACPI 6.6 advances _CPC to revision 4 and lists only Write, so invoking that workaround for revision 4 or later would require a register read that the interface no longer specifies. Make cppc_get_desired_perf() return -EOPNOTSUPP for _CPC revision 4 or later. Use the revision retained in the per-CPU CPC descriptor rather than the platform-wide FADT revision. The _CPC revision may still not accurately describe the implemented register semantics. If a nominally revision 3 platform implements a non-readable Desired Performance register, a read may return zero and make cppc_cpufreq_get_rate() report 0 kHz. Treat a zero read as unusable and fall back to the cached OSPM request, just as for a failed read. Fixes: c47195631960 ("cppc_cpufreq: Use desired perf if feedback ctrs are 0 or unchanged") Cc: stable@vger.kernel.org Suggested-by: Sumit Gupta <sumitg@nvidia.com> Signed-off-by: Christian Loehle <christian.loehle@arm.com> Link: https://patch.msgid.link/20260803203531.1268651-2-christian.loehle@arm.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-08-05kbuild: set the initial value of subdir-rustflags-yYuntao Wang
Initialize subdir-rustflags-y to an empty value to prevent it from being inadvertently affected by an environment variable of the same name. Signed-off-by: Yuntao Wang <yuntao.wang@linux.dev> Link: https://patch.msgid.link/20260718040146.294700-1-yuntao.wang@linux.dev Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-08-05scripts/config: Use in-place editing (-i) in sed portablyRong Zhang
The use of in-place editing was removed by commit 83e8b90e1d2c ("scripts/config: use sed's POSIX interface"). Before that, the script used bare `-i' to skip creating a backup file. In fact, major sed implementations have supported `-i' for over a decade. It's really doubtful if anyone would still build Linux on a Unix system without it. The issue is more about how we use it: FreeBSD and macOS disallow bare `-i'. To skip creating a backup, an empty string ("zero-length extension") must be passed as a separate argument following `-i'. GNU and other BSDs accept bare `-i' to skip creating a backup, but disallow passing a zero-length extension. That being said, when thinking about it optimistically, using `-i' is portable as long as a backup is created. Use in-place editing (-i) in a portable manner by creating a backup file with a .swp extension (the same name as the current temporary file). The backup file will be deleted on exit. A rough benchmark with ~1000 editions showed a 14.4% speedup (5.27s => 4.51s, GNU sed). The FreeBSD sed showed a similar speedup. Reviewed-by: Nicolas Schier <nsc@kernel.org> Signed-off-by: Rong Zhang <i@rong.moe> Link: https://patch.msgid.link/20260722-config-sed-v2-2-9f2c4b164666@rong.moe Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-08-05scripts/config: Use POSIX standard ERE (-E) in sedRong Zhang
The use of Extended Regular Expressions was removed by commit 83e8b90e1d2c ("scripts/config: use sed's POSIX interface"). Before that, the script used `-r' to enable ERE, which is indeed non-portable. However, POSIX.1-2024 [1][2] has accepted `-E' as a standard option to use ERE for matching, and major sed implementations (GNU, FreeBSD, OpenBSD, NetBSD, macOS) have supported `-E' for over two decades, so it makes no sense to use Basic Regular Expressions any more. Switch to ERE to get rid of chained calls to sed. A rough benchmark with ~1000 editions showed a 40.0% speedup (8.78s => 5.27s, GNU sed). The FreeBSD sed showed a similar speedup. Link: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/sed.html [1] Link: https://austingroupbugs.net/view.php?id=528 [2] Reviewed-by: Nicolas Schier <nsc@kernel.org> Signed-off-by: Rong Zhang <i@rong.moe> Link: https://patch.msgid.link/20260722-config-sed-v2-1-9f2c4b164666@rong.moe Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-08-05modpost: prevent leak when early return no suffix .o in read_symbols()Robertus Diawan Chris
The allocation for elf info symsearch and hdr from parse_elf() haven't been released when return because of modname didn't have suffix ".o". And it seems like the suffix ".o" check did not depends on parse_elf() to succeed first. So, move the suffix ".o" check before checking parse_elf() result to prevent resource leak when the modname didn't have suffix ".o" and return early. This is reported by Coverity Scan as "Resource leak". Fixes: 8c9ce89c5b63 ("modpost: simplify mod->name allocation") Signed-off-by: Robertus Diawan Chris <robertusdchris@gmail.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20260624044742.144852-1-robertusdchris@gmail.com Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-08-05usr: Correct a spelling by changing a letterBhaskar Chowdhury
s/dit/did/ Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260731221556.3638651-2-unixbhaskar@gmail.com Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-08-05fixdep: make gendered language gender-neutralElsie Heck
Fix awkward phrasing and change instances of gendered language to gender-neutral in code comments to improve consistency and clarity. Signed-off-by: Elsie Heck <its@elc.moe> Link: https://patch.msgid.link/20260717195939.25130-1-its@elc.moe Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-08-05kconfig: fix minor typos in commentsJulian Braha
Some typos I noticed: 1. expressoin -> expression 2. A property represent -> A property represents Signed-off-by: Julian Braha <julianbraha@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260719210536.9577-1-julianbraha@gmail.com Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-08-05scripts: fix spelling mistakesMartin Weiss
Fix two minor typographical issues in two scripts under scripts/. Signed-off-by: Martin Weiss <Martin.weiss2410@gmail.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260629082812.551273-1-Martin.weiss2410@gmail.com [nsc: Added minimal commit description] Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-08-05kconfig: abort rather than loop for ever on EOFSimon Glass
When a non-interactive 'make oldconfig' or 'syncconfig' meets a new int or hex symbol whose default cannot be applied, conf_string() reads a value from stdin. At end of file fgets() returns NULL, no value is set and the loop asks again. The result is an endless loop which fills the output until it exhausts memory, rather than a clean failure. Detect this in conf_string(): if the value cannot be set and stdin is at end of file, stop with an error that names the symbol. Note that a symbol with no default doesn't trigger this, since sym_calc_value() falls back to 0, which is accepted at end of file. The loop is triggered by a broken Kconfig file, with a default whose text fails sym_string_valid(). Such mistakes do creep in from time to time and are hard to debug, since the build fills the log with repeated prompts instead of pointing at the offending symbol. Some bad defaults draw a parse-time warning, but menu_validate_number() accepts a reference to any int or hex symbol, so a cross-type reference loops with no warning at all. For example, "0xff" is not a valid int value: config HEXSYM hex default 0xff config VAL int "Value" default HEXSYM Interactive use is unaffected, since feof() only becomes true once a read actually hits end of file: an invalid answer at a terminal still re-prompts, while Ctrl-D at such a prompt exits with the error instead of looping. bool and tristate symbols and choices already accept the default on an empty line, so they still take their defaults in a non-interactive build. Tested with int and hex symbols carrying such defaults: with empty stdin, the code without this change produces around 190MB of repeated prompts within two seconds, while with the change it exits 1 naming the symbol. Piped and interactive (pty) sessions still re-prompt on an invalid answer and then accept a valid one. A new string symbol with no default still takes the empty string at end of file, since any text is valid for a string. Signed-off-by: Simon Glass <sjg@chromium.org> Link: https://patch.msgid.link/20260714133545.3294648-1-sjg@chromium.org Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-08-05ASoC: cs35l41/cs35l45/cs4265: sort the reg_defaults tablesMark Brown
Peter Ujfalusi <peter.ujfalusi@linux.intel.com> says: reg_defaults must be sorted by ascending register address as regcache_lookup_reg() locates the entries in it with bsearch(), see commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). These three tables have entries which are out of order, so the binary search does not find part of them. For those registers regcache_reg_needs_sync() cannot compare the cached value against the default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. The patches only reorder the existing entries, the text of every entry is kept verbatim and no default value is changed. Each table was verified by evaluating the register addresses and replaying lib/bsearch.c on them. Entries not reachable by the binary search, per table: cs35l41_reg 2 (of 47) cs35l45_defaults 36 (of 73) cs4265_reg_defaults 3 (of 16) For cs35l45 this is nearly half of the table: the DSP1_RX*_RATE and DSP1_TX*_RATE registers sit in the middle of it while their addresses are far above everything else, which cuts the search off from the whole 0x4c40 - 0xf010 range. Found by an audit of all reg_defaults tables under sound/, the SoundWire codec drivers are fixed by a separate series. Link: https://patch.msgid.link/20260805082413.26174-1-peter.ujfalusi@linux.intel.com
2026-08-05ASoC: cs4265: sort the register default tablePeter Ujfalusi
reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). cs4265_reg_defaults[] lists CS4265_INT_MASK (0x0e), CS4265_STATUS_MODE_MSB (0x0f) and CS4265_STATUS_MODE_LSB (0x10) after CS4265_SPDIF_CTL1 (0x11) and CS4265_SPDIF_CTL2 (0x12), so the binary search does not find those three entries. regcache_reg_needs_sync() then cannot compare them against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: fb6f806967f6 ("ASoC: Add support for the CS4265 CODEC") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260805082413.26174-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>