June 2025 - Linux-stable-mirror

[PATCH net] can: tcan4x5x: fix power regulator retrieval during probe

by Marc Kleine-Budde

From: Brett Werling <brett.werling(a)garmin.com> Fixes the power regulator retrieval in tcan4x5x_can_probe() by ensuring the regulator pointer is not set to NULL in the successful return from devm_regulator_get_optional(). Fixes: 3814ca3a10be ("can: tcan4x5x: tcan4x5x_can_probe(): turn on the power before parsing the config") Signed-off-by: Brett Werling <brett.werling(a)garmin.com> Link: https://patch.msgid.link/20250612191825.3646364-1-brett.werling@garmin.com Cc: stable(a)vger.kernel.org Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> --- drivers/net/can/m_can/tcan4x5x-core.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/net/can/m_can/tcan4x5x-core.c b/drivers/net/can/m_can/tcan4x5x-core.c index e5c162f8c589..8edaa339d590 100644 --- a/drivers/net/can/m_can/tcan4x5x-core.c +++ b/drivers/net/can/m_can/tcan4x5x-core.c @@ -411,10 +411,11 @@ static int tcan4x5x_can_probe(struct spi_device *spi) priv = cdev_to_priv(mcan_class); priv->power = devm_regulator_get_optional(&spi->dev, "vsup"); - if (PTR_ERR(priv->power) == -EPROBE_DEFER) { - ret = -EPROBE_DEFER; - goto out_m_can_class_free_dev; - } else { + if (IS_ERR(priv->power)) { + if (PTR_ERR(priv->power) == -EPROBE_DEFER) { + ret = -EPROBE_DEFER; + goto out_m_can_class_free_dev; + } priv->power = NULL; } base-commit: 7b4ac12cc929e281cf7edc22203e0533790ebc2b -- 2.47.2

2 months, 1 week

2
1
0 0

[tip: x86/urgent] x86/mm: Disable INVLPGB when PTI is enabled

by tip-bot2 for Dave Hansen

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: 94a17f2dc90bc7eae36c0f478515d4bd1c23e877 Gitweb: https://git.kernel.org/tip/94a17f2dc90bc7eae36c0f478515d4bd1c23e877 Author: Dave Hansen <dave.hansen(a)linux.intel.com> AuthorDate: Tue, 10 Jun 2025 15:24:20 -07:00 Committer: Dave Hansen <dave.hansen(a)linux.intel.com> CommitterDate: Tue, 17 Jun 2025 15:36:57 -07:00 x86/mm: Disable INVLPGB when PTI is enabled PTI uses separate ASIDs (aka. PCIDs) for kernel and user address spaces. When the kernel needs to flush the user address space, it just sets a bit in a bitmap and then flushes the entire PCID on the next switch to userspace. This bitmap is a single 'unsigned long' which is plenty for all 6 dynamic ASIDs. But, unfortunately, the INVLPGB support brings along a bunch more user ASIDs, as many as ~2k more. The bitmap can't address that many. Fortunately, the bitmap is only needed for PTI and all the CPUs with INVLPGB are AMD CPUs that aren't vulnerable to Meltdown and don't need PTI. The only way someone can run into an issue in practice is by booting with pti=on on a newer AMD CPU. Disable INVLPGB if PTI is enabled. Avoid overrunning the small bitmap. Note: this will be fixed up properly by making the bitmap bigger. For now, just avoid the mostly theoretical bug. Fixes: 4afeb0ed1753 ("x86/mm: Enable broadcast TLB invalidation for multi-threaded processes") Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Acked-by: Rik van Riel <riel(a)surriel.com> Cc:stable@vger.kernel.org Link: https://lore.kernel.org/all/20250610222420.E8CBF472%40davehans-spike.ostc.i… --- arch/x86/mm/pti.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c index 1902998..c0c40b6 100644 --- a/arch/x86/mm/pti.c +++ b/arch/x86/mm/pti.c @@ -98,6 +98,11 @@ void __init pti_check_boottime_disable(void) return; setup_force_cpu_cap(X86_FEATURE_PTI); + + if (cpu_feature_enabled(X86_FEATURE_INVLPGB)) { + pr_debug("PTI enabled, disabling INVLPGB\n"); + setup_clear_cpu_cap(X86_FEATURE_INVLPGB); + } } static int __init pti_parse_cmdline(char *arg)

2 months, 1 week

1
0
0 0

[PATCH v2 0/3] soc: qcom: mdt_loader: Validation and cleanup fixes

by Bjorn Andersson

Signed-off-by: Bjorn Andersson <bjorn.andersson(a)oss.qualcomm.com> --- Changes in v2: - Validate e_phentsize and and e_shentsize as well --- Bjorn Andersson (3): soc: qcom: mdt_loader: Ensure we don't read past the ELF header soc: qcom: mdt_loader: Rename mdt_phdr_valid() soc: qcom: mdt_loader: Actually use the e_phoff drivers/soc/qcom/mdt_loader.c | 63 ++++++++++++++++++++++++++++++++++++------- 1 file changed, 53 insertions(+), 10 deletions(-) --- base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494 change-id: 20250604-mdt-loader-validation-and-fixes-5c3267f5b19f Best regards, -- Bjorn Andersson <bjorn.andersson(a)oss.qualcomm.com>

2 months, 1 week

3
3
0 0

[REGRESSION] stable-rc/linux-6.12.y: (build) ‘lvts_debugfs_exit’ defined but not used [-Werror=unused-function]...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-6.12.y: --- ‘lvts_debugfs_exit’ defined but not used [-Werror=unused-function] in drivers/thermal/mediatek/lvts_thermal.o (drivers/thermal/mediatek/lvts_thermal.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:fb8aae5340da55b6254442f0858147bf5f0b39dc - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: 519e0647630e07972733e99a0dc82065a65736ea Log excerpt: ===================================================== drivers/thermal/mediatek/lvts_thermal.c:262:13: error: ‘lvts_debugfs_exit’ defined but not used [-Werror=unused-function] 262 | static void lvts_debugfs_exit(struct lvts_domain *lvts_td) { } | ^~~~~~~~~~~~~~~~~ CC [M] drivers/watchdog/softdog.o cc1: all warnings being treated as errors ===================================================== # Builds where the incident occurred: ## cros://chromeos-6.6/arm64/chromiumos-mediatek.flavour.config+lab-setup+arm64-chromebook+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y on (arm64): - compiler: gcc-12 - dashboard: https://d.kernelci.org/build/maestro:685194ac5c2cf25042b9c1a8 #kernelci issue maestro:fb8aae5340da55b6254442f0858147bf5f0b39dc Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

2 months, 1 week

1
0
0 0

Request for backport of 358de8b4f201 to LTS kernels

by Chuck Lever

Hi Greg & Sasha ! I ran into some trouble in my nightly CI systems that test v6.6.y and v6.1.y. Using "make binrpm-pkg" followed by "rpm -iv ..." results in the test systems being unbootable because the vmlinuz file is never copied to /boot. The test systems are imaged with Fedora 39. I found a related Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=2239008 It appears there is a missing fix in LTS kernels. I bisected the kernel fix to: 358de8b4f201 ("kbuild: rpm-pkg: simplify installkernel %post") which includes a "Cc: stable" tag but does not appear in origin/linux-6.6.y, origin/linux-6.1.y, or origin/5.15.y (I did not look further back than that). Would it be appropriate to apply 358de8b4f201 to LTS kernels? -- Chuck Lever

2 months, 1 week

2
3
0 0

[PATCH v2] sunrpc: handle SVC_GARBAGE during svc auth processing as auth error

by Jeff Layton

tianshuo han reported a remotely-triggerable crash if the client sends a kernel RPC server a specially crafted packet. If decoding the RPC reply fails in such a way that SVC_GARBAGE is returned without setting the rq_accept_statp pointer, then that pointer can be dereferenced and a value stored there. If it's the first time the thread has processed an RPC, then that pointer will be set to NULL and the kernel will crash. In other cases, it could create a memory scribble. The server sunrpc code treats a SVC_GARBAGE return from svc_authenticate or pg_authenticate as if it should send a GARBAGE_ARGS reply. RFC 5531 says that if authentication fails that the RPC should be rejected instead with a status of AUTH_ERR. Handle a SVC_GARBAGE return as an AUTH_ERROR, with a reason of AUTH_BADCRED instead of returning GARBAGE_ARGS in that case. This sidesteps the whole problem of touching the rpc_accept_statp pointer in this situation and avoids the crash. Cc: stable(a)vger.kernel.org # v6.9+ Fixes: 29cd2927fb91 ("SUNRPC: Fix encoding of accepted but unsuccessful RPC replies") Reported-by: tianshuo han <hantianshuo233(a)gmail.com> Signed-off-by: Jeff Layton <jlayton(a)kernel.org> --- This should be more correct. Unfortunately, I don't know of any testcases for low-level RPC error handling. That seems like something that would be nice to do with pynfs or similar though. --- Changes in v2: - Fix endianness of rq_accept_statp assignment - Better describe the way the crash happens and how this fixes it - point Fixes: tag at correct patch - add Cc: stable tag --- net/sunrpc/svc.c | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c index 939b6239df8ab6229ce34836d77d3a6b983fbbb7..99050ab1435148ac5d52b697ab1a771b9e948143 100644 --- a/net/sunrpc/svc.c +++ b/net/sunrpc/svc.c @@ -1375,7 +1375,8 @@ svc_process_common(struct svc_rqst *rqstp) case SVC_OK: break; case SVC_GARBAGE: - goto err_garbage_args; + rqstp->rq_auth_stat = rpc_autherr_badcred; + goto err_bad_auth; case SVC_SYSERR: goto err_system_err; case SVC_DENIED: @@ -1516,14 +1517,6 @@ svc_process_common(struct svc_rqst *rqstp) *rqstp->rq_accept_statp = rpc_proc_unavail; goto sendit; -err_garbage_args: - svc_printk(rqstp, "failed to decode RPC header\n"); - - if (serv->sv_stats) - serv->sv_stats->rpcbadfmt++; - *rqstp->rq_accept_statp = rpc_garbage_args; - goto sendit; - err_system_err: if (serv->sv_stats) serv->sv_stats->rpcbadfmt++; --- base-commit: 9afe652958c3ee88f24df1e4a97f298afce89407 change-id: 20250617-rpc-6-16-cc7a23e9c961 Best regards, -- Jeff Layton <jlayton(a)kernel.org>

2 months, 1 week

2
1
0 0

FAILED: patch "[PATCH] rust: compile libcore with edition 2024 for 1.87+" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x f4daa80d6be7d3c55ca72a8e560afc4e21f886aa # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025061734-shale-reliably-8969@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f4daa80d6be7d3c55ca72a8e560afc4e21f886aa Mon Sep 17 00:00:00 2001 From: Gary Guo <gary(a)garyguo.net> Date: Sat, 17 May 2025 09:55:59 +0100 Subject: [PATCH] rust: compile libcore with edition 2024 for 1.87+ Rust 1.87 (released on 2025-05-15) compiles core library with edition 2024 instead of 2021 [1]. Ensure that the edition matches libcore's expectation to avoid potential breakage. [ J3m3 reported in Zulip [2] that the `rust-analyzer` target was broken after this patch -- indeed, we need to avoid `core-cfgs` since those are passed to the `rust-analyzer` target. So, instead, I tweaked the patch to create a new `core-edition` variable and explicitly mention the `--edition` flag instead of reusing `core-cfg`s. In addition, pass a new argument using this new variable to `generate_rust_analyzer.py` so that we set the right edition there. By the way, for future reference: the `filter-out` change is needed for Rust < 1.87, since otherwise we would skip the `--edition=2021` we just added, ending up with no edition flag, and thus the compiler would default to the 2015 one. [2] https://rust-for-linux.zulipchat.com/#narrow/channel/291565/topic/x/near/52… - Miguel ] Cc: stable(a)vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/138162 [1] Reported-by: est31 <est31(a)protonmail.com> Closes: https://github.com/Rust-for-Linux/linux/issues/1163 Signed-off-by: Gary Guo <gary(a)garyguo.net> Link: https://lore.kernel.org/r/20250517085600.2857460-1-gary@garyguo.net Signed-off-by: Miguel Ojeda <ojeda(a)kernel.org> diff --git a/rust/Makefile b/rust/Makefile index f207ba0ed466..d62b58d0a55c 100644 --- a/rust/Makefile +++ b/rust/Makefile @@ -60,6 +60,8 @@ endif core-cfgs = \ --cfg no_fp_fmt_parse +core-edition := $(if $(call rustc-min-version,108700),2024,2021) + # `rustc` recognizes `--remap-path-prefix` since 1.26.0, but `rustdoc` only # since Rust 1.81.0. Moreover, `rustdoc` ICEs on out-of-tree builds since Rust # 1.82.0 (https://github.com/rust-lang/rust/issues/138520). Thus workaround both @@ -106,8 +108,8 @@ rustdoc-macros: $(src)/macros/lib.rs FORCE # Starting with Rust 1.82.0, skipping `-Wrustdoc::unescaped_backticks` should # not be needed -- see https://github.com/rust-lang/rust/pull/128307. -rustdoc-core: private skip_flags = -Wrustdoc::unescaped_backticks -rustdoc-core: private rustc_target_flags = $(core-cfgs) +rustdoc-core: private skip_flags = --edition=2021 -Wrustdoc::unescaped_backticks +rustdoc-core: private rustc_target_flags = --edition=$(core-edition) $(core-cfgs) rustdoc-core: $(RUST_LIB_SRC)/core/src/lib.rs FORCE +$(call if_changed,rustdoc) @@ -416,7 +418,7 @@ quiet_cmd_rustc_library = $(if $(skip_clippy),RUSTC,$(RUSTC_OR_CLIPPY_QUIET)) L cmd_rustc_library = \ OBJTREE=$(abspath $(objtree)) \ $(if $(skip_clippy),$(RUSTC),$(RUSTC_OR_CLIPPY)) \ - $(filter-out $(skip_flags),$(rust_flags) $(rustc_target_flags)) \ + $(filter-out $(skip_flags),$(rust_flags)) $(rustc_target_flags) \ --emit=dep-info=$(depfile) --emit=obj=$@ \ --emit=metadata=$(dir $@)$(patsubst %.o,lib%.rmeta,$(notdir $@)) \ --crate-type rlib -L$(objtree)/$(obj) \ @@ -427,7 +429,7 @@ quiet_cmd_rustc_library = $(if $(skip_clippy),RUSTC,$(RUSTC_OR_CLIPPY_QUIET)) L rust-analyzer: $(Q)MAKEFLAGS= $(srctree)/scripts/generate_rust_analyzer.py \ - --cfgs='core=$(core-cfgs)' \ + --cfgs='core=$(core-cfgs)' $(core-edition) \ $(realpath $(srctree)) $(realpath $(objtree)) \ $(rustc_sysroot) $(RUST_LIB_SRC) $(if $(KBUILD_EXTMOD),$(srcroot)) \ > rust-project.json @@ -483,9 +485,9 @@ $(obj)/helpers/helpers.o: $(src)/helpers/helpers.c $(recordmcount_source) FORCE $(obj)/exports.o: private skip_gendwarfksyms = 1 $(obj)/core.o: private skip_clippy = 1 -$(obj)/core.o: private skip_flags = -Wunreachable_pub +$(obj)/core.o: private skip_flags = --edition=2021 -Wunreachable_pub $(obj)/core.o: private rustc_objcopy = $(foreach sym,$(redirect-intrinsics),--redefine-sym $(sym)=__rust$(sym)) -$(obj)/core.o: private rustc_target_flags = $(core-cfgs) +$(obj)/core.o: private rustc_target_flags = --edition=$(core-edition) $(core-cfgs) $(obj)/core.o: $(RUST_LIB_SRC)/core/src/lib.rs \ $(wildcard $(objtree)/include/config/RUSTC_VERSION_TEXT) FORCE +$(call if_changed_rule,rustc_library) diff --git a/scripts/generate_rust_analyzer.py b/scripts/generate_rust_analyzer.py index fe663dd0c43b..7c3ea2b55041 100755 --- a/scripts/generate_rust_analyzer.py +++ b/scripts/generate_rust_analyzer.py @@ -19,7 +19,7 @@ def args_crates_cfgs(cfgs): return crates_cfgs -def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs): +def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs, core_edition): # Generate the configuration list. cfg = [] with open(objtree / "include" / "generated" / "rustc_cfg") as fd: @@ -35,7 +35,7 @@ def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs): crates_indexes = {} crates_cfgs = args_crates_cfgs(cfgs) - def append_crate(display_name, root_module, deps, cfg=[], is_workspace_member=True, is_proc_macro=False): + def append_crate(display_name, root_module, deps, cfg=[], is_workspace_member=True, is_proc_macro=False, edition="2021"): crate = { "display_name": display_name, "root_module": str(root_module), @@ -43,7 +43,7 @@ def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs): "is_proc_macro": is_proc_macro, "deps": [{"crate": crates_indexes[dep], "name": dep} for dep in deps], "cfg": cfg, - "edition": "2021", + "edition": edition, "env": { "RUST_MODFILE": "This is only for rust-analyzer" } @@ -61,6 +61,7 @@ def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs): display_name, deps, cfg=[], + edition="2021", ): append_crate( display_name, @@ -68,12 +69,13 @@ def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs): deps, cfg, is_workspace_member=False, + edition=edition, ) # NB: sysroot crates reexport items from one another so setting up our transitive dependencies # here is important for ensuring that rust-analyzer can resolve symbols. The sources of truth # for this dependency graph are `(sysroot_src / crate / "Cargo.toml" for crate in crates)`. - append_sysroot_crate("core", [], cfg=crates_cfgs.get("core", [])) + append_sysroot_crate("core", [], cfg=crates_cfgs.get("core", []), edition=core_edition) append_sysroot_crate("alloc", ["core"]) append_sysroot_crate("std", ["alloc", "core"]) append_sysroot_crate("proc_macro", ["core", "std"]) @@ -177,6 +179,7 @@ def main(): parser = argparse.ArgumentParser() parser.add_argument('--verbose', '-v', action='store_true') parser.add_argument('--cfgs', action='append', default=[]) + parser.add_argument("core_edition") parser.add_argument("srctree", type=pathlib.Path) parser.add_argument("objtree", type=pathlib.Path) parser.add_argument("sysroot", type=pathlib.Path) @@ -193,7 +196,7 @@ def main(): assert args.sysroot in args.sysroot_src.parents rust_project = { - "crates": generate_crates(args.srctree, args.objtree, args.sysroot_src, args.exttree, args.cfgs), + "crates": generate_crates(args.srctree, args.objtree, args.sysroot_src, args.exttree, args.cfgs, args.core_edition), "sysroot": str(args.sysroot), }

2 months, 1 week

3
3
0 0

[REGRESSION] stable-rc/linux-5.4.y: (build) clang: error: assembler command failed with exit code 1 (use -v to...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.4.y: --- clang: error: assembler command failed with exit code 1 (use -v to see invocation) in drivers/firmware/qcom_scm-32.o (scripts/Makefile.build:262) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:e1ce6e2cb61e68ec7bf14991570487d713f77e0a - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: e2f5a2e75b315706dd2d1d50a4313e5785eb189d Log excerpt: ===================================================== CC drivers/firmware/qcom_scm-32.o CC lib/idr.o CC drivers/gpu/host1x/debug.o CC drivers/clk/rockchip/clk-rk3328.o CC drivers/clk/rockchip/clk-rk3368.o CC lib/ioremap.o CC drivers/gpu/drm/drm_probe_helper.o CC drivers/clk/rockchip/clk-rk3399.o /tmp/qcom_scm-32-2d4d72.s: Assembler messages: /tmp/qcom_scm-32-2d4d72.s:56: Error: selected processor does not support `smc #0' in ARM mode /tmp/qcom_scm-32-2d4d72.s:69: Error: selected processor does not support `smc #0' in ARM mode /tmp/qcom_scm-32-2d4d72.s:173: Error: selected processor does not support `smc #0' in ARM mode /tmp/qcom_scm-32-2d4d72.s:394: Error: selected processor does not support `smc #0' in ARM mode /tmp/qcom_scm-32-2d4d72.s:545: Error: selected processor does not support `smc #0' in ARM mode /tmp/qcom_scm-32-2d4d72.s:930: Error: selected processor does not support `smc #0' in ARM mode /tmp/qcom_scm-32-2d4d72.s:1070: Error: selected processor does not support `smc #0' in ARM mode /tmp/qcom_scm-32-2d4d72.s:1117: Error: selected processor does not support `smc #0' in ARM mode clang: error: assembler command failed with exit code 1 (use -v to see invocation) ===================================================== # Builds where the incident occurred: ## defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (arm): - compiler: clang-17 - dashboard: https://d.kernelci.org/build/maestro:685191885c2cf25042b9bb39 ## multi_v7_defconfig on (arm): - compiler: clang-17 - dashboard: https://d.kernelci.org/build/maestro:685191845c2cf25042b9bb35 #kernelci issue maestro:e1ce6e2cb61e68ec7bf14991570487d713f77e0a Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

2 months, 1 week

1
0
0 0

[REGRESSION] stable-rc/linux-6.1.y: (build) stack frame size (2488) exceeds limit (2048) in 'dml31_ModeSupport...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-6.1.y: --- stack frame size (2488) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than] in drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.o (drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:69fb66ef80a96ff4750a9dacf73be24a7cbe888e - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: 2c86adab41e98d103953bf8c447202c9147150ab Log excerpt: ===================================================== drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:3795:6: error: stack frame size (2488) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than] 3795 | void dml31_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib) | ^ CC drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn303/dcn303_fpu.o 1 error generated. CC drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/dcn314_fpu.o ===================================================== # Builds where the incident occurred: ## x86_64_defconfig+kselftest+x86-board on (x86_64): - compiler: clang-17 - dashboard: https://d.kernelci.org/build/maestro:685193725c2cf25042b9bcc9 #kernelci issue maestro:69fb66ef80a96ff4750a9dacf73be24a7cbe888e Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

2 months, 1 week

1
0
0 0

[REGRESSION] stable-rc/linux-5.4.y: (build) in drivers/firmware/qcom_scm-32.o (scripts/Makefile.build:262) [lo...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.4.y: --- in drivers/firmware/qcom_scm-32.o (scripts/Makefile.build:262) [logspec:kbuild,kbuild.compiler] --- - dashboard: https://d.kernelci.org/i/maestro:04c1ce2921a16b59c7329a6026c59ea7942ef691 - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: e2f5a2e75b315706dd2d1d50a4313e5785eb189d Log excerpt: ===================================================== CC drivers/firmware/qcom_scm-32.o CC drivers/firmware/trusted_foundations.o CC drivers/clk/qcom/clk-regmap.o CC drivers/gpio/gpio-pl061.o CC kernel/resource.o CC kernel/sysctl.o /tmp/ccsKkK07.s: Assembler messages: /tmp/ccsKkK07.s:45: Error: selected processor does not support `smc #0' in ARM mode /tmp/ccsKkK07.s:94: Error: selected processor does not support `smc #0' in ARM mode /tmp/ccsKkK07.s:160: Error: selected processor does not support `smc #0' in ARM mode /tmp/ccsKkK07.s:296: Error: selected processor does not support `smc #0' in ARM mode ===================================================== # Builds where the incident occurred: ## multi_v7_defconfig on (arm): - compiler: gcc-12 - dashboard: https://d.kernelci.org/build/maestro:685191a35c2cf25042b9bb4f ## multi_v7_defconfig+kselftest on (arm): - compiler: gcc-12 - dashboard: https://d.kernelci.org/build/maestro:685191ab5c2cf25042b9bb56 #kernelci issue maestro:04c1ce2921a16b59c7329a6026c59ea7942ef691 Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

2 months, 1 week

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2025