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

by Ivan Kokshaysky

This series fixes oopses on Alpha/SMP observed since kernel v6.9. [1] Thanks to Magnus Lindholm for identifying that remarkably longstanding bug. The problem is that GCC expects 16-byte alignment of the incoming stack since early 2004, as Maciej found out [2]: Having actually dug speculatively I can see that the psABI was changed in GCC 3.5 with commit e5e10fb4a350 ("re PR target/14539 (128-bit long double improperly aligned)") back in Mar 2004, when the stack pointer alignment was increased from 8 bytes to 16 bytes, and arch/alpha/kernel/entry.S has various suspicious stack pointer adjustments, starting with SP_OFF which is not a whole multiple of 16. Also, as Magnus noted, "ALPHA Calling Standard" [3] required the same: D.3.1 Stack Alignment This standard requires that stacks be octaword aligned at the time a new procedure is invoked. However: - the "normal" kernel stack is always misaligned by 8 bytes, thanks to the odd number of 64-bit words in 'struct pt_regs', which is the very first thing pushed onto the kernel thread stack; - syscall, fault, interrupt etc. handlers may, or may not, receive aligned stack depending on numerous factors. Somehow we got away with it until recently, when we ended up with a stack corruption in kernel/smp.c:smp_call_function_single() due to its use of 32-byte aligned local data and the compiler doing clever things allocating it on the stack. Patches 1-2 are preparatory; 3 - the main fix; 4 - fixes remaining special cases. Ivan. [1] https://lore.kernel.org/rcu/CA+=Fv5R9NG+1SHU9QV9hjmavycHKpnNyerQ=Ei90G98ukR… [2] https://lore.kernel.org/rcu/alpine.DEB.2.21.2501130248010.18889@angie.orcam… [3] https://bitsavers.org/pdf/dec/alpha/Alpha_Calling_Standard_Rev_2.0_19900427… --- Changes in v2: - patch #1: provide empty 'struct pt_regs' to fix compile failure in libbpf, reported by John Paul Adrian Glaubitz <glaubitz(a)physik.fu-berlin.de>; update comment and commit message accordingly; - cc'ed <stable(a)vger.kernel.org> as older kernels ought to be fixed as well. --- Ivan Kokshaysky (4): alpha/uapi: do not expose kernel-only stack frame structures alpha: replace hardcoded stack offsets with autogenerated ones alpha: make stack 16-byte aligned (most cases) alpha: align stack for page fault and user unaligned trap handlers arch/alpha/include/asm/ptrace.h | 64 ++++++++++++++++++++++++++- arch/alpha/include/uapi/asm/ptrace.h | 65 ++-------------------------- arch/alpha/kernel/asm-offsets.c | 4 ++ arch/alpha/kernel/entry.S | 24 +++++----- arch/alpha/kernel/traps.c | 2 +- arch/alpha/mm/fault.c | 4 +- 6 files changed, 83 insertions(+), 80 deletions(-) -- 2.39.5

3 weeks, 2 days

5
17
0 0

[PATCH v8 02/13] drm/bridge: cdns-dsi: Fix phy de-init and flag it so

by Aradhya Bhatia

From: Aradhya Bhatia <a-bhatia1(a)ti.com> The driver code doesn't have a Phy de-initialization path as yet, and so it does not clear the phy_initialized flag while suspending. This is a problem because after resume the driver looks at this flag to determine if a Phy re-initialization is required or not. It is in fact required because the hardware is resuming from a suspend, but the driver does not carry out any re-initialization causing the D-Phy to not work at all. Call the counterparts of phy_init() and phy_power_on(), that are phy_exit() and phy_power_off(), from _bridge_post_disable(), and clear the flags so that the Phy can be initialized again when required. Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework") Cc: Stable List <stable(a)vger.kernel.org> Signed-off-by: Aradhya Bhatia <a-bhatia1(a)ti.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia(a)linux.dev> --- drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c index 2f897ea5e80a..b0a1a6774ea6 100644 --- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c +++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c @@ -680,6 +680,11 @@ static void cdns_dsi_bridge_post_disable(struct drm_bridge *bridge) struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge); struct cdns_dsi *dsi = input_to_dsi(input); + dsi->phy_initialized = false; + dsi->link_initialized = false; + phy_power_off(dsi->dphy); + phy_exit(dsi->dphy); + pm_runtime_put(dsi->base.dev); } @@ -1152,7 +1157,6 @@ static int __maybe_unused cdns_dsi_suspend(struct device *dev) clk_disable_unprepare(dsi->dsi_sys_clk); clk_disable_unprepare(dsi->dsi_p_clk); reset_control_assert(dsi->dsi_p_rst); - dsi->link_initialized = false; return 0; } -- 2.34.1

3 weeks, 2 days

3
2
0 0

Publish Your Research in e-Informatica Software Engineering Journal (IF=1.2, Open Access & Free of Charge)

by e-Informatica Software Engineering Journal

Dear Prof./Dr. Table, e-Informatica Software Engineering Journal (EISEJ) is an established, peer-reviewed, ISI JCR-indexed journal with an Impact Factor (IF=1.2, 5 Year IF=1.3) calculated by Clarivate and a free-of-charge, open-access publishing model that accepts papers in Software Engineering, including the intersection of data science (AI/ML) and Software Engineering. Since you have published your research results at premier software engineering conferences, such as MSR24, we believe that EISEJ can serve as an excellent platform to share your impactful work further, connecting it with a broad, engaged audience and enhancing your visibility even more. Why choose EISEJ for your next publication? - Reputation and Trust: Indexed in ISI Web of Science (IF=1.2, 5 Year IF=1.3), Scopus (CiteScore'23=2.6, CiteScoreTracker'24=3.3 and growing), DBLP, DOAJ, and Google Scholar, demonstrating our global reach and credibility. - No Author Fees: Publish your work under a CC-BY license without any costs, making your research accessible worldwide. - Global Reach and Recognition: Internationally renowned Editorial Board: https://www.e-informatyka.pl/index.php/einformatica/editorial-board/ . - Efficient Publishing Process: Benefit from continuous, rapid publishing with immediate online availability post-acceptance. - No Restrictions on Paper Length: We welcome comprehensive work without word or page limits. What We Publish: In addition to regular research papers, EISEJ is an ideal venue for: - Systematic reviews, mapping studies, and survey research studies, and supporting tools, see, e.g., [1] Norsaremah Salleh, Emilia Mendes, Fabiana Mendes, Charitha Dissanayake Lekamlage and Kai Petersen, "Value-based Software Engineering: A Systematic Mapping Study", In e-Informatica Software Engineering Journal, vol. 17, no. 1, pp. 230106, 2023. DOI: 10.37190/e-Inf230106. [2] Chris Marshall, Barbara Kitchenham and Pearl Brereton, "Tool Features to Support Systematic Reviews in Software Engineering – A Cross Domain Study", In e-Informatica Software Engineering Journal, vol. 12, no. 1, pp. 79–115, 2018. DOI: 10.5277/e-Inf180104. - Guidelines, see, e.g., [3] Miroslaw Staron, "Guidelines for Conducting Action Research Studies in Software Engineering", In e-Informatica Software Engineering Journal, vol. 19, no. 1, pp. 250105, 2025. DOI: 10.37190/e-Inf250105. [4] Muhammad Usman, Nauman Bin Ali and Claes Wohlin, "A Quality Assessment Instrument for Systematic Literature Reviews in Software Engineering", In e-Informatica Software Engineering Journal, vol. 17, no. 1, pp. 230105, 2023. DOI: 10.37190/e-Inf230105. - Research agendas and vision papers, see, e.g., [5] Michael Unterkalmsteiner, Pekka Abrahamsson, XiaoFeng Wang, Anh Nguyen-Duc, Syed Shah, Sohaib Shahid Bajwa, Guido H. Baltes, Kieran Conboy, Eoin Cullina, Denis Dennehy, Henry Edison, Carlos Fernandez-Sanchez, Juan Garbajosa, Tony Gorschek, Eriks Klotins, Laura Hokkanen, Fabio Kon, Ilaria Lunesu, Michele Marchesi, Lorraine Morgan, Markku Oivo, Christoph Selig, Pertti Seppänen, Roger Sweetman, Pasi Tyrväinen, Christina Ungerer and Agustin Yagüe, "Software Startups – A Research Agenda", In e-Informatica Software Engineering Journal, vol. 10, no. 1, pp. 89–124, 2016. DOI: 10.5277/e-Inf160105. [6] Einav Peretz-Andersson and Richard Torkar, "Empirical AI Transformation Research: A Systematic Mapping Study and Future Agenda", In e-Informatica Software Engineering Journal, vol. 16, no. 1, pp. 220108, 2022. DOI: 10.37190/e-Inf220108. - Interdisciplinary work at the intersection of Software Engineering and AI/ML, see, e.g., [7] Mirosław Ochodek and Miroslaw Staron, "ACoRA – A Platform for Automating Code Review Tasks", In e-Informatica Software Engineering Journal, vol. 19, no. 1, pp. 250102, 2025. DOI: 10.37190/e-Inf250102. We are also open to proposals for special sections that reflect the latest trends and challenges in the field. If you have ideas for collaboration or suggestions on how we can better meet researchers’ needs, we welcome your feedback at e-informatica(a)pwr.edu.pl . Explore our journal at: https://www.e-informatyka.pl/ , and start your submission process at https://mc.manuscriptcentral.com/e-InformaticaSEJ . We recommend using our latest LaTeX template available at https://www.e-informatyka.pl/index.php/einformatica/authors-guide/paper-sub… With best regards, Lech Madeyski & Miroslaw Ochodek Editors-in-Chief, e-Informatica Software Engineering Journal (EISEJ) --- EISEJ is indexed by: - ISI WoS with Impact Factor (IF=1.2, 5 Year IF=1.3) calculated by Clarivate: https://jcr.clarivate.com/jcr-jp/journal-profile?journal=E-INFORMATICA&year… - Scopus (with CiteScore=2.6): https://www.scopus.com/sourceid/21100259509 - DBLP: https://dblp.uni-trier.de/db/journals/eInformatica/index.html - Directory of Open Access Journals (DOAJ): https://www.doaj.org/toc/2084-4840 - Google Scholar: https://scholar.google.pl/citations?user=8-uDLDoAAAAJ&hl --- Opt out: If you do not want to receive further e-mails from us, please use this link: https://listmonk.e-informatyka.pl/subscription/c3d88966-bba6-42ee-af4c-3eab…

3 weeks, 2 days

1
0
0 0

[PATCH] arm64: Handle .ARM.attributes section in linker scripts

by Nathan Chancellor

A recent LLVM commit [1] started generating an .ARM.attributes section similar to the one that exists for 32-bit, which results in orphan section warnings (or errors if CONFIG_WERROR is enabled) from the linker because it is not handled in the arm64 linker scripts. ld.lld: error: arch/arm64/kernel/vdso/vgettimeofday.o:(.ARM.attributes) is being placed in '.ARM.attributes' ld.lld: error: arch/arm64/kernel/vdso/vgetrandom.o:(.ARM.attributes) is being placed in '.ARM.attributes' ld.lld: error: vmlinux.a(lib/vsprintf.o):(.ARM.attributes) is being placed in '.ARM.attributes' ld.lld: error: vmlinux.a(lib/win_minmax.o):(.ARM.attributes) is being placed in '.ARM.attributes' ld.lld: error: vmlinux.a(lib/xarray.o):(.ARM.attributes) is being placed in '.ARM.attributes' Add this new section to the necessary linker scripts to resolve the warnings. Cc: stable(a)vger.kernel.org Fixes: b3e5d80d0c48 ("arm64/build: Warn on orphan section placement") Link: https://github.com/llvm/llvm-project/commit/ee99c4d4845db66c4daa2373352133f… [1] Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- arch/arm64/kernel/vdso/vdso.lds.S | 1 + arch/arm64/kernel/vmlinux.lds.S | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/arm64/kernel/vdso/vdso.lds.S b/arch/arm64/kernel/vdso/vdso.lds.S index 4ec32e86a8da..f8418a3a2758 100644 --- a/arch/arm64/kernel/vdso/vdso.lds.S +++ b/arch/arm64/kernel/vdso/vdso.lds.S @@ -75,6 +75,7 @@ SECTIONS DWARF_DEBUG ELF_DETAILS + .ARM.attributes 0 : { *(.ARM.attributes) } /DISCARD/ : { *(.data .data.* .gnu.linkonce.d.* .sdata*) diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S index f84c71f04d9e..c94942e9eb46 100644 --- a/arch/arm64/kernel/vmlinux.lds.S +++ b/arch/arm64/kernel/vmlinux.lds.S @@ -335,6 +335,7 @@ SECTIONS STABS_DEBUG DWARF_DEBUG ELF_DETAILS + .ARM.attributes 0 : { *(.ARM.attributes) } HEAD_SYMBOLS --- base-commit: 1dd3393696efba1598aa7692939bba99d0cffae3 change-id: 20250123-arm64-handle-arm-attributes-in-linker-script-82aee25313ac Best regards, -- Nathan Chancellor <nathan(a)kernel.org>

3 weeks, 2 days

2
1
0 0

Request to apply 961b4b5e86bf to LTS kernels

by Chuck Lever

Hi - May I request that you apply 961b4b5e86bf ("NFSD: Reset cb_seq_status after NFS4ERR_DELAY") to all LTS kernels that don't have it? I've checked that it applies cleanly to at least v6.1 and run it through NFSD CI. It should not be a problem to apply it elsewhere. -- Chuck Lever

3 weeks, 2 days

2
1
0 0

[PATCH] arm64: kprobe: fix an error in single stepping support

by 1534428646＠qq.com

From: "Yiren Xie" <1534428646(a)qq.com> It is obvious a conflict between the code and the comment. The function aarch64_insn_is_steppable is used to check if a mrs instruction can be safe in single-stepping environment, in the comment it says only reading DAIF bits by mrs is safe in single-stepping environment, and other mrs instructions are not. So aarch64_insn_is_steppable should returen "TRUE" if the mrs instruction being single stepped is reading DAIF bits. And have verified using a kprobe kernel module which reads the DAIF bits by function arch_local_irq_save with offset setting to 0x4, confirmed that without this modification, it encounters "kprobe_init: register_kprobe failed, returned -22" error while inserting the kprobe kernel module. and with this modification, it can read the DAIF bits in single-stepping environment. Fixes: 2dd0e8d2d2a1 ("arm64: Kprobes with single stepping support") Cc: stable(a)vger.kernel.org Signed-off-by: Yiren Xie <1534428646(a)qq.com> --- arch/arm64/kernel/probes/decode-insn.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/kernel/probes/decode-insn.c b/arch/arm64/kernel/probes/decode-insn.c index 6438bf62e753..22383eb1c22c 100644 --- a/arch/arm64/kernel/probes/decode-insn.c +++ b/arch/arm64/kernel/probes/decode-insn.c @@ -40,7 +40,7 @@ static bool __kprobes aarch64_insn_is_steppable(u32 insn) */ if (aarch64_insn_is_mrs(insn)) return aarch64_insn_extract_system_reg(insn) - != AARCH64_INSN_SPCLREG_DAIF; + == AARCH64_INSN_SPCLREG_DAIF; /* * The HINT instruction is steppable only if it is in whitelist -- 2.34.1

3 weeks, 2 days

3
2
0 0

Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219 sge_count (-12) is out of range

by Harshvardhan Jha

Hi All, +stable There seems to be some formatting issues in my log output. I have attached it as a file. Thanks & Regards, Harshvardhan On 29/01/25 1:57 PM, Harshvardhan Jha wrote: > Hello there, > > The stable tag v5.4.289 seems to fail to boot with following trace: > > [ OK ] Created slice system-serial\x2dgetty.slice. [ OK ] Listening on > udev Control Socket. [ OK ] Reached target Local Encrypted Volumes. [ OK > ] Listening on /dev/initctl Compatibility Named Pipe. [ OK ] Listening > on Delayed Shutdown Socket. [ OK ] Created slice > system-selinux\x2dpol...grate\x2dlocal\x2dchanges.slice. [ OK ] Stopped > target Initrd File Systems. [ OK ] Listening on LVM2 metadata daemon > socket. Mounting Debug File System... [ OK ] Listening on networkd > rtnetlink socket. [ OK ] Listening on Device-mapper event daemon FIFOs. > Starting Monitoring of LVM2 mirrors... dmeventd or progress polling... [ > OK ] Created slice User and Session Slice. Starting Read and set NIS > domainname from /etc/sysconfig/network... Starting Load legacy module > configuration... [ OK ] Set up automount Arbitrary Executab...ats File > System Automount Point. [ OK ] Created slice > system-rdma\x2dload\x2dmodules.slice. [ OK ] Started Forward Password > Requests to Wall Directory Watch. [ OK ] Reached target Paths. Starting > Remount Root and Kernel File Systems... [ OK ] Created slice > system-getty.slice. Starting Create list of required st... nodes for the > current kernel... Starting Set Up Additional Binary Formats... [ OK ] > Stopped target Initrd Root File System. [ OK ] Reached target Slices. [ > OK ] Created slice system-systemd\x2dfsck.slice. [ OK ] Mounted POSIX > Message Queue File System. [ OK ] Mounted Debug File System. [ OK ] > Started Read and set NIS domainname from /etc/sysconfig/network. > Mounting Arbitrary Executable File Formats File System... [ OK ] Started > Journal Service. [ OK ] Started Create list of required sta...ce nodes > for the current kernel. Starting Create Static Device Nodes in /dev... [ > OK ] Started LVM2 metadata daemon. [ OK ] Started Remount Root and > Kernel File Systems. Starting Load/Save Random Seed... Starting udev > Coldplug all Devices... Starting Flush Journal to Persistent Storage... > [FAILED] Failed to start Load Kernel Modules. See 'systemctl status > systemd-modules-load.service' for details. Starting Apply Kernel > Variables... [ OK ] Started Load/Save Random Seed. [ OK ] Mounted > Arbitrary Executable File Formats File System. [ OK ] Started Set Up > Additional Binary Formats. [ OK ] Started Create Static Device Nodes in > /dev. Starting udev Kernel Device Manager... [ OK ] Started Apply Kernel > Variables. [ OK ] Started Load legacy module configuration. [ OK ] > Started udev Coldplug all Devices. Starting udev Wait for Complete > Device Initialization... [ 24.427217] megaraid_sas 0000:65:00.0: > megasas_build_io_fusion 3273 sge_count (-12) is out of range. Range is: > 0-256 > > [ 24.427217] megaraid_sas 0000:65:00.0: megasas_build_io_fusion 3273 > sge_count (-12) is out of range. Range is: 0-256 kept showing > infinitely. It kept popping until I reset the system. > > Reverting the following patch seems to fix the issue: > > commit 07c9cccc4c3fecba175a7e5aafba6370758f5ce2 > Author: Juergen Gross <jgross(a)suse.com> > Date: Fri Sep 13 12:05:02 2024 +0200 > > xen/swiotlb: add alignment check for dma buffers > > [ Upstream commit 9f40ec84a7976d95c34e7cc070939deb103652b0 ] > > When checking a memory buffer to be consecutive in machine memory, > the alignment needs to be checked, too. Failing to do so might result > in DMA memory not being aligned according to its requested size, > leading to error messages like: > > 4xxx 0000:2b:00.0: enabling device (0140 -> 0142) > 4xxx 0000:2b:00.0: Ring address not aligned > 4xxx 0000:2b:00.0: Failed to initialise service qat_crypto > 4xxx 0000:2b:00.0: Resetting device qat_dev0 > 4xxx: probe of 0000:2b:00.0 failed with error -14 > > Fixes: 9435cce87950 ("xen/swiotlb: Add support for 64KB page > granularity") > Signed-off-by: Juergen Gross <jgross(a)suse.com> > Reviewed-by: Stefano Stabellini <sstabellini(a)kernel.org> > Signed-off-by: Juergen Gross <jgross(a)suse.com> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > I tried changing swiotlb grub command line arguments but that didn't > seem to help much unfortunately and the error was seen again. > > Thanks & Regards, > Harshvardhan >

3 weeks, 2 days

5
18
0 0

[PATCH v1] usb: core: fix pipe creation for get_bMaxPacketSize0

by Stefan Eichenberger

From: Stefan Eichenberger <stefan.eichenberger(a)toradex.com> When usb_control_msg is used in the get_bMaxPacketSize0 function, the USB pipe does not include the endpoint device number. This can cause failures when a usb hub port is reinitialized after encountering a bad cable connection. As a result, the system logs the following error messages: usb usb2-port1: cannot reset (err = -32) usb usb2-port1: Cannot enable. Maybe the USB cable is bad? usb usb2-port1: attempt power cycle usb 2-1: new high-speed USB device number 5 using ci_hdrc usb 2-1: device descriptor read/8, error -71 The problem began after commit 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads"). There usb_get_device_descriptor was replaced with get_bMaxPacketSize0. Unlike usb_get_device_descriptor, the get_bMaxPacketSize0 function uses the macro usb_rcvaddr0pipe, which does not include the endpoint device number. usb_get_device_descriptor, on the other hand, used the macro usb_rcvctrlpipe, which includes the endpoint device number. By modifying the get_bMaxPacketSize0 function to use usb_rcvctrlpipe instead of usb_rcvaddr0pipe, the issue can be resolved. This change will ensure that the endpoint device number is included in the USB pipe, preventing reinitialization failures. If the endpoint has not set the device number yet, it will still work because the device number is 0 in udev. Cc: stable(a)vger.kernel.org Fixes: 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads") Signed-off-by: Stefan Eichenberger <stefan.eichenberger(a)toradex.com> --- Before commit 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads") usb_rcvaddr0pipe was used in hub_port_init. With this proposed change, usb_rcvctrlpipe will be used which includes devnum for the pipe. I'm not sure if this might have some side effects. However, my understanding is that devnum is set to the right value (might also be 0 if not initialised) before get_bMaxPacketSize0 is called. Therefore, this should work but please let me know if I'm wrong on this. --- drivers/usb/core/hub.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index c3f839637cb5..59e38780f76d 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -4698,7 +4698,6 @@ void usb_ep0_reinit(struct usb_device *udev) EXPORT_SYMBOL_GPL(usb_ep0_reinit); #define usb_sndaddr0pipe() (PIPE_CONTROL << 30) -#define usb_rcvaddr0pipe() ((PIPE_CONTROL << 30) | USB_DIR_IN) static int hub_set_address(struct usb_device *udev, int devnum) { @@ -4804,7 +4803,7 @@ static int get_bMaxPacketSize0(struct usb_device *udev, for (i = 0; i < GET_MAXPACKET0_TRIES; ++i) { /* Start with invalid values in case the transfer fails */ buf->bDescriptorType = buf->bMaxPacketSize0 = 0; - rc = usb_control_msg(udev, usb_rcvaddr0pipe(), + rc = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0), USB_REQ_GET_DESCRIPTOR, USB_DIR_IN, USB_DT_DEVICE << 8, 0, buf, size, -- 2.45.2

3 weeks, 2 days

2
2
0 0

stable-rc/linux-5.10.y: new build regression: passing 'const struct net *' to parameter of type 'struc...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.10.y: passing 'const struct net *' to parameter of type 'struct net *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers] in net/ipv4/udp.o (net/ipv4/udp.c) [logspec:kbuild,kbuild.compiler.error] - Dashboard: https://staging.dashboard.kernelci.org:9000/issue/maestro:841ec27ef8554e3fd… - Grafana: https://grafana.kernelci.org/d/issue/issue?var-id=maestro:841ec27ef8554e3fd… Log excerpt: net/ipv4/udp.c:447:29: error: passing 'const struct net *' to parameter of type 'struct net *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers] 447 | score = compute_score(sk, net, | ^~~ net/ipv4/udp.c:359:55: note: passing argument to parameter 'net' here 359 | static int compute_score(struct sock *sk, struct net *net, | ^ 1 error generated. # Builds where the incident occurred: ## i386_defconfig+allmodconfig(clang-17): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11a6a661a7bc87… ## x86_64_defconfig+allmodconfig(clang-17): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11a3d661a7bc87… ## defconfig+allmodconfig(clang-17): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11a31661a7bc87… ## x86_64_defconfig(clang-17): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11a39661a7bc87… ## defconfig+allmodconfig(clang-17): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11a35661a7bc87… #kernelci issue maestro:841ec27ef8554e3fda7cfd5babc4831387ac9e8e -- This is an experimental report format. Please send feedback in! Talk to us at kerneci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

3 weeks, 2 days

2
1
0 0

stable-rc/linux-5.4.y: new build regression: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.4.y: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘__free’ in drivers/soc/atmel/soc.o (drivers/soc/atmel/soc.c) [logspec:kbuild,kbuild.compiler.error] - Dashboard: https://staging.dashboard.kernelci.org:9000/issue/maestro:040dcc33328a47e52… - Grafana: https://grafana.kernelci.org/d/issue/issue?var-id=maestro:040dcc33328a47e52… Log excerpt: drivers/soc/atmel/soc.c:277:32: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘__free’ 277 | struct device_node *np __free(device_node) = of_find_node_by_path("/"); | ^~~~~~ drivers/soc/atmel/soc.c:277:32: error: implicit declaration of function ‘__free’; did you mean ‘kzfree’? [-Werror=implicit-function-declaration] 277 | struct device_node *np __free(device_node) = of_find_node_by_path("/"); | ^~~~~~ | kzfree drivers/soc/atmel/soc.c:277:39: error: ‘device_node’ undeclared (first use in this function) 277 | struct device_node *np __free(device_node) = of_find_node_by_path("/"); | ^~~~~~~~~~~ drivers/soc/atmel/soc.c:277:39: note: each undeclared identifier is reported only once for each function it appears in drivers/soc/atmel/soc.c:279:51: error: ‘np’ undeclared (first use in this function); did you mean ‘nop’? 279 | if (!of_match_node(at91_soc_allowed_list, np)) | ^~ | nop CC drivers/spi/spidev.o cc1: some warnings being treated as errors # Builds where the incident occurred: ## multi_v7_defconfig(gcc-12): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a119e4661a7bc87… ## multi_v5_defconfig(gcc-12): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a119e0661a7bc87… ## multi_v7_defconfig(gcc-12): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a119d8661a7bc87… #kernelci issue maestro:040dcc33328a47e528c393a656a52b340b4ccc8b -- This is an experimental report format. Please send feedback in! Talk to us at kerneci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

3 weeks, 2 days

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror