- Linux-stable-mirror - lists.linaro.org

[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 weeks, 3 days

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 weeks, 3 days

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 weeks, 3 days

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 weeks, 3 days

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 weeks, 3 days

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 weeks, 3 days

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 weeks, 3 days

1
0
0 0

[REGRESSION] stable-rc/linux-5.15.y: (build) integer literal is too large to be represented in type 'long', int...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.15.y: --- integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] in drivers/gpu/drm/meson/meson_vclk.o (drivers/gpu/drm/meson/meson_vclk.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:ae3b0334acd91200d6ced325a381bafac2d46493 - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: d99cd6f3a570e2f93e8f966b8ca772ef3da54fe2 Log excerpt: ===================================================== drivers/gpu/drm/meson/meson_vclk.c:399:15: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 399 | .pll_freq = 2970000000, | ^ drivers/gpu/drm/meson/meson_vclk.c:411:15: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 411 | .pll_freq = 2970000000, | ^ drivers/gpu/drm/meson/meson_vclk.c:423:15: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 423 | .pll_freq = 2970000000, | ^ drivers/gpu/drm/meson/meson_vclk.c:436:15: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 436 | .phy_freq = 2970000000, | ^ drivers/gpu/drm/meson/meson_vclk.c:460:15: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 460 | .phy_freq = 2970000000, | ^ CC [M] net/dccp/feat.o drivers/gpu/drm/meson/meson_vclk.c:850:8: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 850 | case 2970000000: | ^ drivers/gpu/drm/meson/meson_vclk.c:868:8: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 868 | case 2970000000: | ^ drivers/gpu/drm/meson/meson_vclk.c:885:8: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 885 | case 2970000000: | ^ 8 errors generated. ===================================================== # Builds where the incident occurred: ## defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (arm): - compiler: clang-17 - dashboard: https://d.kernelci.org/build/maestro:685192b15c2cf25042b9bc2e #kernelci issue maestro:ae3b0334acd91200d6ced325a381bafac2d46493 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 weeks, 3 days

1
0
0 0

[PATCH v2] serial: core: restore of_node information in sysfs

by Aidan Stewart

Since in v6.8-rc1, the of_node symlink under tty devices is missing. This breaks any udev rules relying on this information. Link the of_node information in the serial controller device with the parent defined in the device tree. This will also apply to the serial device which takes the serial controller as a parent device. Fixes: b286f4e87e32 ("serial: core: Move tty and serdev to be children of serial core port device") Cc: stable(a)vger.kernel.org Signed-off-by: Aidan Stewart <astewart(a)tektelic.com> --- v1 -> v2: - v1: https://lore.kernel.org/linux-serial/20250616162154.9057-1-astewart@tekteli… - Remove IS_ENABLED(CONFIG_OF) check. --- drivers/tty/serial/serial_base_bus.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/tty/serial/serial_base_bus.c b/drivers/tty/serial/serial_base_bus.c index 5d1677f1b651..cb3b127b06b6 100644 --- a/drivers/tty/serial/serial_base_bus.c +++ b/drivers/tty/serial/serial_base_bus.c @@ -72,6 +72,7 @@ static int serial_base_device_init(struct uart_port *port, dev->parent = parent_dev; dev->bus = &serial_base_bus_type; dev->release = release; + device_set_of_node_from_dev(dev, parent_dev); if (!serial_base_initialized) { dev_dbg(port->dev, "uart_add_one_port() called before arch_initcall()?\n"); -- 2.49.0

2 weeks, 3 days

1
0
0 0

[PATCH 6.12.y 0/2] Kunit to check the longest symbol length

by Sergio González Collado

The longest length of a symbol (KSYM_NAME_LEN) was increased to 512 in the reference [1]. Because in Rust symbols can become quite long due to namespacing introduced by modules, types, traits, generics, etc. This patch series presents two commits that implement a test to verify that a symbol with KSYM_NAME_LEN of 512 can be read. The first commit: To check that symbol length was valid, the commit implements a kunit test that verifies that a symbol of 512 length can be read. The second commit: There was a warning when building with clang because there was a definition of unlikely from compiler.h in tools/include/linux, which conflicted with the one in the instruction decoder selftest. [1] https://lore.kernel.org/lkml/20220802015052.10452-6-ojeda@kernel.org/ --- Nathan Chancellor (1): x86/tools: Drop duplicate unlikely() definition in insn_decoder_test.c Sergio González Collado (1): Kunit to check the longest symbol length arch/x86/tools/insn_decoder_test.c | 5 +- lib/Kconfig.debug | 9 ++++ lib/Makefile | 2 + lib/longest_symbol_kunit.c | 82 ++++++++++++++++++++++++++++++ 4 files changed, 95 insertions(+), 3 deletions(-) create mode 100644 lib/longest_symbol_kunit.c base-commit: ba9210b8c96355a16b78e1b890dce78f284d6f31 -- 2.39.2

2 weeks, 3 days

4
11
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror