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

[REGRESSION] stable-rc/linux-5.15.y: (build) GCC does not allow variable declarations in for loop initializers ...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.15.y: --- GCC does not allow variable declarations in for loop initializers before C99 [-Werror,-Wgcc-compat] in mm/mempool.o (mm/mempool.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:5387ce1530c340d198d1f318d34f9904675295a1 - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: 0001989708674740432a288983eddc1fdad1073b Please include the KernelCI tag when submitting a fix: Reported-by: kernelci.org bot <bot(a)kernelci.org> Log excerpt: ===================================================== mm/mempool.c:68:8: error: GCC does not allow variable declarations in for loop initializers before C99 [-Werror,-Wgcc-compat] 68 | for (int i = 0; i < (1 << order); i++) { | ^ mm/mempool.c:101:8: error: GCC does not allow variable declarations in for loop initializers before C99 [-Werror,-Wgcc-compat] 101 | for (int i = 0; i < (1 << order); i++) { | ^ CC kernel/irq/spurious.o 2 errors generated. ===================================================== # Builds where the incident occurred: ## defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (arm): - compiler: clang-21 - config: https://files.kernelci.org/kbuild-clang-21-arm-allmodconfig-69286d2ef5b8743… - dashboard: https://d.kernelci.org/build/maestro:69286d2ef5b8743b1f65f3ee ## i386_defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (i386): - compiler: clang-21 - config: https://files.kernelci.org/kbuild-clang-21-i386-allmodconfig-69286d6ff5b874… - dashboard: https://d.kernelci.org/build/maestro:69286d6ff5b8743b1f65f41f #kernelci issue maestro:5387ce1530c340d198d1f318d34f9904675295a1 -- 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

1
0
0 0

Optimiza tu reclutamiento con PsicoSmart

by Valeria Pérez

Mejora tus contrataciones con PsicoSmart body { margin: 0; padding: 0; font-family: Arial, Helvetica, sans-serif; font-size: 14px; color: #333; background-color: #ffffff; } table { border-spacing: 0; width: 100%; max-width: 600px; margin: auto; } td { padding: 12px 20px; } a { color: #1a73e8; text-decoration: none; } .footer { font-size: 12px; color: #888888; text-align: center; } Evalúa talento de forma objetiva y mejora tus contrataciones con PsicoSmart. Hola, , ¿Te ha pasado que un candidato luce perfecto en entrevista, pero en el trabajo no encaja como esperabas? En selección, confiar solo en la percepción puede llevar a decisiones costosas. Por eso quiero presentarte PsicoSmart, una herramienta creada para que los equipos de Recursos Humanos tomen decisiones más objetivas y acertadas. Con PsicoSmart puedes: Aplicar 31 pruebas psicométricas que evalúan liderazgo, honestidad, comunicación e inteligencia. Validar conocimientos técnicos con más de 2,500 exámenes especializados. Supervisar la identidad de quien responde mediante captura fotográfica automática durante la evaluación. Gestionar todo desde una sola plataforma, accesible desde cualquier dispositivo. Si estás buscando mejorar tus contrataciones, podría ser una muy buena opción. Si quieres conocer más puedes responder este correo o simplemente contactarme, mis datos están abajo. Saludos, -------------- Atte.: Valeria Pérez Ciudad de México: (55) 5018 0565 WhatsApp: +52 33 1607 2089 Si no deseas recibir más correos, haz clic aquí para darte de baja. Para remover su dirección de esta lista haga <a href="https://s1.arrobamail.com/unsuscribe.php?id=yiwtsrewiswqrwseup">click aquí</a>

2 weeks

1
0
0 0

[PATCH] soc: samsung: exynos-pmu: fix device leak on regmap lookup

by Johan Hovold

Make sure to drop the reference taken when looking up the PMU device and its regmap. Note that holding a reference to a device does not prevent its regmap from going away so there is no point in keeping the reference. Fixes: 0b7c6075022c ("soc: samsung: exynos-pmu: Add regmap support for SoCs that protect PMU regs") Cc: stable(a)vger.kernel.org # 6.9 Cc: Peter Griffin <peter.griffin(a)linaro.org> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/soc/samsung/exynos-pmu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c index 22c50ca2aa79..ba4de8194a0e 100644 --- a/drivers/soc/samsung/exynos-pmu.c +++ b/drivers/soc/samsung/exynos-pmu.c @@ -346,6 +346,8 @@ struct regmap *exynos_get_pmu_regmap_by_phandle(struct device_node *np, if (!dev) return ERR_PTR(-EPROBE_DEFER); + put_device(dev); + return syscon_node_to_regmap(pmu_np); } EXPORT_SYMBOL_GPL(exynos_get_pmu_regmap_by_phandle); -- 2.51.2

2 weeks

2
4
0 0

[PATCH 6.1] ksmbd: fix use-after-free in session logoff

by Nazar Kalashnikov

From: Nazar Kalashnikov <sivartiwe(a)gmail.com> From: Sean Heelan <seanheelan(a)gmail.com> commit 2fc9feff45d92a92cd5f96487655d5be23fb7e2b upstream. The sess->user object can currently be in use by another thread, for example if another connection has sent a session setup request to bind to the session being free'd. The handler for that connection could be in the smb2_sess_setup function which makes use of sess->user. Signed-off-by: Sean Heelan <seanheelan(a)gmail.com> Acked-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Nazar Kalashnikov <sivartiwe(a)gmail.com> --- Backport fix for CVE-2025-37899 fs/smb/server/smb2pdu.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index d2dca5d2f17c..f72ef3fe4968 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -2252,10 +2252,6 @@ int smb2_session_logoff(struct ksmbd_work *work) sess->state = SMB2_SESSION_EXPIRED; up_write(&conn->session_lock); - if (sess->user) { - ksmbd_free_user(sess->user); - sess->user = NULL; - } ksmbd_all_conn_set_status(sess_id, KSMBD_SESS_NEED_NEGOTIATE); rsp->StructureSize = cpu_to_le16(4); -- 2.39.2

2 weeks

2
1
0 0

[PATCH 6.6] ksmbd: fix use-after-free in session logoff

by Nazar Kalashnikov

From: Nazar Kalashnikov <sivartiwe(a)gmail.com> From: Sean Heelan <seanheelan(a)gmail.com> commit 2fc9feff45d92a92cd5f96487655d5be23fb7e2b upstream. The sess->user object can currently be in use by another thread, for example if another connection has sent a session setup request to bind to the session being free'd. The handler for that connection could be in the smb2_sess_setup function which makes use of sess->user. Signed-off-by: Sean Heelan <seanheelan(a)gmail.com> Acked-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Nazar Kalashnikov <sivartiwe(a)gmail.com> --- Backport fix for CVE-2025-37899 fs/smb/server/smb2pdu.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index 9f64808c7917..a819f198c333 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -2255,10 +2255,6 @@ int smb2_session_logoff(struct ksmbd_work *work) sess->state = SMB2_SESSION_EXPIRED; up_write(&conn->session_lock); - if (sess->user) { - ksmbd_free_user(sess->user); - sess->user = NULL; - } ksmbd_all_conn_set_status(sess_id, KSMBD_SESS_NEED_SETUP); rsp->StructureSize = cpu_to_le16(4); -- 2.43.0

2 weeks

1
0
0 0

[PATCH] Revert "arm64: dts: rockchip: fix audio-supply for Rock Pi 4"

by Quentin Schulz

From: Quentin Schulz <quentin.schulz(a)cherry.de> This reverts commit 8240e87f16d17a9592c9d67857a3dcdbcb98f10d. The original commit claimed that APIO5 IO domain (supplied with audio-supply) is supplied by RK808-D Buck 4 as stated in the schematics. The linked PDF has two non-schematics pages where APIO5 indeed is said to be 1.8V. Reading the actual schematics[1][2][3][4][5][6][7][8], this is actually wrong as APIO5 is supplied VCC_3V0 which is LDO8 from RK808-D and is 3.0V instead of 1.8V from vcca1v8_codec. This fixes the console disappearing in U-Boot, where the Device Tree is imported from the Linux kernel repo, when the IO domain driver is built, as reported by Heinrich[9]. As to why this breaks the console while the serial is not exposed on any of the pins on the bank in the APIO5 domain, that is a well-kept secret by the SoC for now. The issue "fixed" by the original commit will need to be fixed another way. [1] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/4ap/radxa_rock_4ap_v1600_schem… [2] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/4ap/radxa_rock_4ap_v1730_schem… [3] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/4bp/radxa_rock_4bp_v1600_schem… [4] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/4bp/radxa_rock_4bp_v1730_schem… [5] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/ROCK-4-SE-V1.53-SCH.pdf [6] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/4b/ROCK_4B_v1.52_SCH.pdf [7] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/4a/ROCK_4A_V1.52_SCH.pdf [8] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/rockpi4_v13_sch_20181112.pdf [9] https://lore.kernel.org/u-boot/e7b7b905-4a6c-4342-b1a5-0ad32a5837cf@gmx.de/ Cc: stable(a)vger.kernel.org Reported-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> Signed-off-by: Quentin Schulz <quentin.schulz(a)cherry.de> --- Note: I do not own any of the Rock Pi 4 variants so I cannot work on fixing the original issue report by Alex. --- arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi index 046dbe3290178..fda7ea87e4efc 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi @@ -516,7 +516,7 @@ &i2s2 { }; &io_domains { - audio-supply = <&vcca1v8_codec>; + audio-supply = <&vcc_3v0>; bt656-supply = <&vcc_3v0>; gpio1830-supply = <&vcc_3v0>; sdmmc-supply = <&vcc_sdio>; --- base-commit: 765e56e41a5af2d456ddda6cbd617b9d3295ab4e change-id: 20251127-rock-pi-4-io-domain-apio5-26bc2afa8224 Best regards, -- Quentin Schulz <quentin.schulz(a)cherry.de>

2 weeks

2
1
0 0

[PATCH] Revert "gpio: swnode: don't use the swnode's name as the key for GPIO lookup"

by Charles Keepax

This reverts commit 25decf0469d4c91d90aa2e28d996aed276bfc622. This software node change doesn't actually fix any current issues with the kernel, it is an improvement to the lookup process rather than fixing a live bug. It also causes a couple of regressions with shipping laptops, which relied on the label based lookup. There is a fix for the regressions in mainline, the first 5 patches of [1]. However, those patches are fairly substantial changes and given the patch causing the regression doesn't actually fix a bug it seems better to just revert it in stable. CC: stable(a)vger.kernel.org # 6.12, 6.17 Link: https://lore.kernel.org/linux-sound/20251120-reset-gpios-swnodes-v7-0-a1004… [1] Closes: https://github.com/thesofproject/linux/issues/5599 Closes: https://github.com/thesofproject/linux/issues/5603 Acked-by: Bartosz Golaszewski <bartosz.golaszewski(a)linaro.org> Signed-off-by: Charles Keepax <ckeepax(a)opensource.cirrus.com> --- I wasn't exactly sure of the proceedure for reverting a patch that was cherry-picked to stable, so apologies if I have made any mistakes here but happy to update if necessary. Thanks, Charles drivers/gpio/gpiolib-swnode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpiolib-swnode.c b/drivers/gpio/gpiolib-swnode.c index e3806db1c0e07..f21dbc28cf2c8 100644 --- a/drivers/gpio/gpiolib-swnode.c +++ b/drivers/gpio/gpiolib-swnode.c @@ -41,7 +41,7 @@ static struct gpio_device *swnode_get_gpio_device(struct fwnode_handle *fwnode) !strcmp(gdev_node->name, GPIOLIB_SWNODE_UNDEFINED_NAME)) return ERR_PTR(-ENOENT); - gdev = gpio_device_find_by_fwnode(fwnode); + gdev = gpio_device_find_by_label(gdev_node->name); return gdev ?: ERR_PTR(-EPROBE_DEFER); } -- 2.47.3

2 weeks

3
13
0 0

[PATCH v2] mm/kfence: add reboot notifier to disable KFENCE on shutdown

by Breno Leitao

During system shutdown, KFENCE can cause IPI synchronization issues if it remains active through the reboot process. To prevent this, register a reboot notifier that disables KFENCE and cancels any pending timer work early in the shutdown sequence. This is only necessary when CONFIG_KFENCE_STATIC_KEYS is enabled, as this configuration sends IPIs that can interfere with shutdown. Without static keys, no IPIs are generated and KFENCE can safely remain active. The notifier uses maximum priority (INT_MAX) to ensure KFENCE shuts down before other subsystems that might still depend on stable memory allocation behavior. This fixes a late kexec CSD lockup[1] when kfence is trying to IPI a CPU that is busy in a IRQ-disabled context printing characters to the console. Link: https://lore.kernel.org/all/sqwajvt7utnt463tzxgwu2yctyn5m6bjwrslsnupfexeml6… [1] Cc: stable(a)vger.kernel.org Signed-off-by: Breno Leitao <leitao(a)debian.org> Reviewed-by: Marco Elver <elver(a)google.com> Fixes: 0ce20dd84089 ("mm: add Kernel Electric-Fence infrastructure") --- Changes in v2: - Adding Fixes: tag and CCing stable (akpm) - Link to v1: https://patch.msgid.link/20251126-kfence-v1-1-5a6e1d7c681c@debian.org --- mm/kfence/core.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/mm/kfence/core.c b/mm/kfence/core.c index 727c20c94ac5..162a026871ab 100644 --- a/mm/kfence/core.c +++ b/mm/kfence/core.c @@ -26,6 +26,7 @@ #include <linux/panic_notifier.h> #include <linux/random.h> #include <linux/rcupdate.h> +#include <linux/reboot.h> #include <linux/sched/clock.h> #include <linux/seq_file.h> #include <linux/slab.h> @@ -820,6 +821,25 @@ static struct notifier_block kfence_check_canary_notifier = { static struct delayed_work kfence_timer; #ifdef CONFIG_KFENCE_STATIC_KEYS +static int kfence_reboot_callback(struct notifier_block *nb, + unsigned long action, void *data) +{ + /* + * Disable kfence to avoid static keys IPI synchronization during + * late shutdown/kexec + */ + WRITE_ONCE(kfence_enabled, false); + /* Cancel any pending timer work */ + cancel_delayed_work_sync(&kfence_timer); + + return NOTIFY_OK; +} + +static struct notifier_block kfence_reboot_notifier = { + .notifier_call = kfence_reboot_callback, + .priority = INT_MAX, /* Run early to stop timers ASAP */ +}; + /* Wait queue to wake up allocation-gate timer task. */ static DECLARE_WAIT_QUEUE_HEAD(allocation_wait); @@ -901,6 +921,10 @@ static void kfence_init_enable(void) if (kfence_check_on_panic) atomic_notifier_chain_register(&panic_notifier_list, &kfence_check_canary_notifier); +#ifdef CONFIG_KFENCE_STATIC_KEYS + register_reboot_notifier(&kfence_reboot_notifier); +#endif + WRITE_ONCE(kfence_enabled, true); queue_delayed_work(system_unbound_wq, &kfence_timer, 0); --- base-commit: ab084f0b8d6d2ee4b1c6a28f39a2a7430bdfa7f0 change-id: 20251126-kfence-42c93f9b3979 Best regards, -- Breno Leitao <leitao(a)debian.org>

2 weeks

1
0
0 0

[PATCH 6.6.y] smb: client: support kvec iterators in async read path

by Henrique Carvalho

commit 3ee1a1fc39819906f04d6c62c180e760cd3a689d upstream. Add cifs_limit_kvec_subset() and select the appropriate limiter in cifs_send_async_read() to handle kvec iterators in async read path, fixing the EIO bug when running executables in cifs shares mounted with nolease. This patch -- or equivalent patch, does not exist upstream, as the upstream code has suffered considerable API changes. The affected path is currently handled by netfs lib and located under netfs/direct_read.c. Reproducer: $ mount.cifs //server/share /mnt -o nolease $ cat - > /mnt/test.sh <<EOL echo hallo EOL $ chmod +x /mnt/test.sh $ /mnt/test.sh bash: /mnt/test.sh: /bin/bash: Defekter Interpreter: Eingabe-/Ausgabefehler $ rm -f /mnt/test.sh Fixes: d08089f649a0 ("cifs: Change the I/O paths to use an iterator rather than a page list") Reported-by: Laura Kerner <laura.kerner(a)ichaus.de> Closes: https://bugzilla.suse.com/show_bug.cgi?id=1245449 Signed-off-by: Henrique Carvalho <henrique.carvalho(a)suse.com> --- fs/smb/client/file.c | 46 ++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 44 insertions(+), 2 deletions(-) diff --git a/fs/smb/client/file.c b/fs/smb/client/file.c index d883ed75022c..4878c74bae6f 100644 --- a/fs/smb/client/file.c +++ b/fs/smb/client/file.c @@ -3527,6 +3527,42 @@ static size_t cifs_limit_bvec_subset(const struct iov_iter *iter, size_t max_siz return span; } +static size_t cifs_limit_kvec_subset(const struct iov_iter *iter, size_t max_size, + size_t max_segs, unsigned int *_nsegs) +{ + const struct kvec *kvecs = iter->kvec; + unsigned int nkv = iter->nr_segs, ix = 0, nsegs = 0; + size_t len, span = 0, n = iter->count; + size_t skip = iter->iov_offset; + + if (WARN_ON(!iov_iter_is_kvec(iter)) || n == 0) + return 0; + + while (n && ix < nkv && skip) { + len = kvecs[ix].iov_len; + if (skip < len) + break; + skip -= len; + n -= len; + ix++; + } + + while (n && ix < nkv) { + len = min3(n, kvecs[ix].iov_len - skip, max_size); + span += len; + max_size -= len; + nsegs++; + ix++; + if (max_size == 0 || nsegs >= max_segs) + break; + skip = 0; + n -= len; + } + + *_nsegs = nsegs; + return span; +} + static int cifs_write_from_iter(loff_t fpos, size_t len, struct iov_iter *from, struct cifsFileInfo *open_file, @@ -4079,6 +4115,13 @@ cifs_send_async_read(loff_t fpos, size_t len, struct cifsFileInfo *open_file, int rc; pid_t pid; struct TCP_Server_Info *server; + size_t (*limit_iov_subset)(const struct iov_iter *iter, size_t max_size, + size_t max_segs, unsigned int *_nsegs); + + if (iov_iter_is_kvec(&ctx->iter)) + limit_iov_subset = cifs_limit_kvec_subset; + else + limit_iov_subset = cifs_limit_bvec_subset; server = cifs_pick_channel(tlink_tcon(open_file->tlink)->ses); @@ -4113,8 +4156,7 @@ cifs_send_async_read(loff_t fpos, size_t len, struct cifsFileInfo *open_file, max_len = min_t(size_t, len, rsize); - cur_len = cifs_limit_bvec_subset(&ctx->iter, max_len, - max_segs, &nsegs); + cur_len = limit_iov_subset(&ctx->iter, max_len, max_segs, &nsegs); cifs_dbg(FYI, "read-to-iter len=%zx/%zx nsegs=%u/%lu/%u\n", cur_len, max_len, nsegs, ctx->iter.nr_segs, max_segs); if (cur_len == 0) { -- 2.47.0

2 weeks

5
8
0 0

please backport 8c9006283e4b ("Revert "drm/i915/dp: Reject HBR3 when sink doesn't support TPS4"")

by Jani Nikula

Stable team, please backport 8c9006283e4b ("Revert "drm/i915/dp: Reject HBR3 when sink doesn't support TPS4"") from v6.18-rc1 to v6.15+. It's missing the obvious Fixes: 584cf613c24a ("drm/i915/dp: Reject HBR3 when sink doesn't support TPS4") Thanks, Jani. -- Jani Nikula, Intel

2 weeks

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror