September 2025 - Linux-stable-mirror

[REGRESSION 5.15.y][BISECTED][PATCH 0/1] console hangs at uevents

by Brett A C Sheffield

Commit ee7a69aa38d8 ("fbdev: Disable sysfb device registration when removing conflicting FBs") was backported to 5.15.y LTS. This causes a regression where all virtual consoles stop responding during boot at: "Populating /dev with existing devices through uevents ..." The console is no longer responding, nor is it possible to switch to another virtual console. It is possible to force a reboot with CTRL+ALT+DEL. The system is otherwise still working normally, and can be connected to over ssh. This patch was not backported to 5.4.y or 5.10.y. Newer stable kernels with this patch (6.1.y, 6.6.y, 6.12,y, 6.15.y, 6.16.y) and mainline are unaffected. There are a bunch of patches that touch fbmem.c in later stable kernels, and I started looking at this but it gets messy very quickly as e23a5e14aa27 is a merge commit. Given this was an autoselected patch that was not backported to fix any specific issue the simplest and cleanest fix is to simply revert. Bisection log: git bisect start # status: waiting for both good and bad commits # good: [8bb7eca972ad531c9b149c0a51ab43a417385813] Linux 5.15 git bisect good 8bb7eca972ad531c9b149c0a51ab43a417385813 # status: waiting for bad commit, 1 good commit known # bad: [c275eaaaa34260e6c907bc5e7ee07c096bc45064] Linux 5.15.125 git bisect bad c275eaaaa34260e6c907bc5e7ee07c096bc45064 # bad: [ff2932ac8ee1ce6f66ba1b5017843c87492cd1a8] tcp: Fix a data-race around sysctl_tcp_challenge_ack_limit. git bisect bad ff2932ac8ee1ce6f66ba1b5017843c87492cd1a8 # good: [72ea28d88d30cefc5b0184e4666cf4817f2a0fa8] arm64: dts: marvell: armada-37xx: Remap IO space to bus address 0x0 git bisect good 72ea28d88d30cefc5b0184e4666cf4817f2a0fa8 # good: [acd12d16528152b32fa09be2c5ef95047f69af05] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID git bisect good acd12d16528152b32fa09be2c5ef95047f69af05 # good: [ce49b94ddb70e607c476a12d26002715d694b23a] random: avoid checking crng_ready() twice in random_init() git bisect good ce49b94ddb70e607c476a12d26002715d694b23a # good: [6886327780254ba749b770373653b6afc2a339fc] fbcon: Disallow setting font bigger than screen size git bisect good 6886327780254ba749b770373653b6afc2a339fc # bad: [1f068f9da7436b11276f23ebf65dd641c8ae0b62] x86/entry: Avoid very early RET git bisect bad 1f068f9da7436b11276f23ebf65dd641c8ae0b62 # good: [5a4bb158f4c638d1fc494d2730357cfb6f5a4eea] netfilter: nf_tables: replace BUG_ON by element length check git bisect good 5a4bb158f4c638d1fc494d2730357cfb6f5a4eea # bad: [e71d0e1370b162271a0053e1f1215961c31dc4cb] ASoC: codecs: rt700/rt711/rt711-sdca: initialize workqueues in probe git bisect bad e71d0e1370b162271a0053e1f1215961c31dc4cb # good: [2d84fcb6e6f74c96eb03e6a1b9eed0a164e37b2c] seg6: bpf: fix skb checksum in bpf_push_seg6_encap() git bisect good 2d84fcb6e6f74c96eb03e6a1b9eed0a164e37b2c # good: [06f818de1621ea4da689fd45f1eb54ff7617342b] scsi: hisi_sas: Limit max hw sectors for v3 HW git bisect good 06f818de1621ea4da689fd45f1eb54ff7617342b # bad: [7a2294c5f2e5636772afe6bd6c5b28218e0ea154] nvme: fix regression when disconnect a recovering ctrl git bisect bad 7a2294c5f2e5636772afe6bd6c5b28218e0ea154 # good: [b952569e03168e23258fabf3faa4d6d2b8e08835] firmware: sysfb: Add sysfb_disable() helper function git bisect good b952569e03168e23258fabf3faa4d6d2b8e08835 # bad: [833ecd0eae76eadf81d6d747bb5bc992d1151867] net: tipc: fix possible refcount leak in tipc_sk_create() git bisect bad 833ecd0eae76eadf81d6d747bb5bc992d1151867 # bad: [13d28e0c79cbf69fc6f145767af66905586c1249] fbdev: Disable sysfb device registration when removing conflicting FBs git bisect bad 13d28e0c79cbf69fc6f145767af66905586c1249 # first bad commit: [13d28e0c79cbf69fc6f145767af66905586c1249] fbdev: Disable sysfb device registration when removing conflicting FBs Brett A C Sheffield (1): Revert "fbdev: Disable sysfb device registration when removing conflicting FBs" drivers/video/fbdev/core/fbmem.c | 12 ------------ 1 file changed, 12 deletions(-) -- 2.49.1

1 week, 5 days

3
5
0 0

[PATCH] powerpc/64s/radix/kfence: map __kfence_pool at page granularity

by Aboorva Devarajan

From: Hari Bathini <hbathini(a)linux.ibm.com> When KFENCE is enabled, total system memory is mapped at page level granularity. But in radix MMU mode, ~3GB additional memory is needed to map 100GB of system memory at page level granularity when compared to using 2MB direct mapping.This is not desired considering KFENCE is designed to be enabled in production kernels [1]. Mapping only the memory allocated for KFENCE pool at page granularity is sufficient to enable KFENCE support. So, allocate __kfence_pool during bootup and map it at page granularity instead of mapping all system memory at page granularity. Without patch: # cat /proc/meminfo MemTotal: 101201920 kB With patch: # cat /proc/meminfo MemTotal: 104483904 kB Note that enabling KFENCE at runtime is disabled for radix MMU for now, as it depends on the ability to split page table mappings and such APIs are not currently implemented for radix MMU. All kfence_test.c testcases passed with this patch. [1] https://lore.kernel.org/all/20201103175841.3495947-2-elver@google.com/ Fixes: a5edf9815dd7 ("powerpc/64s: Enable KFENCE on book3s64") Cc: stable(a)vger.kernel.org Signed-off-by: Hari Bathini <hbathini(a)linux.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Aboorva Devarajan <aboorvad(a)linux.ibm.com> Link: https://msgid.link/20240701130021.578240-1-hbathini@linux.ibm.com --- Upstream commit 353d7a84c214 ("powerpc/64s/radix/kfence: map __kfence_pool at page granularity") This has already been merged upstream and is required in stable kernels as well. --- arch/powerpc/include/asm/kfence.h | 11 +++- arch/powerpc/mm/book3s64/radix_pgtable.c | 84 ++++++++++++++++++++++-- arch/powerpc/mm/init-common.c | 3 + 3 files changed, 93 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/include/asm/kfence.h b/arch/powerpc/include/asm/kfence.h index 424ceef82ae615..fab124ada1c7f2 100644 --- a/arch/powerpc/include/asm/kfence.h +++ b/arch/powerpc/include/asm/kfence.h @@ -15,10 +15,19 @@ #define ARCH_FUNC_PREFIX "." #endif +#ifdef CONFIG_KFENCE +extern bool kfence_disabled; + +static inline void disable_kfence(void) +{ + kfence_disabled = true; +} + static inline bool arch_kfence_init_pool(void) { - return true; + return !kfence_disabled; } +#endif #ifdef CONFIG_PPC64 static inline bool kfence_protect_page(unsigned long addr, bool protect) diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch/powerpc/mm/book3s64/radix_pgtable.c index 15e88f1439ec20..b0d927009af83c 100644 --- a/arch/powerpc/mm/book3s64/radix_pgtable.c +++ b/arch/powerpc/mm/book3s64/radix_pgtable.c @@ -17,6 +17,7 @@ #include <linux/hugetlb.h> #include <linux/string_helpers.h> #include <linux/memory.h> +#include <linux/kfence.h> #include <asm/pgalloc.h> #include <asm/mmu_context.h> @@ -31,6 +32,7 @@ #include <asm/uaccess.h> #include <asm/ultravisor.h> #include <asm/set_memory.h> +#include <asm/kfence.h> #include <trace/events/thp.h> @@ -293,7 +295,8 @@ static unsigned long next_boundary(unsigned long addr, unsigned long end) static int __meminit create_physical_mapping(unsigned long start, unsigned long end, - int nid, pgprot_t _prot) + int nid, pgprot_t _prot, + unsigned long mapping_sz_limit) { unsigned long vaddr, addr, mapping_size = 0; bool prev_exec, exec = false; @@ -301,7 +304,10 @@ static int __meminit create_physical_mapping(unsigned long start, int psize; unsigned long max_mapping_size = memory_block_size; - if (debug_pagealloc_enabled_or_kfence()) + if (mapping_sz_limit < max_mapping_size) + max_mapping_size = mapping_sz_limit; + + if (debug_pagealloc_enabled()) max_mapping_size = PAGE_SIZE; start = ALIGN(start, PAGE_SIZE); @@ -356,8 +362,74 @@ static int __meminit create_physical_mapping(unsigned long start, return 0; } +#ifdef CONFIG_KFENCE +static bool __ro_after_init kfence_early_init = !!CONFIG_KFENCE_SAMPLE_INTERVAL; + +static int __init parse_kfence_early_init(char *arg) +{ + int val; + + if (get_option(&arg, &val)) + kfence_early_init = !!val; + return 0; +} +early_param("kfence.sample_interval", parse_kfence_early_init); + +static inline phys_addr_t alloc_kfence_pool(void) +{ + phys_addr_t kfence_pool; + + /* + * TODO: Support to enable KFENCE after bootup depends on the ability to + * split page table mappings. As such support is not currently + * implemented for radix pagetables, support enabling KFENCE + * only at system startup for now. + * + * After support for splitting mappings is available on radix, + * alloc_kfence_pool() & map_kfence_pool() can be dropped and + * mapping for __kfence_pool memory can be + * split during arch_kfence_init_pool(). + */ + if (!kfence_early_init) + goto no_kfence; + + kfence_pool = memblock_phys_alloc(KFENCE_POOL_SIZE, PAGE_SIZE); + if (!kfence_pool) + goto no_kfence; + + memblock_mark_nomap(kfence_pool, KFENCE_POOL_SIZE); + return kfence_pool; + +no_kfence: + disable_kfence(); + return 0; +} + +static inline void map_kfence_pool(phys_addr_t kfence_pool) +{ + if (!kfence_pool) + return; + + if (create_physical_mapping(kfence_pool, kfence_pool + KFENCE_POOL_SIZE, + -1, PAGE_KERNEL, PAGE_SIZE)) + goto err; + + memblock_clear_nomap(kfence_pool, KFENCE_POOL_SIZE); + __kfence_pool = __va(kfence_pool); + return; + +err: + memblock_phys_free(kfence_pool, KFENCE_POOL_SIZE); + disable_kfence(); +} +#else +static inline phys_addr_t alloc_kfence_pool(void) { return 0; } +static inline void map_kfence_pool(phys_addr_t kfence_pool) { } +#endif + static void __init radix_init_pgtable(void) { + phys_addr_t kfence_pool; unsigned long rts_field; phys_addr_t start, end; u64 i; @@ -365,6 +437,8 @@ static void __init radix_init_pgtable(void) /* We don't support slb for radix */ slb_set_size(0); + kfence_pool = alloc_kfence_pool(); + /* * Create the linear mapping */ @@ -381,9 +455,11 @@ static void __init radix_init_pgtable(void) } WARN_ON(create_physical_mapping(start, end, - -1, PAGE_KERNEL)); + -1, PAGE_KERNEL, ~0UL)); } + map_kfence_pool(kfence_pool); + if (!cpu_has_feature(CPU_FTR_HVMODE) && cpu_has_feature(CPU_FTR_P9_RADIX_PREFETCH_BUG)) { /* @@ -875,7 +951,7 @@ int __meminit radix__create_section_mapping(unsigned long start, } return create_physical_mapping(__pa(start), __pa(end), - nid, prot); + nid, prot, ~0UL); } int __meminit radix__remove_section_mapping(unsigned long start, unsigned long end) diff --git a/arch/powerpc/mm/init-common.c b/arch/powerpc/mm/init-common.c index d3a7726ecf512c..21131b96d20901 100644 --- a/arch/powerpc/mm/init-common.c +++ b/arch/powerpc/mm/init-common.c @@ -31,6 +31,9 @@ EXPORT_SYMBOL_GPL(kernstart_virt_addr); bool disable_kuep = !IS_ENABLED(CONFIG_PPC_KUEP); bool disable_kuap = !IS_ENABLED(CONFIG_PPC_KUAP); +#ifdef CONFIG_KFENCE +bool __ro_after_init kfence_disabled; +#endif static int __init parse_nosmep(char *p) {

1 week, 5 days

1
0
0 0

[PATCH 5.15] xfs: short circuit xfs_growfs_data_private() if delta is zero

by Amir Goldstein

From: Eric Sandeen <sandeen(a)redhat.com> [ Upstream commit 84712492e6dab803bf595fb8494d11098b74a652 ] Although xfs_growfs_data() doesn't call xfs_growfs_data_private() if in->newblocks == mp->m_sb.sb_dblocks, xfs_growfs_data_private() further massages the new block count so that we don't i.e. try to create a too-small new AG. This may lead to a delta of "0" in xfs_growfs_data_private(), so we end up in the shrink case and emit the EXPERIMENTAL warning even if we're not changing anything at all. Fix this by returning straightaway if the block delta is zero. (nb: in older kernels, the result of entering the shrink case with delta == 0 may actually let an -ENOSPC escape to userspace, which is confusing for users.) Fixes: fb2fc1720185 ("xfs: support shrinking unused space in the last AG") Signed-off-by: Eric Sandeen <sandeen(a)redhat.com> Reviewed-by: "Darrick J. Wong" <djwong(a)kernel.org> Signed-off-by: Chandan Babu R <chandanbabu(a)kernel.org> Signed-off-by: Amir Goldstein <amir73il(a)gmail.com> --- Greg, This fixes fstests failure in xfs/606. The upstream fix applies cleanly to 5.15.y and was already backported to 6.6.y and 6.1.y by Leah: https://lore.kernel.org/linux-xfs/20240501184112.3799035-24-leah.rumancik@g… Wasn't sure if you'd prefer to keep Leah's SOB and Darrick's ACK from the 6.1.y backport, so did not keep them. This is tested and running on our production 5.15 kernel for a while. Thanks, Amir. fs/xfs/xfs_fsops.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/xfs/xfs_fsops.c b/fs/xfs/xfs_fsops.c index 5b5b68affe66..2d7467be2a48 100644 --- a/fs/xfs/xfs_fsops.c +++ b/fs/xfs/xfs_fsops.c @@ -126,6 +126,10 @@ xfs_growfs_data_private( if (delta < 0 && nagcount < 2) return -EINVAL; + /* No work to do */ + if (delta == 0) + return 0; + oagcount = mp->m_sb.sb_agcount; /* allocate the new per-ag structures */ -- 2.47.1

1 week, 5 days

1
0
0 0

[PATCH v1] arm64: dts: qcom: monaco-evk: Use correct sound card compatible to match SoC

by Mohammad Rafi Shaik

The Monaco-EVK board is based on Qualcomm's QCS8300 SoC. The DTS previously reused the sound card compatible as "qcom,qcs8275-sndcard", which is based on existing coverage. To maintain clarity and consistency, the naming conventions for the compatible should reflect actual SoC rather than the board. Therefore, update the sound card compatible as "qcom,qcs8300-sndcard" to avoid potential confusion. Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik(a)oss.qualcomm.com> --- This patch series depends on patch series: https://lore.kernel.org/linux-sound/20250905142647.2566951-1-mohammad.rafi.… --- arch/arm64/boot/dts/qcom/monaco-evk.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/qcom/monaco-evk.dts b/arch/arm64/boot/dts/qcom/monaco-evk.dts index f3c5d363921e..7187c1760ef5 100644 --- a/arch/arm64/boot/dts/qcom/monaco-evk.dts +++ b/arch/arm64/boot/dts/qcom/monaco-evk.dts @@ -38,7 +38,7 @@ max98357a: audio-codec-1 { }; sound { - compatible = "qcom,qcs8275-sndcard"; + compatible = "qcom,qcs8300-sndcard"; model = "MONACO-EVK"; pinctrl-0 = <&hs0_mi2s_active>, <&mi2s1_active>; -- 2.34.1

1 week, 5 days

3
3
0 0

[PATCH net 0/3] mptcp: misc fixes for v6.17-rc6

by Matthieu Baerts (NGI0)

Here are various unrelated fixes: - Patch 1: Fix a wrong attribute type in the MPTCP Netlink specs. A fix for v6.7. - Patch 2: Avoid mentioning a deprecated MPTCP sysctl knob in the doc. A fix for v6.15. - Patch 3: Handle new warnings from ShellCheck v0.11.0. This prevents some warnings reported by some CIs. If it is not a good material for 'net', please drop it and I can resend it later, targeting 'net-next'. Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- Matthieu Baerts (NGI0) (3): netlink: specs: mptcp: fix if-idx attribute type doc: mptcp: net.mptcp.pm_type is deprecated selftests: mptcp: shellcheck: support v0.11.0 Documentation/netlink/specs/mptcp_pm.yaml | 2 +- Documentation/networking/mptcp.rst | 8 ++++---- tools/testing/selftests/net/mptcp/diag.sh | 2 +- tools/testing/selftests/net/mptcp/mptcp_connect.sh | 2 +- tools/testing/selftests/net/mptcp/mptcp_join.sh | 2 +- tools/testing/selftests/net/mptcp/mptcp_sockopt.sh | 2 +- tools/testing/selftests/net/mptcp/pm_netlink.sh | 5 +++-- tools/testing/selftests/net/mptcp/simult_flows.sh | 2 +- tools/testing/selftests/net/mptcp/userspace_pm.sh | 2 +- 9 files changed, 14 insertions(+), 13 deletions(-) --- base-commit: e2a10daba84968f6b5777d150985fd7d6abc9c84 change-id: 20250908-net-mptcp-misc-fixes-6-17-rc5-7550f5f90b66 Best regards, -- Matthieu Baerts (NGI0) <matttbe(a)kernel.org>

1 week, 5 days

6
8
0 0

[PATCH] crypto: aspeed - Fix dma_unmap_sg() direction

by Thomas Fourier

It seems like everywhere in this file, when the request is not bidirectional, req->src is mapped with DMA_TO_DEVICE and req->src is mapped with DMA_FROM_DEVICE. Fixes: 62f58b1637b7 ("crypto: aspeed - add HACE crypto driver") Cc: <stable(a)vger.kernel.org> Signed-off-by: Thomas Fourier <fourier.thomas(a)gmail.com> --- drivers/crypto/aspeed/aspeed-hace-crypto.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/aspeed/aspeed-hace-crypto.c b/drivers/crypto/aspeed/aspeed-hace-crypto.c index a72dfebc53ff..fa201dae1f81 100644 --- a/drivers/crypto/aspeed/aspeed-hace-crypto.c +++ b/drivers/crypto/aspeed/aspeed-hace-crypto.c @@ -346,7 +346,7 @@ static int aspeed_sk_start_sg(struct aspeed_hace_dev *hace_dev) } else { dma_unmap_sg(hace_dev->dev, req->dst, rctx->dst_nents, - DMA_TO_DEVICE); + DMA_FROM_DEVICE); dma_unmap_sg(hace_dev->dev, req->src, rctx->src_nents, DMA_TO_DEVICE); } -- 2.43.0

1 week, 5 days

2
1
0 0

OFFER

by MAJOR TRADE

1 week, 5 days

1
0
0 0

New September Order. 73342 Wednesday, September 10, 2025 at 07:26:21 AM

by Info - Albinayah 397

Hi Stable, Please provide a quote for your products: Include: 1.Pricing (per unit) 2.Delivery cost & timeline 3.Quote expiry date Deadline: September Thanks! Kamal Prasad Albinayah Trading

1 week, 5 days

1
0
0 0

+ zram-fix-slot-write-race-condition.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: zram: fix slot write race condition has been added to the -mm mm-hotfixes-unstable branch. Its filename is zram-fix-slot-write-race-condition.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Sergey Senozhatsky <senozhatsky(a)chromium.org> Subject: zram: fix slot write race condition Date: Tue, 9 Sep 2025 13:48:35 +0900 Parallel concurrent writes to the same zram index result in leaked zsmalloc handles. Schematically we can have something like this: CPU0 CPU1 zram_slot_lock() zs_free(handle) zram_slot_lock() zram_slot_lock() zs_free(handle) zram_slot_lock() compress compress handle = zs_malloc() handle = zs_malloc() zram_slot_lock zram_set_handle(handle) zram_slot_lock zram_slot_lock zram_set_handle(handle) zram_slot_lock Either CPU0 or CPU1 zsmalloc handle will leak because zs_free() is done too early. In fact, we need to reset zram entry right before we set its new handle, all under the same slot lock scope. Link: https://lkml.kernel.org/r/20250909045150.635345-1-senozhatsky@chromium.org Fixes: 71268035f5d73 ("zram: free slot memory early during write") Signed-off-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> Reported-by: Changhui Zhong <czhong(a)redhat.com> Closes: https://lore.kernel.org/all/CAGVVp+UtpGoW5WEdEU7uVTtsSCjPN=ksN6EcvyypAtFDOU… Cc: Jens Axboe <axboe(a)kernel.dk> Cc: Minchan Kim <minchan(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- drivers/block/zram/zram_drv.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) --- a/drivers/block/zram/zram_drv.c~zram-fix-slot-write-race-condition +++ a/drivers/block/zram/zram_drv.c @@ -1795,6 +1795,7 @@ static int write_same_filled_page(struct u32 index) { zram_slot_lock(zram, index); + zram_free_page(zram, index); zram_set_flag(zram, index, ZRAM_SAME); zram_set_handle(zram, index, fill); zram_slot_unlock(zram, index); @@ -1832,6 +1833,7 @@ static int write_incompressible_page(str kunmap_local(src); zram_slot_lock(zram, index); + zram_free_page(zram, index); zram_set_flag(zram, index, ZRAM_HUGE); zram_set_handle(zram, index, handle); zram_set_obj_size(zram, index, PAGE_SIZE); @@ -1855,11 +1857,6 @@ static int zram_write_page(struct zram * unsigned long element; bool same_filled; - /* First, free memory allocated to this slot (if any) */ - zram_slot_lock(zram, index); - zram_free_page(zram, index); - zram_slot_unlock(zram, index); - mem = kmap_local_page(page); same_filled = page_same_filled(mem, &element); kunmap_local(mem); @@ -1901,6 +1898,7 @@ static int zram_write_page(struct zram * zcomp_stream_put(zstrm); zram_slot_lock(zram, index); + zram_free_page(zram, index); zram_set_handle(zram, index, handle); zram_set_obj_size(zram, index, comp_len); zram_slot_unlock(zram, index); _ Patches currently in -mm which might be from senozhatsky(a)chromium.org are zram-fix-slot-write-race-condition.patch zram-protect-recomp_algorithm_show-with-init_lock.patch panic-remove-redundant-panic-cpu-backtrace.patch

1 week, 5 days

1
0
0 0

[PATCHv2] zram: fix slot write race condition

by Sergey Senozhatsky

Parallel concurrent writes to the same zram index result in leaked zsmalloc handles. Schematically we can have something like this: CPU0 CPU1 zram_slot_lock() zs_free(handle) zram_slot_lock() zram_slot_lock() zs_free(handle) zram_slot_lock() compress compress handle = zs_malloc() handle = zs_malloc() zram_slot_lock zram_set_handle(handle) zram_slot_lock zram_slot_lock zram_set_handle(handle) zram_slot_lock Either CPU0 or CPU1 zsmalloc handle will leak because zs_free() is done too early. In fact, we need to reset zram entry right before we set its new handle, all under the same slot lock scope. Cc: stable(a)vger.kernel.org Reported-by: Changhui Zhong <czhong(a)redhat.com> Closes: https://lore.kernel.org/all/CAGVVp+UtpGoW5WEdEU7uVTtsSCjPN=ksN6EcvyypAtFDOU… Fixes: 71268035f5d73 ("zram: free slot memory early during write") Signed-off-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> --- drivers/block/zram/zram_drv.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index 9ac271b82780..78b56cd7698e 100644 --- a/drivers/block/zram/zram_drv.c +++ b/drivers/block/zram/zram_drv.c @@ -1788,6 +1788,7 @@ static int write_same_filled_page(struct zram *zram, unsigned long fill, u32 index) { zram_slot_lock(zram, index); + zram_free_page(zram, index); zram_set_flag(zram, index, ZRAM_SAME); zram_set_handle(zram, index, fill); zram_slot_unlock(zram, index); @@ -1825,6 +1826,7 @@ static int write_incompressible_page(struct zram *zram, struct page *page, kunmap_local(src); zram_slot_lock(zram, index); + zram_free_page(zram, index); zram_set_flag(zram, index, ZRAM_HUGE); zram_set_handle(zram, index, handle); zram_set_obj_size(zram, index, PAGE_SIZE); @@ -1848,11 +1850,6 @@ static int zram_write_page(struct zram *zram, struct page *page, u32 index) unsigned long element; bool same_filled; - /* First, free memory allocated to this slot (if any) */ - zram_slot_lock(zram, index); - zram_free_page(zram, index); - zram_slot_unlock(zram, index); - mem = kmap_local_page(page); same_filled = page_same_filled(mem, &element); kunmap_local(mem); @@ -1894,6 +1891,7 @@ static int zram_write_page(struct zram *zram, struct page *page, u32 index) zcomp_stream_put(zstrm); zram_slot_lock(zram, index); + zram_free_page(zram, index); zram_set_handle(zram, index, handle); zram_set_obj_size(zram, index, comp_len); zram_slot_unlock(zram, index); -- 2.51.0.384.g4c02a37b29-goog

1 week, 5 days

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2025