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

[PATCH v9 2/4] serial: 8250_dw: fix PSLVERR on RX_TIMEOUT

by Yunhui Cui

The DW UART may trigger the RX_TIMEOUT interrupt without data present and remain stuck in this state indefinitely. The dw8250_handle_irq() function detects this condition by checking if the UART_LSR_DR bit is not set when RX_TIMEOUT occurs. When detected, it performs a "dummy read" to recover the DW UART from this state. When the PSLVERR_RESP_EN parameter is set to 1, reading the UART_RX while the FIFO is enabled and UART_LSR_DR is not set will generate a PSLVERR error, which may lead to a system panic. There are two methods to prevent PSLVERR: one is to check if UART_LSR_DR is set before reading UART_RX when the FIFO is enabled, and the other is to read UART_RX when the FIFO is disabled. Given these two scenarios, the FIFO must be disabled before the "dummy read" operation and re-enabled afterward to maintain normal UART functionality. Fixes: 424d79183af0 ("serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt") Signed-off-by: Yunhui Cui <cuiyunhui(a)bytedance.com> Cc: stable(a)vger.kernel.org --- drivers/tty/serial/8250/8250_dw.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c index 1902f29444a1c..082b7fcf251db 100644 --- a/drivers/tty/serial/8250/8250_dw.c +++ b/drivers/tty/serial/8250/8250_dw.c @@ -297,9 +297,17 @@ static int dw8250_handle_irq(struct uart_port *p) uart_port_lock_irqsave(p, &flags); status = serial_lsr_in(up); - if (!(status & (UART_LSR_DR | UART_LSR_BI))) + if (!(status & (UART_LSR_DR | UART_LSR_BI))) { + /* To avoid PSLVERR, disable the FIFO first. */ + if (up->fcr & UART_FCR_ENABLE_FIFO) + serial_out(up, UART_FCR, 0); + serial_port_in(p, UART_RX); + if (up->fcr & UART_FCR_ENABLE_FIFO) + serial_out(up, UART_FCR, up->fcr); + } + uart_port_unlock_irqrestore(p, flags); } -- 2.39.5

1 month, 2 weeks

4
5
0 0

[PATCH 6.6.y 0/2] regulator: pwm-regulator: fix boot hang issue

by Chukun Pan

This series backports the merged series: https://lore.kernel.org/all/20240113224628.377993-1-martin.blumenstingl@goo… The first patch has been backported. Backport the remaining two patches to fix boot hang issues on some Rockchip devices using pwm-regulator. Martin Blumenstingl (2): regulator: pwm-regulator: Calculate the output voltage for disabled PWMs regulator: pwm-regulator: Manage boot-on with disabled PWM channels drivers/regulator/pwm-regulator.c | 40 +++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) -- 2.25.1

1 month, 2 weeks

1
2
0 0

[PATCH] drm/amdgpu: Initialize data to NULL in imu_v12_0_program_rlc_ram()

by Nathan Chancellor

After a recent change in clang to expose uninitialized warnings from const variables and pointers [1], there is a warning in imu_v12_0_program_rlc_ram() because data is passed uninitialized to program_imu_rlc_ram(): drivers/gpu/drm/amd/amdgpu/imu_v12_0.c:374:30: error: variable 'data' is uninitialized when used here [-Werror,-Wuninitialized] 374 | program_imu_rlc_ram(adev, data, (const u32)size); | ^~~~ As this warning happens early in clang's frontend, it does not realize that due to the assignment of r to -EINVAL, program_imu_rlc_ram() is never actually called, and even if it were, data would not be dereferenced because size is 0. Just initialize data to NULL to silence the warning, as the commit that added program_imu_rlc_ram() mentioned it would eventually be used over the old method, at which point data can be properly initialized and used. Cc: stable(a)vger.kernel.org Closes: https://github.com/ClangBuiltLinux/linux/issues/2107 Fixes: 56159fffaab5 ("drm/amdgpu: use new method to program rlc ram") Link: https://github.com/llvm/llvm-project/commit/2464313eef01c5b1edf0eccf57a32cd… [1] Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- drivers/gpu/drm/amd/amdgpu/imu_v12_0.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/imu_v12_0.c b/drivers/gpu/drm/amd/amdgpu/imu_v12_0.c index df898dbb746e..8cb6b1854d24 100644 --- a/drivers/gpu/drm/amd/amdgpu/imu_v12_0.c +++ b/drivers/gpu/drm/amd/amdgpu/imu_v12_0.c @@ -362,7 +362,7 @@ static void program_imu_rlc_ram(struct amdgpu_device *adev, static void imu_v12_0_program_rlc_ram(struct amdgpu_device *adev) { u32 reg_data, size = 0; - const u32 *data; + const u32 *data = NULL; int r = -EINVAL; WREG32_SOC15(GC, 0, regGFX_IMU_RLC_RAM_INDEX, 0x2); --- base-commit: fff8e0504499a929f26e2fb7cf7e2c9854e37b91 change-id: 20250715-drm-amdgpu-fix-const-uninit-warning-db61fe5d135a Best regards, -- Nathan Chancellor <nathan(a)kernel.org>

1 month, 2 weeks

2
1
0 0

[PATCH 6.12.y] btrfs: fix block group refcount race in btrfs_create_pending_block_groups()

by alvalan9＠foxmail.com

From: Boris Burkov <boris(a)bur.io> [ Upstream commit 2d8e5168d48a91e7a802d3003e72afb4304bebfa ] Block group creation is done in two phases, which results in a slightly unintuitive property: a block group can be allocated/deallocated from after btrfs_make_block_group() adds it to the space_info with btrfs_add_bg_to_space_info(), but before creation is completely completed in btrfs_create_pending_block_groups(). As a result, it is possible for a block group to go unused and have 'btrfs_mark_bg_unused' called on it concurrently with 'btrfs_create_pending_block_groups'. This causes a number of issues, which were fixed with the block group flag 'BLOCK_GROUP_FLAG_NEW'. However, this fix is not quite complete. Since it does not use the unused_bg_lock, it is possible for the following race to occur: btrfs_create_pending_block_groups btrfs_mark_bg_unused if list_empty // false list_del_init clear_bit else if (test_bit) // true list_move_tail And we get into the exact same broken ref count and invalid new_bgs state for transaction cleanup that BLOCK_GROUP_FLAG_NEW was designed to prevent. The broken refcount aspect will result in a warning like: [1272.943527] refcount_t: underflow; use-after-free. [1272.943967] WARNING: CPU: 1 PID: 61 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110 [1272.944731] Modules linked in: btrfs virtio_net xor zstd_compress raid6_pq null_blk [last unloaded: btrfs] [1272.945550] CPU: 1 UID: 0 PID: 61 Comm: kworker/u32:1 Kdump: loaded Tainted: G W 6.14.0-rc5+ #108 [1272.946368] Tainted: [W]=WARN [1272.946585] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 [1272.947273] Workqueue: btrfs_discard btrfs_discard_workfn [btrfs] [1272.947788] RIP: 0010:refcount_warn_saturate+0xba/0x110 [1272.949532] RSP: 0018:ffffbf1200247df0 EFLAGS: 00010282 [1272.949901] RAX: 0000000000000000 RBX: ffffa14b00e3f800 RCX: 0000000000000000 [1272.950437] RDX: 0000000000000000 RSI: ffffbf1200247c78 RDI: 00000000ffffdfff [1272.950986] RBP: ffffa14b00dc2860 R08: 00000000ffffdfff R09: ffffffff90526268 [1272.951512] R10: ffffffff904762c0 R11: 0000000063666572 R12: ffffa14b00dc28c0 [1272.952024] R13: 0000000000000000 R14: ffffa14b00dc2868 R15: 000001285dcd12c0 [1272.952850] FS: 0000000000000000(0000) GS:ffffa14d33c40000(0000) knlGS:0000000000000000 [1272.953458] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1272.953931] CR2: 00007f838cbda000 CR3: 000000010104e000 CR4: 00000000000006f0 [1272.954474] Call Trace: [1272.954655] <TASK> [1272.954812] ? refcount_warn_saturate+0xba/0x110 [1272.955173] ? __warn.cold+0x93/0xd7 [1272.955487] ? refcount_warn_saturate+0xba/0x110 [1272.955816] ? report_bug+0xe7/0x120 [1272.956103] ? handle_bug+0x53/0x90 [1272.956424] ? exc_invalid_op+0x13/0x60 [1272.956700] ? asm_exc_invalid_op+0x16/0x20 [1272.957011] ? refcount_warn_saturate+0xba/0x110 [1272.957399] btrfs_discard_cancel_work.cold+0x26/0x2b [btrfs] [1272.957853] btrfs_put_block_group.cold+0x5d/0x8e [btrfs] [1272.958289] btrfs_discard_workfn+0x194/0x380 [btrfs] [1272.958729] process_one_work+0x130/0x290 [1272.959026] worker_thread+0x2ea/0x420 [1272.959335] ? __pfx_worker_thread+0x10/0x10 [1272.959644] kthread+0xd7/0x1c0 [1272.959872] ? __pfx_kthread+0x10/0x10 [1272.960172] ret_from_fork+0x30/0x50 [1272.960474] ? __pfx_kthread+0x10/0x10 [1272.960745] ret_from_fork_asm+0x1a/0x30 [1272.961035] </TASK> [1272.961238] ---[ end trace 0000000000000000 ]--- Though we have seen them in the async discard workfn as well. It is most likely to happen after a relocation finishes which cancels discard, tears down the block group, etc. Fix this fully by taking the lock around the list_del_init + clear_bit so that the two are done atomically. Fixes: 0657b20c5a76 ("btrfs: fix use-after-free of new block group that became unused") Reviewed-by: Qu Wenruo <wqu(a)suse.com> Reviewed-by: Filipe Manana <fdmanana(a)suse.com> Signed-off-by: Boris Burkov <boris(a)bur.io> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Alva Lan <alvalan9(a)foxmail.com> --- fs/btrfs/block-group.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c index aa8656c8b7e7..dd35e29d8082 100644 --- a/fs/btrfs/block-group.c +++ b/fs/btrfs/block-group.c @@ -2780,8 +2780,11 @@ void btrfs_create_pending_block_groups(struct btrfs_trans_handle *trans) /* Already aborted the transaction if it failed. */ next: btrfs_dec_delayed_refs_rsv_bg_inserts(fs_info); + + spin_lock(&fs_info->unused_bgs_lock); list_del_init(&block_group->bg_list); clear_bit(BLOCK_GROUP_FLAG_NEW, &block_group->runtime_flags); + spin_unlock(&fs_info->unused_bgs_lock); /* * If the block group is still unused, add it to the list of -- 2.34.1

1 month, 2 weeks

2
1
0 0

FAILED: patch "[PATCH] ASoC: fsl_sai: Force a software reset when starting in" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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-5.4.y git checkout FETCH_HEAD git cherry-pick -x dc78f7e59169d3f0e6c3c95d23dc8e55e95741e2 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025071259-appendage-epidemic-aae1@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From dc78f7e59169d3f0e6c3c95d23dc8e55e95741e2 Mon Sep 17 00:00:00 2001 From: Arun Raghavan <arun(a)asymptotic.io> Date: Thu, 26 Jun 2025 09:08:25 -0400 Subject: [PATCH] ASoC: fsl_sai: Force a software reset when starting in consumer mode On an imx8mm platform with an external clock provider, when running the receiver (arecord) and triggering an xrun with xrun_injection, we see a channel swap/offset. This happens sometimes when running only the receiver, but occurs reliably if a transmitter (aplay) is also concurrently running. It seems that the SAI loses track of frame sync during the trigger stop -> trigger start cycle that occurs during an xrun. Doing just a FIFO reset in this case does not suffice, and only a software reset seems to get it back on track. This looks like the same h/w bug that is already handled for the producer case, so we now do the reset unconditionally on config disable. Signed-off-by: Arun Raghavan <arun(a)asymptotic.io> Reported-by: Pieterjan Camerlynck <p.camerlynck(a)televic.com> Fixes: 3e3f8bd56955 ("ASoC: fsl_sai: fix no frame clk in master mode") Cc: stable(a)vger.kernel.org Reviewed-by: Fabio Estevam <festevam(a)gmail.com> Link: https://patch.msgid.link/20250626130858.163825-1-arun@arunraghavan.net Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c index af1a168d35e3..50af6b725670 100644 --- a/sound/soc/fsl/fsl_sai.c +++ b/sound/soc/fsl/fsl_sai.c @@ -803,13 +803,15 @@ static void fsl_sai_config_disable(struct fsl_sai *sai, int dir) * anymore. Add software reset to fix this issue. * This is a hardware bug, and will be fix in the * next sai version. + * + * In consumer mode, this can happen even after a + * single open/close, especially if both tx and rx + * are running concurrently. */ - if (!sai->is_consumer_mode[tx]) { - /* Software Reset */ - regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), FSL_SAI_CSR_SR); - /* Clear SR bit to finish the reset */ - regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), 0); - } + /* Software Reset */ + regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), FSL_SAI_CSR_SR); + /* Clear SR bit to finish the reset */ + regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), 0); } static int fsl_sai_trigger(struct snd_pcm_substream *substream, int cmd,

1 month, 2 weeks

2
1
0 0

FAILED: patch "[PATCH] ASoC: fsl_sai: Force a software reset when starting in" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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-5.10.y git checkout FETCH_HEAD git cherry-pick -x dc78f7e59169d3f0e6c3c95d23dc8e55e95741e2 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025071258-retiring-unspoken-567d@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From dc78f7e59169d3f0e6c3c95d23dc8e55e95741e2 Mon Sep 17 00:00:00 2001 From: Arun Raghavan <arun(a)asymptotic.io> Date: Thu, 26 Jun 2025 09:08:25 -0400 Subject: [PATCH] ASoC: fsl_sai: Force a software reset when starting in consumer mode On an imx8mm platform with an external clock provider, when running the receiver (arecord) and triggering an xrun with xrun_injection, we see a channel swap/offset. This happens sometimes when running only the receiver, but occurs reliably if a transmitter (aplay) is also concurrently running. It seems that the SAI loses track of frame sync during the trigger stop -> trigger start cycle that occurs during an xrun. Doing just a FIFO reset in this case does not suffice, and only a software reset seems to get it back on track. This looks like the same h/w bug that is already handled for the producer case, so we now do the reset unconditionally on config disable. Signed-off-by: Arun Raghavan <arun(a)asymptotic.io> Reported-by: Pieterjan Camerlynck <p.camerlynck(a)televic.com> Fixes: 3e3f8bd56955 ("ASoC: fsl_sai: fix no frame clk in master mode") Cc: stable(a)vger.kernel.org Reviewed-by: Fabio Estevam <festevam(a)gmail.com> Link: https://patch.msgid.link/20250626130858.163825-1-arun@arunraghavan.net Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c index af1a168d35e3..50af6b725670 100644 --- a/sound/soc/fsl/fsl_sai.c +++ b/sound/soc/fsl/fsl_sai.c @@ -803,13 +803,15 @@ static void fsl_sai_config_disable(struct fsl_sai *sai, int dir) * anymore. Add software reset to fix this issue. * This is a hardware bug, and will be fix in the * next sai version. + * + * In consumer mode, this can happen even after a + * single open/close, especially if both tx and rx + * are running concurrently. */ - if (!sai->is_consumer_mode[tx]) { - /* Software Reset */ - regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), FSL_SAI_CSR_SR); - /* Clear SR bit to finish the reset */ - regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), 0); - } + /* Software Reset */ + regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), FSL_SAI_CSR_SR); + /* Clear SR bit to finish the reset */ + regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), 0); } static int fsl_sai_trigger(struct snd_pcm_substream *substream, int cmd,

1 month, 2 weeks

2
1
0 0

FAILED: patch "[PATCH] ASoC: fsl_sai: Force a software reset when starting in" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-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-5.15.y git checkout FETCH_HEAD git cherry-pick -x dc78f7e59169d3f0e6c3c95d23dc8e55e95741e2 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025071258-wharf-revisit-b7a3@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From dc78f7e59169d3f0e6c3c95d23dc8e55e95741e2 Mon Sep 17 00:00:00 2001 From: Arun Raghavan <arun(a)asymptotic.io> Date: Thu, 26 Jun 2025 09:08:25 -0400 Subject: [PATCH] ASoC: fsl_sai: Force a software reset when starting in consumer mode On an imx8mm platform with an external clock provider, when running the receiver (arecord) and triggering an xrun with xrun_injection, we see a channel swap/offset. This happens sometimes when running only the receiver, but occurs reliably if a transmitter (aplay) is also concurrently running. It seems that the SAI loses track of frame sync during the trigger stop -> trigger start cycle that occurs during an xrun. Doing just a FIFO reset in this case does not suffice, and only a software reset seems to get it back on track. This looks like the same h/w bug that is already handled for the producer case, so we now do the reset unconditionally on config disable. Signed-off-by: Arun Raghavan <arun(a)asymptotic.io> Reported-by: Pieterjan Camerlynck <p.camerlynck(a)televic.com> Fixes: 3e3f8bd56955 ("ASoC: fsl_sai: fix no frame clk in master mode") Cc: stable(a)vger.kernel.org Reviewed-by: Fabio Estevam <festevam(a)gmail.com> Link: https://patch.msgid.link/20250626130858.163825-1-arun@arunraghavan.net Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c index af1a168d35e3..50af6b725670 100644 --- a/sound/soc/fsl/fsl_sai.c +++ b/sound/soc/fsl/fsl_sai.c @@ -803,13 +803,15 @@ static void fsl_sai_config_disable(struct fsl_sai *sai, int dir) * anymore. Add software reset to fix this issue. * This is a hardware bug, and will be fix in the * next sai version. + * + * In consumer mode, this can happen even after a + * single open/close, especially if both tx and rx + * are running concurrently. */ - if (!sai->is_consumer_mode[tx]) { - /* Software Reset */ - regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), FSL_SAI_CSR_SR); - /* Clear SR bit to finish the reset */ - regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), 0); - } + /* Software Reset */ + regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), FSL_SAI_CSR_SR); + /* Clear SR bit to finish the reset */ + regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), 0); } static int fsl_sai_trigger(struct snd_pcm_substream *substream, int cmd,

1 month, 2 weeks

2
1
0 0

FAILED: patch "[PATCH] ASoC: fsl_sai: Force a software reset when starting in" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-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.1.y git checkout FETCH_HEAD git cherry-pick -x dc78f7e59169d3f0e6c3c95d23dc8e55e95741e2 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025071257-utility-ungodly-5f38@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From dc78f7e59169d3f0e6c3c95d23dc8e55e95741e2 Mon Sep 17 00:00:00 2001 From: Arun Raghavan <arun(a)asymptotic.io> Date: Thu, 26 Jun 2025 09:08:25 -0400 Subject: [PATCH] ASoC: fsl_sai: Force a software reset when starting in consumer mode On an imx8mm platform with an external clock provider, when running the receiver (arecord) and triggering an xrun with xrun_injection, we see a channel swap/offset. This happens sometimes when running only the receiver, but occurs reliably if a transmitter (aplay) is also concurrently running. It seems that the SAI loses track of frame sync during the trigger stop -> trigger start cycle that occurs during an xrun. Doing just a FIFO reset in this case does not suffice, and only a software reset seems to get it back on track. This looks like the same h/w bug that is already handled for the producer case, so we now do the reset unconditionally on config disable. Signed-off-by: Arun Raghavan <arun(a)asymptotic.io> Reported-by: Pieterjan Camerlynck <p.camerlynck(a)televic.com> Fixes: 3e3f8bd56955 ("ASoC: fsl_sai: fix no frame clk in master mode") Cc: stable(a)vger.kernel.org Reviewed-by: Fabio Estevam <festevam(a)gmail.com> Link: https://patch.msgid.link/20250626130858.163825-1-arun@arunraghavan.net Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c index af1a168d35e3..50af6b725670 100644 --- a/sound/soc/fsl/fsl_sai.c +++ b/sound/soc/fsl/fsl_sai.c @@ -803,13 +803,15 @@ static void fsl_sai_config_disable(struct fsl_sai *sai, int dir) * anymore. Add software reset to fix this issue. * This is a hardware bug, and will be fix in the * next sai version. + * + * In consumer mode, this can happen even after a + * single open/close, especially if both tx and rx + * are running concurrently. */ - if (!sai->is_consumer_mode[tx]) { - /* Software Reset */ - regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), FSL_SAI_CSR_SR); - /* Clear SR bit to finish the reset */ - regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), 0); - } + /* Software Reset */ + regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), FSL_SAI_CSR_SR); + /* Clear SR bit to finish the reset */ + regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), 0); } static int fsl_sai_trigger(struct snd_pcm_substream *substream, int cmd,

1 month, 2 weeks

2
1
0 0

FAILED: patch "[PATCH] ASoC: fsl_sai: Force a software reset when starting in" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-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.6.y git checkout FETCH_HEAD git cherry-pick -x dc78f7e59169d3f0e6c3c95d23dc8e55e95741e2 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025071256-clobber-annotate-b978@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From dc78f7e59169d3f0e6c3c95d23dc8e55e95741e2 Mon Sep 17 00:00:00 2001 From: Arun Raghavan <arun(a)asymptotic.io> Date: Thu, 26 Jun 2025 09:08:25 -0400 Subject: [PATCH] ASoC: fsl_sai: Force a software reset when starting in consumer mode On an imx8mm platform with an external clock provider, when running the receiver (arecord) and triggering an xrun with xrun_injection, we see a channel swap/offset. This happens sometimes when running only the receiver, but occurs reliably if a transmitter (aplay) is also concurrently running. It seems that the SAI loses track of frame sync during the trigger stop -> trigger start cycle that occurs during an xrun. Doing just a FIFO reset in this case does not suffice, and only a software reset seems to get it back on track. This looks like the same h/w bug that is already handled for the producer case, so we now do the reset unconditionally on config disable. Signed-off-by: Arun Raghavan <arun(a)asymptotic.io> Reported-by: Pieterjan Camerlynck <p.camerlynck(a)televic.com> Fixes: 3e3f8bd56955 ("ASoC: fsl_sai: fix no frame clk in master mode") Cc: stable(a)vger.kernel.org Reviewed-by: Fabio Estevam <festevam(a)gmail.com> Link: https://patch.msgid.link/20250626130858.163825-1-arun@arunraghavan.net Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c index af1a168d35e3..50af6b725670 100644 --- a/sound/soc/fsl/fsl_sai.c +++ b/sound/soc/fsl/fsl_sai.c @@ -803,13 +803,15 @@ static void fsl_sai_config_disable(struct fsl_sai *sai, int dir) * anymore. Add software reset to fix this issue. * This is a hardware bug, and will be fix in the * next sai version. + * + * In consumer mode, this can happen even after a + * single open/close, especially if both tx and rx + * are running concurrently. */ - if (!sai->is_consumer_mode[tx]) { - /* Software Reset */ - regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), FSL_SAI_CSR_SR); - /* Clear SR bit to finish the reset */ - regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), 0); - } + /* Software Reset */ + regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), FSL_SAI_CSR_SR); + /* Clear SR bit to finish the reset */ + regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), 0); } static int fsl_sai_trigger(struct snd_pcm_substream *substream, int cmd,

1 month, 2 weeks

2
1
0 0

[PATCH] ALSA: hda/realtek - Add mute LED support for HP Victus 15-fa0xxx

by edip＠medip.dev

From: Edip Hazuri <edip(a)medip.dev> The mute led on this laptop is using ALC245 but requires a quirk to work This patch enables the existing quirk for the device. Tested on my Victus 15-fa0xxx Laptop. The LED behaviour works as intended. Cc: <stable(a)vger.kernel.org> Signed-off-by: Edip Hazuri <edip(a)medip.dev> --- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 060db37ea..5cac18cff 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -10769,6 +10769,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x8a2e, "HP Envy 16", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x103c, 0x8a30, "HP Envy 17", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x103c, 0x8a31, "HP Envy 15", ALC287_FIXUP_CS35L41_I2C_2), + SND_PCI_QUIRK(0x103c, 0x8a4f, "HP Victus 15-fa0xxx (MB 8A4F)", ALC245_FIXUP_HP_MUTE_LED_COEFBIT), SND_PCI_QUIRK(0x103c, 0x8a6e, "HP EDNA 360", ALC287_FIXUP_CS35L41_I2C_4), SND_PCI_QUIRK(0x103c, 0x8a74, "HP ProBook 440 G8 Notebook PC", ALC236_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8a78, "HP Dev One", ALC285_FIXUP_HP_LIMIT_INT_MIC_BOOST), -- 2.50.1

1 month, 2 weeks

2
1
0 0

[PATCH] cxl/region: Fix potential double free of region device in delete_region_store

by Ma Ke

cxl_find_region_by_name() uses device_find_child_by_name() to locate a region device by name. This function implicitly increments the device's reference count before returning the pointer by calling device_find_child(). However, in delete_region_store(), after calling devm_release_action() which synchronously executes unregister_region(), an additional explicit put_device() is invoked. The unregister_region() callback already contains a put_device() call to decrement the reference count. This results in two consecutive decrements of the same device's reference count. First decrement occurs in unregister_region() via its put_device() call. Second decrement occurs in delete_region_store() via the explicit put_device(). We should remove the additional put_device(). As comment of device_find_child() says, 'NOTE: you will need to drop the reference with put_device() after use'. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 779dd20cfb56 ("cxl/region: Add region creation support") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/cxl/core/region.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c index 6e5e1460068d..eacf726cf463 100644 --- a/drivers/cxl/core/region.c +++ b/drivers/cxl/core/region.c @@ -2672,7 +2672,6 @@ static ssize_t delete_region_store(struct device *dev, return PTR_ERR(cxlr); devm_release_action(port->uport_dev, unregister_region, cxlr); - put_device(&cxlr->dev); return len; } -- 2.25.1

1 month, 2 weeks

2
1
0 0

[PATCH] crypto: qat - flush misc workqueue during device shutdown

by Giovanni Cabiddu

Repeated loading and unloading of a device specific QAT driver, for example qat_4xxx, in a tight loop can lead to a crash due to a use-after-free scenario. This occurs when a power management (PM) interrupt triggers just before the device-specific driver (e.g., qat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remains loaded. Since the driver uses a shared workqueue (`qat_misc_wq`) across all devices and owned by intel_qat.ko, a deferred routine from the device-specific driver may still be pending in the queue. If this routine executes after the driver is unloaded, it can dereference freed memory, resulting in a page fault and kernel crash like the following: BUG: unable to handle page fault for address: ffa000002e50a01c #PF: supervisor read access in kernel mode RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat] Call Trace: pm_bh_handler+0x1d2/0x250 [intel_qat] process_one_work+0x171/0x340 worker_thread+0x277/0x3a0 kthread+0xf0/0x120 ret_from_fork+0x2d/0x50 To prevent this, flush the misc workqueue during device shutdown to ensure that all pending work items are completed before the driver is unloaded. Note: This approach may slightly increase shutdown latency if the workqueue contains jobs from other devices, but it ensures correctness and stability. Fixes: e5745f34113b ("crypto: qat - enable power management for QAT GEN4") Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu(a)intel.com> Cc: stable(a)vger.kernel.org Reviewed-by: Ahsan Atta <ahsan.atta(a)intel.com> --- drivers/crypto/intel/qat/qat_common/adf_common_drv.h | 1 + drivers/crypto/intel/qat/qat_common/adf_init.c | 1 + drivers/crypto/intel/qat/qat_common/adf_isr.c | 5 +++++ 3 files changed, 7 insertions(+) diff --git a/drivers/crypto/intel/qat/qat_common/adf_common_drv.h b/drivers/crypto/intel/qat/qat_common/adf_common_drv.h index eaa6388a6678..7a022bd4ae07 100644 --- a/drivers/crypto/intel/qat/qat_common/adf_common_drv.h +++ b/drivers/crypto/intel/qat/qat_common/adf_common_drv.h @@ -189,6 +189,7 @@ void adf_exit_misc_wq(void); bool adf_misc_wq_queue_work(struct work_struct *work); bool adf_misc_wq_queue_delayed_work(struct delayed_work *work, unsigned long delay); +void adf_misc_wq_flush(void); #if defined(CONFIG_PCI_IOV) int adf_sriov_configure(struct pci_dev *pdev, int numvfs); void adf_disable_sriov(struct adf_accel_dev *accel_dev); diff --git a/drivers/crypto/intel/qat/qat_common/adf_init.c b/drivers/crypto/intel/qat/qat_common/adf_init.c index f189cce7d153..46491048e0bb 100644 --- a/drivers/crypto/intel/qat/qat_common/adf_init.c +++ b/drivers/crypto/intel/qat/qat_common/adf_init.c @@ -404,6 +404,7 @@ static void adf_dev_shutdown(struct adf_accel_dev *accel_dev) hw_data->exit_admin_comms(accel_dev); adf_cleanup_etr_data(accel_dev); + adf_misc_wq_flush(); adf_dev_restore(accel_dev); } diff --git a/drivers/crypto/intel/qat/qat_common/adf_isr.c b/drivers/crypto/intel/qat/qat_common/adf_isr.c index cae1aee5479a..12e565613661 100644 --- a/drivers/crypto/intel/qat/qat_common/adf_isr.c +++ b/drivers/crypto/intel/qat/qat_common/adf_isr.c @@ -407,3 +407,8 @@ bool adf_misc_wq_queue_delayed_work(struct delayed_work *work, { return queue_delayed_work(adf_misc_wq, work, delay); } + +void adf_misc_wq_flush(void) +{ + flush_workqueue(adf_misc_wq); +} base-commit: 9d21467fca15472efb701dad69abf685195845a4 -- 2.50.0

1 month, 2 weeks

2
1
0 0

[PATCH] crypto: acomp - Fix CFI failure due to type punning

by Eric Biggers

To avoid a crash when control flow integrity is enabled, make the workspace ("stream") free function use a consistent type, and call it through a function pointer that has that same type. Fixes: 42d9f6c77479 ("crypto: acomp - Move scomp stream allocation code into acomp") Cc: stable(a)vger.kernel.org Signed-off-by: Eric Biggers <ebiggers(a)kernel.org> --- crypto/deflate.c | 7 ++++++- crypto/zstd.c | 7 ++++++- include/crypto/internal/acompress.h | 5 +---- 3 files changed, 13 insertions(+), 6 deletions(-) diff --git a/crypto/deflate.c b/crypto/deflate.c index fe8e4ad0fee10..21404515dc77e 100644 --- a/crypto/deflate.c +++ b/crypto/deflate.c @@ -46,13 +46,18 @@ static void *deflate_alloc_stream(void) ctx->stream.workspace = ctx->workspace; return ctx; } +static void deflate_free_stream(void *ctx) +{ + kvfree(ctx); +} + static struct crypto_acomp_streams deflate_streams = { .alloc_ctx = deflate_alloc_stream, - .cfree_ctx = kvfree, + .free_ctx = deflate_free_stream, }; static int deflate_compress_one(struct acomp_req *req, struct deflate_stream *ds) { diff --git a/crypto/zstd.c b/crypto/zstd.c index 657e0cf7b9524..ff5f596a4ea7e 100644 --- a/crypto/zstd.c +++ b/crypto/zstd.c @@ -52,13 +52,18 @@ static void *zstd_alloc_stream(void) ctx->wksp_size = wksp_size; return ctx; } +static void zstd_free_stream(void *ctx) +{ + kvfree(ctx); +} + static struct crypto_acomp_streams zstd_streams = { .alloc_ctx = zstd_alloc_stream, - .cfree_ctx = kvfree, + .free_ctx = zstd_free_stream, }; static int zstd_init(struct crypto_acomp *acomp_tfm) { int ret = 0; diff --git a/include/crypto/internal/acompress.h b/include/crypto/internal/acompress.h index ffffd88bbbad3..2d97440028ffd 100644 --- a/include/crypto/internal/acompress.h +++ b/include/crypto/internal/acompress.h @@ -61,14 +61,11 @@ struct crypto_acomp_stream { }; struct crypto_acomp_streams { /* These must come first because of struct scomp_alg. */ void *(*alloc_ctx)(void); - union { - void (*free_ctx)(void *); - void (*cfree_ctx)(const void *); - }; + void (*free_ctx)(void *); struct crypto_acomp_stream __percpu *streams; struct work_struct stream_work; cpumask_t stream_want; }; base-commit: 181698af38d3f93381229ad89c09b5bd0496661a -- 2.50.1

1 month, 2 weeks

3
2
0 0

[PATCH] rv: Ensure containers are registered first

by Nam Cao

If rv_register_monitor() is called with a non-NULL parent pointer (i.e. by monitors inside a container), it is expected that the parent (a.k.a container) is already registered. The containers seem to always be registered first. I suspect because of the order in Makefile. But nothing guarantees this. If this registering order is changed, "strange" things happen. For example, if the container is registered last, rv_is_container_monitor() incorrectly says this is NOT a container. .enable() is then called, which is NULL for container, thus we have a NULL pointer deref crash. Guarantee that containers are registered first. Fixes: cb85c660fcd4 ("rv: Add option for nested monitors and include sched") Signed-off-by: Nam Cao <namcao(a)linutronix.de> Cc: stable(a)vger.kernel.org --- include/linux/rv.h | 5 +++++ kernel/trace/rv/monitors/pagefault/pagefault.c | 4 ++-- kernel/trace/rv/monitors/rtapp/rtapp.c | 4 ++-- kernel/trace/rv/monitors/sched/sched.c | 4 ++-- kernel/trace/rv/monitors/sco/sco.c | 4 ++-- kernel/trace/rv/monitors/scpd/scpd.c | 4 ++-- kernel/trace/rv/monitors/sleep/sleep.c | 4 ++-- kernel/trace/rv/monitors/sncid/sncid.c | 4 ++-- kernel/trace/rv/monitors/snep/snep.c | 4 ++-- kernel/trace/rv/monitors/snroc/snroc.c | 4 ++-- kernel/trace/rv/monitors/tss/tss.c | 4 ++-- kernel/trace/rv/monitors/wip/wip.c | 4 ++-- kernel/trace/rv/monitors/wwnr/wwnr.c | 4 ++-- tools/verification/rvgen/rvgen/templates/container/main.c | 4 ++-- tools/verification/rvgen/rvgen/templates/dot2k/main.c | 4 ++-- tools/verification/rvgen/rvgen/templates/ltl2k/main.c | 4 ++-- 16 files changed, 35 insertions(+), 30 deletions(-) diff --git a/include/linux/rv.h b/include/linux/rv.h index 97baf58d88b2..094c9f62389c 100644 --- a/include/linux/rv.h +++ b/include/linux/rv.h @@ -119,5 +119,10 @@ static inline bool rv_reacting_on(void) } #endif /* CONFIG_RV_REACTORS */ +#define rv_container_init device_initcall +#define rv_container_exit __exitcall +#define rv_monitor_init late_initcall +#define rv_monitor_exit __exitcall + #endif /* CONFIG_RV */ #endif /* _LINUX_RV_H */ diff --git a/kernel/trace/rv/monitors/pagefault/pagefault.c b/kernel/trace/rv/monitors/pagefault/pagefault.c index 9fe6123b2200..2b226d27ddff 100644 --- a/kernel/trace/rv/monitors/pagefault/pagefault.c +++ b/kernel/trace/rv/monitors/pagefault/pagefault.c @@ -80,8 +80,8 @@ static void __exit unregister_pagefault(void) rv_unregister_monitor(&rv_pagefault); } -module_init(register_pagefault); -module_exit(unregister_pagefault); +rv_monitor_init(register_pagefault); +rv_monitor_exit(unregister_pagefault); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Nam Cao <namcao(a)linutronix.de>"); diff --git a/kernel/trace/rv/monitors/rtapp/rtapp.c b/kernel/trace/rv/monitors/rtapp/rtapp.c index fd75fc927d65..b078327e71bf 100644 --- a/kernel/trace/rv/monitors/rtapp/rtapp.c +++ b/kernel/trace/rv/monitors/rtapp/rtapp.c @@ -25,8 +25,8 @@ static void __exit unregister_rtapp(void) rv_unregister_monitor(&rv_rtapp); } -module_init(register_rtapp); -module_exit(unregister_rtapp); +rv_container_init(register_rtapp); +rv_container_exit(unregister_rtapp); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Nam Cao <namcao(a)linutronix.de>"); diff --git a/kernel/trace/rv/monitors/sched/sched.c b/kernel/trace/rv/monitors/sched/sched.c index 905e03c3c934..e89e193bd8e0 100644 --- a/kernel/trace/rv/monitors/sched/sched.c +++ b/kernel/trace/rv/monitors/sched/sched.c @@ -30,8 +30,8 @@ static void __exit unregister_sched(void) rv_unregister_monitor(&rv_sched); } -module_init(register_sched); -module_exit(unregister_sched); +rv_container_init(register_sched); +rv_container_exit(unregister_sched); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Gabriele Monaco <gmonaco(a)redhat.com>"); diff --git a/kernel/trace/rv/monitors/sco/sco.c b/kernel/trace/rv/monitors/sco/sco.c index 4cff59220bfc..b96e09e64a2f 100644 --- a/kernel/trace/rv/monitors/sco/sco.c +++ b/kernel/trace/rv/monitors/sco/sco.c @@ -80,8 +80,8 @@ static void __exit unregister_sco(void) rv_unregister_monitor(&rv_sco); } -module_init(register_sco); -module_exit(unregister_sco); +rv_monitor_init(register_sco); +rv_monitor_exit(unregister_sco); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Gabriele Monaco <gmonaco(a)redhat.com>"); diff --git a/kernel/trace/rv/monitors/scpd/scpd.c b/kernel/trace/rv/monitors/scpd/scpd.c index cbdd6a5f8d7f..a4c8e78fa768 100644 --- a/kernel/trace/rv/monitors/scpd/scpd.c +++ b/kernel/trace/rv/monitors/scpd/scpd.c @@ -88,8 +88,8 @@ static void __exit unregister_scpd(void) rv_unregister_monitor(&rv_scpd); } -module_init(register_scpd); -module_exit(unregister_scpd); +rv_monitor_init(register_scpd); +rv_monitor_exit(unregister_scpd); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Gabriele Monaco <gmonaco(a)redhat.com>"); diff --git a/kernel/trace/rv/monitors/sleep/sleep.c b/kernel/trace/rv/monitors/sleep/sleep.c index eea447b06907..6980f8de725d 100644 --- a/kernel/trace/rv/monitors/sleep/sleep.c +++ b/kernel/trace/rv/monitors/sleep/sleep.c @@ -229,8 +229,8 @@ static void __exit unregister_sleep(void) rv_unregister_monitor(&rv_sleep); } -module_init(register_sleep); -module_exit(unregister_sleep); +rv_monitor_init(register_sleep); +rv_monitor_exit(unregister_sleep); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Nam Cao <namcao(a)linutronix.de>"); diff --git a/kernel/trace/rv/monitors/sncid/sncid.c b/kernel/trace/rv/monitors/sncid/sncid.c index f5037cd6214c..97a126c6083a 100644 --- a/kernel/trace/rv/monitors/sncid/sncid.c +++ b/kernel/trace/rv/monitors/sncid/sncid.c @@ -88,8 +88,8 @@ static void __exit unregister_sncid(void) rv_unregister_monitor(&rv_sncid); } -module_init(register_sncid); -module_exit(unregister_sncid); +rv_monitor_init(register_sncid); +rv_monitor_exit(unregister_sncid); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Gabriele Monaco <gmonaco(a)redhat.com>"); diff --git a/kernel/trace/rv/monitors/snep/snep.c b/kernel/trace/rv/monitors/snep/snep.c index 0076ba6d7ea4..376a856ebffa 100644 --- a/kernel/trace/rv/monitors/snep/snep.c +++ b/kernel/trace/rv/monitors/snep/snep.c @@ -88,8 +88,8 @@ static void __exit unregister_snep(void) rv_unregister_monitor(&rv_snep); } -module_init(register_snep); -module_exit(unregister_snep); +rv_monitor_init(register_snep); +rv_monitor_exit(unregister_snep); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Gabriele Monaco <gmonaco(a)redhat.com>"); diff --git a/kernel/trace/rv/monitors/snroc/snroc.c b/kernel/trace/rv/monitors/snroc/snroc.c index bb1f60d55296..e4439605b4b6 100644 --- a/kernel/trace/rv/monitors/snroc/snroc.c +++ b/kernel/trace/rv/monitors/snroc/snroc.c @@ -77,8 +77,8 @@ static void __exit unregister_snroc(void) rv_unregister_monitor(&rv_snroc); } -module_init(register_snroc); -module_exit(unregister_snroc); +rv_monitor_init(register_snroc); +rv_monitor_exit(unregister_snroc); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Gabriele Monaco <gmonaco(a)redhat.com>"); diff --git a/kernel/trace/rv/monitors/tss/tss.c b/kernel/trace/rv/monitors/tss/tss.c index 542787e6524f..8f960c9fe0ff 100644 --- a/kernel/trace/rv/monitors/tss/tss.c +++ b/kernel/trace/rv/monitors/tss/tss.c @@ -83,8 +83,8 @@ static void __exit unregister_tss(void) rv_unregister_monitor(&rv_tss); } -module_init(register_tss); -module_exit(unregister_tss); +rv_monitor_init(register_tss); +rv_monitor_exit(unregister_tss); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Gabriele Monaco <gmonaco(a)redhat.com>"); diff --git a/kernel/trace/rv/monitors/wip/wip.c b/kernel/trace/rv/monitors/wip/wip.c index ed758fec8608..5c39c6074bd3 100644 --- a/kernel/trace/rv/monitors/wip/wip.c +++ b/kernel/trace/rv/monitors/wip/wip.c @@ -80,8 +80,8 @@ static void __exit unregister_wip(void) rv_unregister_monitor(&rv_wip); } -module_init(register_wip); -module_exit(unregister_wip); +rv_monitor_init(register_wip); +rv_monitor_exit(unregister_wip); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Daniel Bristot de Oliveira <bristot(a)kernel.org>"); diff --git a/kernel/trace/rv/monitors/wwnr/wwnr.c b/kernel/trace/rv/monitors/wwnr/wwnr.c index 172f31c4b0f3..ec671546f571 100644 --- a/kernel/trace/rv/monitors/wwnr/wwnr.c +++ b/kernel/trace/rv/monitors/wwnr/wwnr.c @@ -79,8 +79,8 @@ static void __exit unregister_wwnr(void) rv_unregister_monitor(&rv_wwnr); } -module_init(register_wwnr); -module_exit(unregister_wwnr); +rv_monitor_init(register_wwnr); +rv_monitor_exit(unregister_wwnr); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Daniel Bristot de Oliveira <bristot(a)kernel.org>"); diff --git a/tools/verification/rvgen/rvgen/templates/container/main.c b/tools/verification/rvgen/rvgen/templates/container/main.c index 89fc17cf8958..5820c9705d0f 100644 --- a/tools/verification/rvgen/rvgen/templates/container/main.c +++ b/tools/verification/rvgen/rvgen/templates/container/main.c @@ -30,8 +30,8 @@ static void __exit unregister_%%MODEL_NAME%%(void) rv_unregister_monitor(&rv_%%MODEL_NAME%%); } -module_init(register_%%MODEL_NAME%%); -module_exit(unregister_%%MODEL_NAME%%); +rv_container_init(register_%%MODEL_NAME%%); +rv_container_exit(unregister_%%MODEL_NAME%%); MODULE_LICENSE("GPL"); MODULE_AUTHOR("dot2k: auto-generated"); diff --git a/tools/verification/rvgen/rvgen/templates/dot2k/main.c b/tools/verification/rvgen/rvgen/templates/dot2k/main.c index 83044a20c89a..d6bd248aba9c 100644 --- a/tools/verification/rvgen/rvgen/templates/dot2k/main.c +++ b/tools/verification/rvgen/rvgen/templates/dot2k/main.c @@ -83,8 +83,8 @@ static void __exit unregister_%%MODEL_NAME%%(void) rv_unregister_monitor(&rv_%%MODEL_NAME%%); } -module_init(register_%%MODEL_NAME%%); -module_exit(unregister_%%MODEL_NAME%%); +rv_monitor_init(register_%%MODEL_NAME%%); +rv_monitor_exit(unregister_%%MODEL_NAME%%); MODULE_LICENSE("GPL"); MODULE_AUTHOR("dot2k: auto-generated"); diff --git a/tools/verification/rvgen/rvgen/templates/ltl2k/main.c b/tools/verification/rvgen/rvgen/templates/ltl2k/main.c index f85d076fbf78..2069a7a0f1ae 100644 --- a/tools/verification/rvgen/rvgen/templates/ltl2k/main.c +++ b/tools/verification/rvgen/rvgen/templates/ltl2k/main.c @@ -94,8 +94,8 @@ static void __exit unregister_%%MODEL_NAME%%(void) rv_unregister_monitor(&rv_%%MODEL_NAME%%); } -module_init(register_%%MODEL_NAME%%); -module_exit(unregister_%%MODEL_NAME%%); +rv_monitor_init(register_%%MODEL_NAME%%); +rv_monitor_exit(unregister_%%MODEL_NAME%%); MODULE_LICENSE("GPL"); MODULE_AUTHOR(/* TODO */); -- 2.39.5

1 month, 2 weeks

3
3
0 0

Re: [PATCH] misc: rtsx: usb: Ensure mmc child device is active when card is present

by Gwendal Grignou

> --- > drivers/misc/cardreader/rtsx_usb.c | 16 +++++++++------- > 1 file changed, 9 insertions(+), 7 deletions(-) > > diff --git a/drivers/misc/cardreader/rtsx_usb.c b/drivers/misc/cardreader/rtsx_usb.c > index 148107a4547c..d007a4455ce5 100644 > --- a/drivers/misc/cardreader/rtsx_usb.c > +++ b/drivers/misc/cardreader/rtsx_usb.c > @@ -698,6 +698,12 @@ static void rtsx_usb_disconnect(struct usb_interface *intf) > } > > #ifdef CONFIG_PM > +static int rtsx_usb_resume_child(struct device *dev, void *data) > +{ > + pm_request_resume(dev); > + return 0; > +} > + > static int rtsx_usb_suspend(struct usb_interface *intf, pm_message_t message) > { > struct rtsx_ucr *ucr = > @@ -713,8 +719,10 @@ static int rtsx_usb_suspend(struct usb_interface *intf, pm_message_t message) > mutex_unlock(&ucr->dev_mutex); > > /* Defer the autosuspend if card exists */ > - if (val & (SD_CD | MS_CD)) > + if (val & (SD_CD | MS_CD)) { > + device_for_each_child(&intf->dev, NULL, rtsx_usb_resume_child); Why not calling rtsx_usb_resume() here? > return -EAGAIN; > + } > } else { > /* There is an ongoing operation*/ > return -EAGAIN; > @@ -724,12 +732,6 @@ static int rtsx_usb_suspend(struct usb_interface *intf, pm_message_t message) > return 0; > } > > -static int rtsx_usb_resume_child(struct device *dev, void *data) > -{ > - pm_request_resume(dev); > - return 0; > -} > - > static int rtsx_usb_resume(struct usb_interface *intf) > { > device_for_each_child(&intf->dev, NULL, rtsx_usb_resume_child); > -- > 2.25.1 >

1 month, 2 weeks

2
1
0 0

[PATCH v2] media: lirc: Fix error handling in lirc_register()

by Ma Ke

When cdev_device_add() failed, calling put_device() to explicitly release dev->lirc_dev. Otherwise, it could cause the fault of the reference count. Found by code review. Cc: stable(a)vger.kernel.org Fixes: a6ddd4fecbb0 ("media: lirc: remove last remnants of lirc kapi") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- Changes in v2: - move get_device() before cdev_device_add() to adjust the timing of parent device reference. --- drivers/media/rc/lirc_dev.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c index a2257dc2f25d..7d4942925993 100644 --- a/drivers/media/rc/lirc_dev.c +++ b/drivers/media/rc/lirc_dev.c @@ -736,11 +736,11 @@ int lirc_register(struct rc_dev *dev) cdev_init(&dev->lirc_cdev, &lirc_fops); + get_device(&dev->dev); + err = cdev_device_add(&dev->lirc_cdev, &dev->lirc_dev); if (err) - goto out_ida; - - get_device(&dev->dev); + goto out_put_device; switch (dev->driver_type) { case RC_DRIVER_SCANCODE: @@ -764,7 +764,8 @@ int lirc_register(struct rc_dev *dev) return 0; -out_ida: +out_put_device: + put_device(&dev->lirc_dev); ida_free(&lirc_ida, minor); return err; } -- 2.25.1

1 month, 2 weeks

1
0
0 0

[PATCH v2 RESEND] sparc: fix error handling in scan_one_device()

by Ma Ke

Once of_device_register() failed, we should call put_device() to decrement reference count for cleanup. Or it could cause memory leak. So fix this by calling put_device(), then the name can be freed in kobject_cleanup(). Calling path: of_device_register() -> of_device_add() -> device_add(). As comment of device_add() says, 'if device_add() succeeds, you should call device_del() when you want to get rid of it. If device_add() has not succeeded, use only put_device() to drop the reference count'. Found by code review. Cc: stable(a)vger.kernel.org Fixes: cf44bbc26cf1 ("[SPARC]: Beginnings of generic of_device framework.") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- Changes in v2: - retained kfree() manually due to the lack of a release callback function. --- arch/sparc/kernel/of_device_64.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/sparc/kernel/of_device_64.c b/arch/sparc/kernel/of_device_64.c index f98c2901f335..f53092b07b9e 100644 --- a/arch/sparc/kernel/of_device_64.c +++ b/arch/sparc/kernel/of_device_64.c @@ -677,6 +677,7 @@ static struct platform_device * __init scan_one_device(struct device_node *dp, if (of_device_register(op)) { printk("%pOF: Could not register of device.\n", dp); + put_device(&op->dev); kfree(op); op = NULL; } -- 2.25.1

1 month, 2 weeks

1
0
0 0

[PATCH RESEND] fsi/core: fix error handling in fsi_slave_init()

by Ma Ke

Once cdev_device_add() failed, we should use put_device() to decrement reference count for cleanup. Or it could cause memory leak. Although operations in err_free_ida are similar to the operations in callback function fsi_slave_release(), put_device() is a correct handling operation as comments require when cdev_device_add() fails. As comment of device_add() says, 'if device_add() succeeds, you should call device_del() when you want to get rid of it. If device_add() has not succeeded, use only put_device() to drop the reference count'. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 371975b0b075 ("fsi/core: Fix error paths on CFAM init") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/fsi/fsi-core.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c index 50e8736039fe..c494fc0bd747 100644 --- a/drivers/fsi/fsi-core.c +++ b/drivers/fsi/fsi-core.c @@ -1084,7 +1084,8 @@ static int fsi_slave_init(struct fsi_master *master, int link, uint8_t id) rc = cdev_device_add(&slave->cdev, &slave->dev); if (rc) { dev_err(&slave->dev, "Error %d creating slave device\n", rc); - goto err_free_ida; + put_device(&slave->dev); + return rc; } /* Now that we have the cdev registered with the core, any fatal @@ -1110,8 +1111,6 @@ static int fsi_slave_init(struct fsi_master *master, int link, uint8_t id) return 0; -err_free_ida: - fsi_free_minor(slave->dev.devt); err_free: of_node_put(slave->dev.of_node); kfree(slave); -- 2.25.1

1 month, 2 weeks

1
0
0 0

[PATCH 2/2] eventpoll: Fix epoll_wait() report false negative

by Nam Cao

ep_events_available() checks for available events by looking at ep->rdllist and ep->ovflist. However, this is done without a lock, therefore the returned value is not reliable. Because it is possible that both checks on ep->rdllist and ep->ovflist are false while ep_start_scan() or ep_done_scan() is being executed on other CPUs, despite events are available. This bug can be observed by: 1. Create an eventpoll with at least one ready level-triggered event 2. Create multiple threads who do epoll_wait() with zero timeout. The threads do not consume the events, therefore all epoll_wait() should return at least one event. If one thread is executing ep_events_available() while another thread is executing ep_start_scan() or ep_done_scan(), epoll_wait() may wrongly return no event for the former thread. This reproducer is implemented as TEST(epoll65) in tools/testing/selftests/filesystems/epoll/epoll_wakeup_test.c Fix it by skipping ep_events_available(), just call ep_try_send_events() directly. epoll_sendevents() (io_uring) suffers the same problem, fix that as well. There is still ep_busy_loop() who uses ep_events_available() without lock, but it is probably okay (?) for busy-polling. Fixes: c5a282e9635e ("fs/epoll: reduce the scope of wq lock in epoll_wait()") Fixes: e59d3c64cba6 ("epoll: eliminate unnecessary lock for zero timeout") Fixes: ae3a4f1fdc2c ("eventpoll: add epoll_sendevents() helper") Signed-off-by: Nam Cao <namcao(a)linutronix.de> Cc: stable(a)vger.kernel.org --- fs/eventpoll.c | 16 ++-------------- 1 file changed, 2 insertions(+), 14 deletions(-) diff --git a/fs/eventpoll.c b/fs/eventpoll.c index 0fbf5dfedb24..541481eafc20 100644 --- a/fs/eventpoll.c +++ b/fs/eventpoll.c @@ -2022,7 +2022,7 @@ static int ep_schedule_timeout(ktime_t *to) static int ep_poll(struct eventpoll *ep, struct epoll_event __user *events, int maxevents, struct timespec64 *timeout) { - int res, eavail, timed_out = 0; + int res, eavail = 1, timed_out = 0; u64 slack = 0; wait_queue_entry_t wait; ktime_t expires, *to = NULL; @@ -2041,16 +2041,6 @@ static int ep_poll(struct eventpoll *ep, struct epoll_event __user *events, timed_out = 1; } - /* - * This call is racy: We may or may not see events that are being added - * to the ready list under the lock (e.g., in IRQ callbacks). For cases - * with a non-zero timeout, this thread will check the ready list under - * lock and will add to the wait queue. For cases with a zero - * timeout, the user by definition should not care and will have to - * recheck again. - */ - eavail = ep_events_available(ep); - while (1) { if (eavail) { res = ep_try_send_events(ep, events, maxevents); @@ -2496,9 +2486,7 @@ int epoll_sendevents(struct file *file, struct epoll_event __user *events, * Racy call, but that's ok - it should get retried based on * poll readiness anyway. */ - if (ep_events_available(ep)) - return ep_try_send_events(ep, events, maxevents); - return 0; + return ep_try_send_events(ep, events, maxevents); } /* -- 2.39.5

1 month, 2 weeks

2
2
0 0

[PATCH] vhost/net: Replace wait_queue with completion in ubufs reference

by Nikolay Kuratov

When operating on struct vhost_net_ubuf_ref, the following execution sequence is theoretically possible: CPU0 is finalizing DMA operation CPU1 is doing VHOST_NET_SET_BACKEND // &ubufs->refcount == 2 vhost_net_ubuf_put() vhost_net_ubuf_put_wait_and_free(oldubufs) vhost_net_ubuf_put_and_wait() vhost_net_ubuf_put() int r = atomic_sub_return(1, &ubufs->refcount); // r = 1 int r = atomic_sub_return(1, &ubufs->refcount); // r = 0 wait_event(ubufs->wait, !atomic_read(&ubufs->refcount)); // no wait occurs here because condition is already true kfree(ubufs); if (unlikely(!r)) wake_up(&ubufs->wait); // use-after-free This leads to use-after-free on ubufs access. This happens because CPU1 skips waiting for wake_up() when refcount is already zero. To prevent that use a completion instead of wait_queue as the ubufs notification mechanism. wait_for_completion() guarantees that there will be complete() call prior to its return. We also need to reinit completion because refcnt == 0 does not mean freeing in case of vhost_net_flush() - it then sets refcnt back to 1. AFAIK concurrent calls to vhost_net_ubuf_put_and_wait() with the same ubufs object aren't possible since those calls (through vhost_net_flush() or vhost_net_set_backend()) are protected by the device mutex. So reinit_completion() right after wait_for_completion() should be fine. Cc: stable(a)vger.kernel.org Fixes: 0ad8b480d6ee9 ("vhost: fix ref cnt checking deadlock") Reported-by: Andrey Ryabinin <arbn(a)yandex-team.com> Suggested-by: Andrey Smetanin <asmetanin(a)yandex-team.ru> Signed-off-by: Nikolay Kuratov <kniv(a)yandex-team.ru> --- drivers/vhost/net.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index 7cbfc7d718b3..454d179fffeb 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c @@ -94,7 +94,7 @@ struct vhost_net_ubuf_ref { * >1: outstanding ubufs */ atomic_t refcount; - wait_queue_head_t wait; + struct completion wait; struct vhost_virtqueue *vq; }; @@ -240,7 +240,7 @@ vhost_net_ubuf_alloc(struct vhost_virtqueue *vq, bool zcopy) if (!ubufs) return ERR_PTR(-ENOMEM); atomic_set(&ubufs->refcount, 1); - init_waitqueue_head(&ubufs->wait); + init_completion(&ubufs->wait); ubufs->vq = vq; return ubufs; } @@ -249,14 +249,15 @@ static int vhost_net_ubuf_put(struct vhost_net_ubuf_ref *ubufs) { int r = atomic_sub_return(1, &ubufs->refcount); if (unlikely(!r)) - wake_up(&ubufs->wait); + complete_all(&ubufs->wait); return r; } static void vhost_net_ubuf_put_and_wait(struct vhost_net_ubuf_ref *ubufs) { vhost_net_ubuf_put(ubufs); - wait_event(ubufs->wait, !atomic_read(&ubufs->refcount)); + wait_for_completion(&ubufs->wait); + reinit_completion(&ubufs->wait); } static void vhost_net_ubuf_put_wait_and_free(struct vhost_net_ubuf_ref *ubufs) -- 2.34.1

1 month, 2 weeks

2
1
0 0

Re: [PATCH bpf-next v5 2/2] selftests/bpf: Add tests with stack ptr register in conditional jmp

by Shung-Hsi Yu

Hi Andrii and Yonghong, On Fri, May 23, 2025 at 09:13:40PM -0700, Yonghong Song wrote: > Add two tests: > - one test has 'rX <op> r10' where rX is not r10, and > - another test has 'rX <op> rY' where rX and rY are not r10 > but there is an early insn 'rX = r10'. > > Without previous verifier change, both tests will fail. > > Signed-off-by: Yonghong Song <yonghong.song(a)linux.dev> > --- > .../selftests/bpf/progs/verifier_precision.c | 53 +++++++++++++++++++ > 1 file changed, 53 insertions(+) I was looking this commit (5ffb537e416e) since it was a BPF selftest test for CVE-2025-38279, but upon looking I found that the commit differs from the patch, there is an extra hunk that changed kernel/bpf/verifier.c that wasn't found the Yonghong's original patch. I suppose it was meant to be squashed into the previous commit e2d2115e56c4 "bpf: Do not include stack ptr register in precision backtracking bookkeeping"? Since stable backports got only e2d2115e56c4, but not the 5ffb537e416e here with the extra change for kernel/bpf/verifier.c, I'd guess the backtracking logic in the stable kernel isn't correct at the moment, so I'll send 5ffb537e416e "selftests/bpf: Add tests with stack ptr register in conditional jmp" to stable as well. Let me know if that's not the right thing to do. Shung-Hsi diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 98c52829936e..a7d6e0c5928b 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -16456,6 +16456,8 @@ static int check_cond_jmp_op(struct bpf_verifier_env *env, if (src_reg->type == PTR_TO_STACK) insn_flags |= INSN_F_SRC_REG_STACK; + if (dst_reg->type == PTR_TO_STACK) + insn_flags |= INSN_F_DST_REG_STACK; } else { if (insn->src_reg != BPF_REG_0) { verbose(env, "BPF_JMP/JMP32 uses reserved fields\n"); @@ -16465,10 +16467,11 @@ static int check_cond_jmp_op(struct bpf_verifier_env *env, memset(src_reg, 0, sizeof(*src_reg)); src_reg->type = SCALAR_VALUE; __mark_reg_known(src_reg, insn->imm); + + if (dst_reg->type == PTR_TO_STACK) + insn_flags |= INSN_F_DST_REG_STACK; } - if (dst_reg->type == PTR_TO_STACK) - insn_flags |= INSN_F_DST_REG_STACK; if (insn_flags) { err = push_insn_history(env, this_branch, insn_flags, 0); if (err) > diff --git a/tools/testing/selftests/bpf/progs/verifier_precision.c b/tools/testing/selftests/bpf/progs/verifier_precision.c ...

1 month, 2 weeks

2
2
0 0

[PATCH] cifs: reset iface weights when we cannot find a candidate

by nspmangalore＠gmail.com

From: Shyam Prasad N <sprasad(a)microsoft.com> We now do a weighted selection of server interfaces when allocating new channels. The weights are decided based on the speed advertised. The fulfilled weight for an interface is a counter that is used to track the interface selection. It should be reset back to zero once all interfaces fulfilling their weight. In cifs_chan_update_iface, this reset logic was missing. As a result when the server interface list changes, the client may not be able to find a new candidate for other channels after all interfaces have been fulfilled. Fixes: a6d8fb54a515 ("cifs: distribute channels across interfaces based on speed") Cc: <stable(a)vger.kernel.org> Signed-off-by: Shyam Prasad N <sprasad(a)microsoft.com> --- fs/smb/client/sess.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/fs/smb/client/sess.c b/fs/smb/client/sess.c index 330bc3d25bad..0a8c2fcc9ded 100644 --- a/fs/smb/client/sess.c +++ b/fs/smb/client/sess.c @@ -332,6 +332,7 @@ cifs_chan_update_iface(struct cifs_ses *ses, struct TCP_Server_Info *server) struct cifs_server_iface *old_iface = NULL; struct cifs_server_iface *last_iface = NULL; struct sockaddr_storage ss; + int retry = 0; spin_lock(&ses->chan_lock); chan_index = cifs_ses_get_chan_index(ses, server); @@ -360,6 +361,7 @@ cifs_chan_update_iface(struct cifs_ses *ses, struct TCP_Server_Info *server) return; } +try_again: last_iface = list_last_entry(&ses->iface_list, struct cifs_server_iface, iface_head); iface_min_speed = last_iface->speed; @@ -397,6 +399,13 @@ cifs_chan_update_iface(struct cifs_ses *ses, struct TCP_Server_Info *server) } if (list_entry_is_head(iface, &ses->iface_list, iface_head)) { + list_for_each_entry(iface, &ses->iface_list, iface_head) + iface->weight_fulfilled = 0; + + /* see if it can be satisfied in second attempt */ + if (!retry++) + goto try_again; + iface = NULL; cifs_dbg(FYI, "unable to find a suitable iface\n"); } -- 2.43.0

1 month, 2 weeks

2
1
0 0

[PATCH 5.4.y 0/6] Backport few sch_sfq fixes

by Harshit Mogalapalli

commit: 10685681bafc ("net_sched: sch_sfq: don't allow 1 packet limit") fixes CVE-2024-57996 and commit: b3bf8f63e617 ("net_sched: sch_sfq: move the limit validation") fixes CVE-2025-37752 and commit: 7ca52541c05c ("net_sched: sch_sfq: reject invalid perturb period") fixes CVE-2025-38193. Patches 3, 5, 6 are CVE fixes for above mentioned CVEs. Patch 1,2 and 4 are pulled in as stable-deps. Testing performed on the patched 5.4.295 kernel with the above 5 patches: (Used latest upstream kselftests for tc-testing) $ uname -a Linux hamogala-kdevoci8-1 5.4.295-master.20250717.el8.rc2.x86_64 #1 SMP Thu Jul 17 00:57:21 PDT 2025 x86_64 x86_64 x86_64 GNU/Linux $ python3.12 ./tdc.py -f tc-tests/qdiscs/sfq.json -- ns/SubPlugin.__init__ Test 7482: Create SFQ with default setting Test c186: Create SFQ with limit setting Test ae23: Create SFQ with perturb setting Test a430: Create SFQ with quantum setting Test 4539: Create SFQ with divisor setting Test b089: Create SFQ with flows setting Test 99a0: Create SFQ with depth setting Test 7389: Create SFQ with headdrop setting Test 6472: Create SFQ with redflowlimit setting Test 8929: Show SFQ class Test 4d6f: Check that limit of 1 is rejected Test 7f8f: Check that a derived limit of 1 is rejected (limit 2 depth 1 flows 1) Test 5168: Check that a derived limit of 1 is rejected (limit 2 depth 1 divisor 1) All test results: 1..13 ok 1 7482 - Create SFQ with default setting ok 2 c186 - Create SFQ with limit setting ok 3 ae23 - Create SFQ with perturb setting ok 4 a430 - Create SFQ with quantum setting ok 5 4539 - Create SFQ with divisor setting ok 6 b089 - Create SFQ with flows setting ok 7 99a0 - Create SFQ with depth setting ok 8 7389 - Create SFQ with headdrop setting ok 9 6472 - Create SFQ with redflowlimit setting ok 10 8929 - Show SFQ class ok 11 4d6f - Check that limit of 1 is rejected ok 12 7f8f - Check that a derived limit of 1 is rejected (limit 2 depth 1 flows 1) ok 13 5168 - Check that a derived limit of 1 is rejected (limit 2 depth 1 divisor 1) Thanks, Harshit Eric Dumazet (3): net_sched: sch_sfq: annotate data-races around q->perturb_period net_sched: sch_sfq: handle bigger packets net_sched: sch_sfq: reject invalid perturb period Octavian Purdila (3): net_sched: sch_sfq: don't allow 1 packet limit net_sched: sch_sfq: use a temporary work area for validating configuration net_sched: sch_sfq: move the limit validation net/sched/sch_sfq.c | 114 +++++++++++++++++++++++++++++--------------- 1 file changed, 75 insertions(+), 39 deletions(-) -- 2.47.1

1 month, 2 weeks

2
12
0 0

[PATCH stable 6.6 0/2] selftests/bpf: revert changes from "check bpf_dummy_struct_ops program params for test runs"

by Shung-Hsi Yu

This patchset reverts BPF selftests changes backported from "check bpf_dummy_struct_ops program params for test runs" series[1]. The changes are causing BPF selftests to fail on stable 6.6 kernel due to missing dependencies (mainly the "Support PTR_MAYBE_NULL for struct_ops arguments." series[2]). Please see individual patch for detail. 1: https://lore.kernel.org/bpf/20240424012821.595216-1-eddyz87@gmail.com/ 2: https://lore.kernel.org/bpf/20240209023750.1153905-1-thinker.li@gmail.com/ Shung-Hsi Yu (2): Revert "selftests/bpf: adjust dummy_st_ops_success to detect additional error" Revert "selftests/bpf: dummy_st_ops should reject 0 for non-nullable params" .../selftests/bpf/prog_tests/dummy_st_ops.c | 27 ------------------- .../bpf/progs/dummy_st_ops_success.c | 13 ++------- 2 files changed, 2 insertions(+), 38 deletions(-) -- 2.50.1

1 month, 2 weeks

2
4
0 0

[to-be-updated] mm-check-if-folio-has-valid-mapcount-before-folio_test_anonksm-when-necessary.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm: check if folio has valid mapcount before folio_test_{anon,ksm}() when necessary has been removed from the -mm tree. Its filename was mm-check-if-folio-has-valid-mapcount-before-folio_test_anonksm-when-necessary.patch This patch was dropped because an updated version will be issued ------------------------------------------------------ From: Harry Yoo <harry.yoo(a)oracle.com> Subject: mm: check if folio has valid mapcount before folio_test_{anon,ksm}() when necessary Date: Mon, 7 Jul 2025 21:07:40 +0900 folio_test_anon() and folio_test_ksm() may return false positives when the folio is a typed page (except hugetlb), because lower bits of folio->mapping field can be set even if it doesn't mean FOLIO_MAPPING_* flags. To avoid false positives, folio_test_{anon,ksm}() should be called only if !page_has_type(&folio->page) || folio_test_hugetlb(folio). However, the check can be skipped if a folio is or will be mapped to userspace because typed pages that are not hugetlb folios cannot be mapped to userspace. As folio_expected_ref_count() already does the check, introduce a helper function folio_has_mapcount() and use it in folio_expected_ref_count() and stable_page_flags(). Update the comment in FOLIO_MAPPING_* flags accordingly. This fixes tools/mm/page-types reporting pages with KPF_SLAB, KPF_ANON and KPF_SLAB (with flags, page-counts, MB omitted): $ sudo ./page-types | grep slab _______S___________________________________ slab _______S____a________x_____________________ slab,anonymous,ksm Link: https://lkml.kernel.org/r/20250707120740.4413-1-harry.yoo@oracle.com Fixes: 130d4df57390 ("mm/sl[au]b: rearrange struct slab fields to allow larger rcu_head") Signed-off-by: Harry Yoo <harry.yoo(a)oracle.com> Suggested-by: Vlastimil Babka <vbabka(a)suse.cz> Cc: Christoph Lameter (Ampere) <cl(a)gentwo.org> Cc: David Hildenbrand <david(a)redhat.com> Cc: David Rientjes <rientjes(a)google.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/proc/page.c | 19 +++++++++++-------- include/linux/mm.h | 2 +- include/linux/page-flags.h | 20 ++++++++++++++------ 3 files changed, 26 insertions(+), 15 deletions(-) --- a/fs/proc/page.c~mm-check-if-folio-has-valid-mapcount-before-folio_test_anonksm-when-necessary +++ a/fs/proc/page.c @@ -148,18 +148,21 @@ u64 stable_page_flags(const struct page folio = page_folio(page); k = folio->flags; - mapping = (unsigned long)folio->mapping; - is_anon = mapping & FOLIO_MAPPING_ANON; /* * pseudo flags for the well known (anonymous) memory mapped pages */ - if (page_mapped(page)) - u |= 1 << KPF_MMAP; - if (is_anon) { - u |= 1 << KPF_ANON; - if (mapping & FOLIO_MAPPING_KSM) - u |= 1 << KPF_KSM; + if (folio_has_mapcount(folio)) { + mapping = (unsigned long)folio->mapping; + is_anon = mapping & FOLIO_MAPPING_ANON; + + if (page_mapped(page)) + u |= 1 << KPF_MMAP; + if (is_anon) { + u |= 1 << KPF_ANON; + if (mapping & FOLIO_MAPPING_KSM) + u |= 1 << KPF_KSM; + } } /* --- a/include/linux/mm.h~mm-check-if-folio-has-valid-mapcount-before-folio_test_anonksm-when-necessary +++ a/include/linux/mm.h @@ -2169,7 +2169,7 @@ static inline int folio_expected_ref_cou const int order = folio_order(folio); int ref_count = 0; - if (WARN_ON_ONCE(page_has_type(&folio->page) && !folio_test_hugetlb(folio))) + if (WARN_ON_ONCE(!folio_has_mapcount(folio))) return 0; if (folio_test_anon(folio)) { --- a/include/linux/page-flags.h~mm-check-if-folio-has-valid-mapcount-before-folio_test_anonksm-when-necessary +++ a/include/linux/page-flags.h @@ -706,12 +706,15 @@ PAGEFLAG_FALSE(VmemmapSelfHosted, vmemma * address_space which maps the folio from disk; whereas "folio_mapped" * refers to user virtual address space into which the folio is mapped. * - * For slab pages, since slab reuses the bits in struct page to store its - * internal states, the folio->mapping does not exist as such, nor do - * these flags below. So in order to avoid testing non-existent bits, - * please make sure that folio_test_slab(folio) actually evaluates to - * false before calling the following functions (e.g., folio_test_anon). - * See mm/slab.h. + * For certain typed pages like slabs, since they reuse bits in struct page + * to store internal states, folio->mapping does not point to a valid + * mapping, nor do these flags exist. To avoid testing non-existent bits, + * make sure folio_has_mapcount() actually evaluates to true before calling + * the following functions (e.g., folio_test_anon). + * + * The folio_has_mapcount() check can be skipped if the folio is mapped + * to userspace, since a folio with !folio_has_mapcount() cannot be mapped + * to userspace at all. */ #define FOLIO_MAPPING_ANON 0x1 #define FOLIO_MAPPING_ANON_KSM 0x2 @@ -1092,6 +1095,11 @@ static inline bool PageHuge(const struct return folio_test_hugetlb(page_folio(page)); } +static inline bool folio_has_mapcount(const struct folio *folio) +{ + return !page_has_type(&folio->page) || folio_test_hugetlb(folio); +} + /* * Check if a page is currently marked HWPoisoned. Note that this check is * best effort only and inherently racy: there is no way to synchronize with _ Patches currently in -mm which might be from harry.yoo(a)oracle.com are mm-zsmalloc-do-not-pass-__gfp_movable-if-config_compaction=n.patch

1 month, 2 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror