- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL
by Ze Zuo 02 Jun '26

02 Jun '26

From: Ben Morris <bmorris(a)anthropic.com> stable inclusion from stable-v6.6.140 commit 1bfb06ecb00f7fdf35dba8e8f2877346cbe5e078 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15482 CVE: CVE-2026-46227 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit abb5f36771cc4c05899b34000829a787572a8817 upstream. The SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs with list_for_each_entry_safe(), which caches the next entry in @tmp before the loop body runs. The body calls sctp_sendmsg_to_asoc(), which may drop the socket lock inside sctp_wait_for_sndbuf(). While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the association cached in @tmp, migrating it to a new endpoint via sctp_sock_migrate() (list_del_init() + list_add_tail() to newep->asocs), and optionally close the new socket which frees the association via kfree_rcu(). The cached @tmp can also be freed by a network ABORT for that association, processed in softirq while the lock is dropped. sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock via the "sk != asoc->base.sk" and "asoc->base.dead" checks, but nothing revalidates @tmp. After a successful return, the iterator advances to the stale @tmp, yielding either a use-after-free (if the peeled socket was closed) or a list-walk onto the new endpoint's list head (type confusion of &newep->asocs as a struct sctp_association *). Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->init_sid pointer. Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc() returns. @asoc is known to still be on ep->asocs at that point: the only callers that list_del an association from ep->asocs are sctp_association_free() (which sets asoc->base.dead) and sctp_assoc_migrate() (which changes asoc->base.sk), and sctp_wait_for_sndbuf() checks both under the lock before any successful return; a tripped check propagates as err < 0 and the loop bails before the re-derive. The SCTP_ABORT path in sctp_sendmsg_check_sflags() returns 0 and the loop hits 'continue' before sctp_sendmsg_to_asoc() is ever called, so the @tmp cached by list_for_each_entry_safe() still covers the lock-held free that ba59fb027307 ("sctp: walk the list of asoc safely") was added for. Fixes: 4910280503f3 ("sctp: add support for snd flag SCTP_SENDALL process in sendmsg") Cc: stable(a)vger.kernel.org Signed-off-by: Ben Morris <bmorris(a)anthropic.com> Acked-by: Xin Long <lucien.xin(a)gmail.com> Link: https://patch.msgid.link/20260508001455.3137-1-joycathacker@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Ze Zuo <zuoze1(a)huawei.com> --- net/sctp/socket.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/net/sctp/socket.c b/net/sctp/socket.c index e6ac0bc410a7..3ee77f7cf3f7 100644 --- a/net/sctp/socket.c +++ b/net/sctp/socket.c @@ -2111,6 +2111,15 @@ static int sctp_sendmsg(struct sock *sk, struct msghdr *msg, size_t msg_len) goto out_unlock; iov_iter_revert(&msg->msg_iter, err); + + /* sctp_sendmsg_to_asoc() may have released the socket + * lock (sctp_wait_for_sndbuf), during which other + * associations on ep->asocs could have been peeled + * off or freed. @asoc itself is revalidated by the + * base.dead and base.sk checks in sctp_wait_for_sndbuf, + * so re-derive the cached cursor from it. + */ + tmp = list_next_entry(asoc, asocs); } goto out_unlock; -- 2.25.1

2 1

[PATCH OLK-6.6] mm/page_alloc: clear page->private in free_pages_prepare()
by Ze Zuo 02 Jun '26

02 Jun '26

From: Mikhail Gavrilov <mikhail.v.gavrilov(a)gmail.com> mainline inclusion from mainline-v7.0-rc1 commit ac1ea219590c09572ed5992dc233bbf7bb70fef9 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14860 CVE: CVE-2026-43303 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values. This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860 Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use. Link: https://lkml.kernel.org/r/20260207173615.146159-1-mikhail.v.gavrilov@gmail.… Fixes: 3b8000ae185c ("mm/vmalloc: huge vmalloc backing pages should be split rather than compound") Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov(a)gmail.com> Suggested-by: Zi Yan <ziy(a)nvidia.com> Acked-by: Zi Yan <ziy(a)nvidia.com> Acked-by: David Hildenbrand (Arm) <david(a)kernel.org> Reviewed-by: Vlastimil Babka <vbabka(a)suse.cz> Cc: Brendan Jackman <jackmanb(a)google.com> Cc: Chris Li <chrisl(a)kernel.org> Cc: Hugh Dickins <hughd(a)google.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Kairui Song <ryncsn(a)gmail.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Nicholas Piggin <npiggin(a)gmail.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: mm/page_alloc.c [Context conflicts due not merge commit 53fbef56e07d ("mm: introduce memdesc_flags_t").] Signed-off-by: Ze Zuo <zuoze1(a)huawei.com> --- mm/page_alloc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index f576e0d7ee39..645bcf7213b7 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1152,6 +1152,7 @@ __always_inline bool free_pages_prepare(struct page *page, page_cpupid_reset_last(page); page->flags &= ~PAGE_FLAGS_CHECK_AT_PREP; + page->private = 0; reset_page_owner(page, order); page_table_check_free(page, order); -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] crypto: authencesn - reject short ahash digests during instance creation
by Cui GaoSheng 02 Jun '26

02 Jun '26

From: Yucheng Lu <kanolyc(a)gmail.com> stable inclusion from stable-v5.10.258 commit 77f59fb2d3aa33e90ec6cbbf45dcfb20ab82b1a9 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15279 CVE: CVE-2026-46033 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 5db6ef9847717329f12c5ea8aba7e9f588a980c0 upstream. authencesn requires either a zero authsize or an authsize of at least 4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of high-order sequence number data at the end of the authenticated data. While crypto_authenc_esn_setauthsize() already rejects explicit non-zero authsizes in the range 1..3, crypto_authenc_esn_create() still copied auth->digestsize into inst->alg.maxauthsize without validating it. The AEAD core then initialized the tfm's default authsize from that value. As a result, selecting an ahash with digest size 1..3, such as cbcmac(cipher_null), exposed authencesn instances whose default authsize was invalid even though setauthsize() would have rejected the same value. AF_ALG could then trigger the ESN tail handling with a too-short tag and hit an out-of-bounds access. Reject authencesn instances whose ahash digest size is in the invalid non-zero range 1..3 so that no tfm can inherit an unsupported default authsize. Fixes: f15f05b0a5de ("crypto: ccm - switch to separate cbcmac driver") Cc: stable(a)kernel.org Reported-by: Yifan Wu <yifanwucs(a)gmail.com> Reported-by: Juefei Pu <tomapufckgml(a)gmail.com> Co-developed-by: Yuan Tan <yuantan098(a)gmail.com> Signed-off-by: Yuan Tan <yuantan098(a)gmail.com> Suggested-by: Xin Liu <bird(a)lzu.edu.cn> Tested-by: Yuhang Zheng <z1652074432(a)gmail.com> Reviewed-by: Eric Biggers <ebiggers(a)kernel.org> Signed-off-by: Yucheng Lu <kanolyc(a)gmail.com> Signed-off-by: Ren Wei <n05ec(a)lzu.edu.cn> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: crypto/authencesn.c [ Context conflicts. ] Signed-off-by: Cui GaoSheng <cuigaosheng1(a)huawei.com> --- crypto/authencesn.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/crypto/authencesn.c b/crypto/authencesn.c index f6ffa16a74ef..318fc75d326b 100644 --- a/crypto/authencesn.c +++ b/crypto/authencesn.c @@ -427,6 +427,11 @@ static int crypto_authenc_esn_create(struct crypto_template *tmpl, goto err_free_inst; crypto_set_skcipher_spawn(&ctx->enc, aead_crypto_instance(inst)); + if (auth->digestsize > 0 && auth->digestsize < 4) { + err = -EINVAL; + goto err_free_inst; + } + err = crypto_grab_skcipher(&ctx->enc, enc_name, 0, crypto_requires_sync(algt->type, algt->mask)); -- 2.34.1

2 2

[PATCH openEuler-1.0-LTS] net/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery
by Cui GaoSheng 02 Jun '26

02 Jun '26

From: Gal Pressman <gal(a)nvidia.com> stable inclusion from stable-v5.10.253 commit 821f85d619f7f22cda7b9d7de89cf5eeb1d11544 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15024 CVE: CVE-2026-43466 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1633111d69053512d099658d4a05fc736fab36b0 ] In case of a TX error CQE, a recovery flow is triggered, mlx5e_reset_txqsq_cc_pc() resets dma_fifo_cc to 0 but not dma_fifo_pc, desyncing the DMA FIFO producer and consumer. After recovery, the producer pushes new DMA entries at the old dma_fifo_pc, while the consumer reads from position 0. This causes us to unmap stale DMA addresses from before the recovery. The DMA FIFO is a purely software construct with no HW counterpart. At the point of reset, all WQEs have been flushed so dma_fifo_cc is already equal to dma_fifo_pc. There is no need to reset either counter, similar to how skb_fifo pc/cc are untouched. Remove the 'dma_fifo_cc = 0' reset. This fixes the following WARNING: WARNING: CPU: 0 PID: 0 at drivers/iommu/dma-iommu.c:1240 iommu_dma_unmap_page+0x79/0x90 Modules linked in: mlx5_vdpa vringh vdpa bonding mlx5_ib mlx5_vfio_pci ipip mlx5_fwctl tunnel4 mlx5_core ib_ipoib geneve ip6_gre ip_gre gre nf_tables ip6_tunnel rdma_ucm ib_uverbs ib_umad vfio_pci vfio_pci_core act_mirred act_skbedit act_vlan vhost_net vhost tap ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress vhost_iotlb iptable_raw tunnel6 vfio_iommu_type1 vfio openvswitch nsh rpcsec_gss_krb5 auth_rpcgss oid_registry xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter overlay zram zsmalloc rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core fuse [last unloaded: nf_tables] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5_for_upstream_min_debug_2024_12_30_21_33 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommu_dma_unmap_page+0x79/0x90 Code: 2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 41 5d 41 5e 41 5f e9 c7 ae 9e ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 Call Trace: <IRQ> ? __warn+0x7d/0x110 ? iommu_dma_unmap_page+0x79/0x90 ? report_bug+0x16d/0x180 ? handle_bug+0x4f/0x90 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? iommu_dma_unmap_page+0x79/0x90 ? iommu_dma_unmap_page+0x2e/0x90 dma_unmap_page_attrs+0x10d/0x1b0 mlx5e_tx_wi_dma_unmap+0xbe/0x120 [mlx5_core] mlx5e_poll_tx_cq+0x16d/0x690 [mlx5_core] mlx5e_napi_poll+0x8b/0xac0 [mlx5_core] __napi_poll+0x24/0x190 net_rx_action+0x32a/0x3b0 ? mlx5_eq_comp_int+0x7e/0x270 [mlx5_core] ? notifier_call_chain+0x35/0xa0 handle_softirqs+0xc9/0x270 irq_exit_rcu+0x71/0xd0 common_interrupt+0x7f/0xa0 </IRQ> <TASK> asm_common_interrupt+0x22/0x40 Fixes: db75373c91b0 ("net/mlx5e: Recover Send Queue (SQ) from error state") Signed-off-by: Gal Pressman <gal(a)nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea(a)nvidia.com> Signed-off-by: Tariq Toukan <tariqt(a)nvidia.com> Link: https://patch.msgid.link/20260305142634.1813208-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/net/ethernet/mellanox/mlx5/core/en/reporter_tx.c drivers/net/ethernet/mellanox/mlx5/core/en_main.c [ Context conflict. ] Signed-off-by: Cui GaoSheng <cuigaosheng1(a)huawei.com> --- drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c index 51edc507b7b5..2e27f41a97b5 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c @@ -1346,7 +1346,6 @@ static void mlx5e_reset_txqsq_cc_pc(struct mlx5e_txqsq *sq) "SQ 0x%x: cc (0x%x) != pc (0x%x)\n", sq->sqn, sq->cc, sq->pc); sq->cc = 0; - sq->dma_fifo_cc = 0; sq->pc = 0; } -- 2.34.1

2 1

[PATCH OLK-5.10 0/2] CVE-2026-46181
by Cai Xinchen 02 Jun '26

02 Jun '26

CVE-2026-46181 Jason Gunthorpe (1): RDMA/mlx4: Fix mis-use of RCU in mlx4_srq_event() Suren Baghdasaryan (1): refcount: provide ops for cases when object's memory can be reused Documentation/core-api/refcount-vs-atomic.rst | 37 +++++- drivers/net/ethernet/mellanox/mlx4/srq.c | 13 ++- include/linux/refcount.h | 106 ++++++++++++++++++ include/linux/slab.h | 9 ++ 4 files changed, 153 insertions(+), 12 deletions(-) -- 2.18.0.huawei.25

1 2

[PATCH OLK-5.10 0/2] CVE-2026-46181
by Cai Xinchen 02 Jun '26

02 Jun '26

CVE-2026-46181 Jason Gunthorpe (1): RDMA/mlx4: Fix mis-use of RCU in mlx4_srq_event() Suren Baghdasaryan (1): refcount: provide ops for cases when object's memory can be reused Documentation/core-api/refcount-vs-atomic.rst | 37 +++++- drivers/net/ethernet/mellanox/mlx4/srq.c | 13 ++- include/linux/refcount.h | 106 ++++++++++++++++++ include/linux/slab.h | 9 ++ 4 files changed, 153 insertions(+), 12 deletions(-) -- 2.18.0.huawei.25

2 3

[PATCH OLK-6.6 0/1] CVE-2026-43201
by Liu Mingrui 02 Jun '26

02 Jun '26

CVE-2026-43201 Mauro Carvalho Chehab (1): APEI/GHES: ARM processor Error: don't go past allocated memory drivers/acpi/apei/ghes.c | 34 +++++++++++++++++++++++++++++----- drivers/ras/ras.c | 6 +++++- 2 files changed, 34 insertions(+), 6 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6 0/2] CVE-2026-46181
by Cai Xinchen 02 Jun '26

02 Jun '26

CVE-2026-46181 Jason Gunthorpe (1): RDMA/mlx4: Fix mis-use of RCU in mlx4_srq_event() Suren Baghdasaryan (1): refcount: provide ops for cases when object's memory can be reused Documentation/RCU/whatisRCU.rst | 10 ++ Documentation/core-api/refcount-vs-atomic.rst | 37 +++++- drivers/net/ethernet/mellanox/mlx4/srq.c | 13 ++- include/linux/refcount.h | 106 ++++++++++++++++++ include/linux/slab.h | 9 ++ 5 files changed, 163 insertions(+), 12 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6] mm/vmscan: fix wrong callback in shrinker_v2_to_v1_scan_objects()
by Qi Xi 02 Jun '26

02 Jun '26

hulk inclusion category: feature bugzilla: https://atomgit.com/openeuler/kernel/issues/15059 CVE: NA --------------------------- Fixes the incorrect callback invocation that would cause shrinker behavior mismatch when adapting v2 shrinkers to v1 interface. Signed-off-by: Qi Xi <xiqi5703(a)163.com> --- mm/vmscan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index cf6b9e6dc8cd..305aa6b3cd84 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -7623,7 +7623,7 @@ static unsigned long shrinker_v2_to_v1_scan_objects(struct shrinker_v2 *shk_v2, struct shrink_control *sc) { if (shk_v2->v1) - return shk_v2->v1->count_objects(shk_v2->v1, sc); + return shk_v2->v1->scan_objects(shk_v2->v1, sc); return SHRINK_EMPTY; } -- 2.53.0

2 1

[PATCH openEuler-1.0-LTS] ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O
by Zizhi Wo 02 Jun '26

02 Jun '26

From: Zhang Yi <yi.zhang(a)huawei.com> stable inclusion from stable-v5.10.253 commit 77e407967cd872cd75d7e4a691908e49c8e6b4d4 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15236 CVE: CVE-2026-45985 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit feaf2a80e78f89ee8a3464126077ba8683b62791 ] When allocating blocks during within-EOF DIO and writeback with dioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an existing large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was set when calling ext4_split_convert_extents(), which may potentially result in stale data issues. Assume we have an unwritten extent, and then DIO writes the second half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, ext4_iomap_alloc() call ext4_map_blocks() with EXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and EXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and call ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the above flags set. Then, ext4_split_convert_extents() calls ext4_split_extent() with EXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2 flags set, and it calls ext4_split_extent_at() to split the second half with EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at() failed to insert extent since a temporary lack -ENOSPC. It zeroes out the first half but convert the entire on-disk extent to written since the EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwritten in the extent status tree. [0000000000SSSSSS] data S: stale data, 0: zeroed [WWWWWWWWWWWWWWWW] on-disk extent W: written extent [WWWWWWWWWWUUUUUU] extent status tree Finally, if the DIO failed to write data to the disk, the stale data in the second half will be exposed once the cached extent entry is gone. Fix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splitting an unwritten extent before submitting I/O, and make ext4_split_convert_extents() to zero out the entire extent range to zero for this case, and also mark the extent in the extent status tree for consistency. Fixes: b8a8684502a0 ("ext4: Introduce FALLOC_FL_ZERO_RANGE flag for fallocate") Signed-off-by: Zhang Yi <yi.zhang(a)huawei.com> Reviewed-by: Ojaswin Mujoo <ojaswin(a)linux.ibm.com> Reviewed-by: Baokun Li <libaokun1(a)huawei.com> Cc: stable(a)kernel.org Message-ID: <20251129103247.686136-4-yi.zhang(a)huaweicloud.com> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> [ different function signatures ] Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: fs/ext4/extents.c [Because of commit 779e26517b36 ("ext4: clean up GET_BLOCKS_PRE_IO error handling") not merged, not affect this patch.] Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/ext4/extents.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 5f2654bfe2f1..bddc00996306 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3872,15 +3872,19 @@ static int ext4_split_convert_extents(handle_t *handle, ee_len = ext4_ext_get_actual_len(ex); /* Convert to unwritten */ if (flags & EXT4_GET_BLOCKS_CONVERT_UNWRITTEN) { split_flag |= EXT4_EXT_DATA_VALID1; - /* Convert to initialized */ - } else if (flags & EXT4_GET_BLOCKS_CONVERT) { + /* Split the existing unwritten extent */ + } else if (flags & (EXT4_GET_BLOCKS_UNWRIT_EXT | + EXT4_GET_BLOCKS_CONVERT)) { split_flag |= ee_block + ee_len <= eof_block ? EXT4_EXT_MAY_ZEROOUT : 0; - split_flag |= (EXT4_EXT_MARK_UNWRIT2 | EXT4_EXT_DATA_VALID2); + split_flag |= EXT4_EXT_MARK_UNWRIT2; + /* Convert to initialized */ + if (flags & EXT4_GET_BLOCKS_CONVERT) + split_flag |= EXT4_EXT_DATA_VALID2; } flags |= EXT4_GET_BLOCKS_PRE_IO; return ext4_split_extent(handle, inode, ppath, map, split_flag, flags); } @@ -4207,11 +4211,11 @@ ext4_ext_handle_unwritten_extents(handle_t *handle, struct inode *inode, allocated, newblock); /* get_block() before submit the IO, split the extent */ if (flags & EXT4_GET_BLOCKS_PRE_IO) { ret = ext4_split_convert_extents(handle, inode, map, ppath, - flags | EXT4_GET_BLOCKS_CONVERT); + flags); if (ret <= 0) goto out; map->m_flags |= EXT4_MAP_UNWRITTEN; goto out; } -- 2.52.0

2 1