mailweb.openeuler.org
Manage this list

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

Kernel

Threads by month
  • ----- 2025 -----
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2021 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2020 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2019 -----
  • December
kernel@openeuler.org

  • 55 participants
  • 18788 discussions
[PATCH openEuler-22.03-LTS-SP1] net: openvswitch: fix overwriting ct original tuple for ICMPv6
by Jinjie Ruan 05 Jul '24

05 Jul '24
From: Ilya Maximets <i.maximets(a)ovn.org> stable inclusion from stable-v5.10.219 commit 5ab6aecbede080b44b8e34720ab72050bf1e6982 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SH5 CVE: CVE-2024-38558 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 7c988176b6c16c516474f6fceebe0f055af5eb56 ] OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet. OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers. Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet. It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ct_orig' that holds the original tuple conntrack metadata parsed from the OVS_PACKET_ATTR_KEY. ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten. The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace. ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue. Initializing the whole thing before parsing is needed because ND packet may not contain all the options. The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed. Fixes: 9dd7f8907c37 ("openvswitch: Add original direction conntrack tuple to sw_flow_key.") Reported-by: Antonin Bas <antonin.bas(a)broadcom.com> Closes: https://github.com/openvswitch/ovs-issues/issues/327 Signed-off-by: Ilya Maximets <i.maximets(a)ovn.org> Acked-by: Aaron Conole <aconole(a)redhat.com> Acked-by: Eelco Chaudron <echaudro(a)redhat.com> Link: https://lore.kernel.org/r/20240509094228.1035477-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- net/openvswitch/flow.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c index c9ba61413c98..9bad601c7fe8 100644 --- a/net/openvswitch/flow.c +++ b/net/openvswitch/flow.c @@ -412,7 +412,6 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, */ key->tp.src = htons(icmp->icmp6_type); key->tp.dst = htons(icmp->icmp6_code); - memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); if (icmp->icmp6_code == 0 && (icmp->icmp6_type == NDISC_NEIGHBOUR_SOLICITATION || @@ -421,6 +420,8 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, struct nd_msg *nd; int offset; + memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); + /* In order to process neighbor discovery options, we need the * entire packet. */ -- 2.34.1
2 1
0 0
[PATCH openEuler-22.03-LTS-SP1] btrfs: fix use-after-free after failure to create a snapshot
by Baokun Li 05 Jul '24

05 Jul '24
From: Filipe Manana <fdmanana(a)suse.com> mainline inclusion from mainline-v5.17-rc3 commit 28b21c558a3753171097193b6f6602a94169093a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72FO CVE: CVE-2022-48733 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- At ioctl.c:create_snapshot(), we allocate a pending snapshot structure and then attach it to the transaction's list of pending snapshots. After that we call btrfs_commit_transaction(), and if that returns an error we jump to 'fail' label, where we kfree() the pending snapshot structure. This can result in a later use-after-free of the pending snapshot: 1) We allocated the pending snapshot and added it to the transaction's list of pending snapshots; 2) We call btrfs_commit_transaction(), and it fails either at the first call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups(). In both cases, we don't abort the transaction and we release our transaction handle. We jump to the 'fail' label and free the pending snapshot structure. We return with the pending snapshot still in the transaction's list; 3) Another task commits the transaction. This time there's no error at all, and then during the transaction commit it accesses a pointer to the pending snapshot structure that the snapshot creation task has already freed, resulting in a user-after-free. This issue could actually be detected by smatch, which produced the following warning: fs/btrfs/ioctl.c:843 create_snapshot() warn: '&pending_snapshot->list' not removed from list So fix this by not having the snapshot creation ioctl directly add the pending snapshot to the transaction's list. Instead add the pending snapshot to the transaction handle, and then at btrfs_commit_transaction() we add the snapshot to the list only when we can guarantee that any error returned after that point will result in a transaction abort, in which case the ioctl code can safely free the pending snapshot and no one can access it anymore. CC: stable(a)vger.kernel.org # 5.10+ Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Conflicts: fs/btrfs/ioctl.c fs/btrfs/transaction.c [Because commit 74e97958121a ("btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations") was merged before this commit and current commit d0c2f4fa555eh ("btrfs: make concurrent fsyncs wait less when waiting for a transaction commit") has not been merged yet.] Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/btrfs/ioctl.c | 5 +---- fs/btrfs/transaction.c | 24 ++++++++++++++++++++++++ fs/btrfs/transaction.h | 2 ++ 3 files changed, 27 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 3d96eef71e2b..ca0894de2ecd 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -868,10 +868,7 @@ static int create_snapshot(struct btrfs_root *root, struct inode *dir, btrfs_qgroup_convert_reserved_meta(root, qgroup_reserved); qgroup_reserved = 0; - spin_lock(&fs_info->trans_lock); - list_add(&pending_snapshot->list, - &trans->transaction->pending_snapshots); - spin_unlock(&fs_info->trans_lock); + trans->pending_snapshot = pending_snapshot; ret = btrfs_commit_transaction(trans); if (ret) diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c index eb9ab3d3a7b3..897ea85e04e4 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -2031,6 +2031,27 @@ static inline void btrfs_wait_delalloc_flush(struct btrfs_fs_info *fs_info) btrfs_wait_ordered_roots(fs_info, U64_MAX, 0, (u64)-1); } +/* + * Add a pending snapshot associated with the given transaction handle to the + * respective handle. This must be called after the transaction commit started + * and while holding fs_info->trans_lock. + * This serves to guarantee a caller of btrfs_commit_transaction() that it can + * safely free the pending snapshot pointer in case btrfs_commit_transaction() + * returns an error. + */ +static void add_pending_snapshot(struct btrfs_trans_handle *trans) +{ + struct btrfs_transaction *cur_trans = trans->transaction; + + if (!trans->pending_snapshot) + return; + + lockdep_assert_held(&trans->fs_info->trans_lock); + ASSERT(cur_trans->state >= TRANS_STATE_COMMIT_START); + + list_add(&trans->pending_snapshot->list, &cur_trans->pending_snapshots); +} + int btrfs_commit_transaction(struct btrfs_trans_handle *trans) { struct btrfs_fs_info *fs_info = trans->fs_info; @@ -2117,6 +2138,8 @@ int btrfs_commit_transaction(struct btrfs_trans_handle *trans) spin_lock(&fs_info->trans_lock); if (cur_trans->state >= TRANS_STATE_COMMIT_START) { + add_pending_snapshot(trans); + spin_unlock(&fs_info->trans_lock); refcount_inc(&cur_trans->use_count); ret = btrfs_end_transaction(trans); @@ -2199,6 +2222,7 @@ int btrfs_commit_transaction(struct btrfs_trans_handle *trans) * COMMIT_DOING so make sure to wait for num_writers to == 1 again. */ spin_lock(&fs_info->trans_lock); + add_pending_snapshot(trans); cur_trans->state = TRANS_STATE_COMMIT_DOING; spin_unlock(&fs_info->trans_lock); wait_event(cur_trans->writer_wait, diff --git a/fs/btrfs/transaction.h b/fs/btrfs/transaction.h index f73654d93fa0..eb26eb068fe8 100644 --- a/fs/btrfs/transaction.h +++ b/fs/btrfs/transaction.h @@ -122,6 +122,8 @@ struct btrfs_trans_handle { struct btrfs_transaction *transaction; struct btrfs_block_rsv *block_rsv; struct btrfs_block_rsv *orig_rsv; + /* Set by a task that wants to create a snapshot. */ + struct btrfs_pending_snapshot *pending_snapshot; refcount_t use_count; unsigned int type; /* -- 2.31.1
2 1
0 0
[PATCH OLK-5.10] btrfs: fix use-after-free after failure to create a snapshot
by Baokun Li 05 Jul '24

05 Jul '24
From: Filipe Manana <fdmanana(a)suse.com> mainline inclusion from mainline-v5.17-rc3 commit 28b21c558a3753171097193b6f6602a94169093a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72FO CVE: CVE-2022-48733 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- At ioctl.c:create_snapshot(), we allocate a pending snapshot structure and then attach it to the transaction's list of pending snapshots. After that we call btrfs_commit_transaction(), and if that returns an error we jump to 'fail' label, where we kfree() the pending snapshot structure. This can result in a later use-after-free of the pending snapshot: 1) We allocated the pending snapshot and added it to the transaction's list of pending snapshots; 2) We call btrfs_commit_transaction(), and it fails either at the first call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups(). In both cases, we don't abort the transaction and we release our transaction handle. We jump to the 'fail' label and free the pending snapshot structure. We return with the pending snapshot still in the transaction's list; 3) Another task commits the transaction. This time there's no error at all, and then during the transaction commit it accesses a pointer to the pending snapshot structure that the snapshot creation task has already freed, resulting in a user-after-free. This issue could actually be detected by smatch, which produced the following warning: fs/btrfs/ioctl.c:843 create_snapshot() warn: '&pending_snapshot->list' not removed from list So fix this by not having the snapshot creation ioctl directly add the pending snapshot to the transaction's list. Instead add the pending snapshot to the transaction handle, and then at btrfs_commit_transaction() we add the snapshot to the list only when we can guarantee that any error returned after that point will result in a transaction abort, in which case the ioctl code can safely free the pending snapshot and no one can access it anymore. CC: stable(a)vger.kernel.org # 5.10+ Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Conflicts: fs/btrfs/ioctl.c fs/btrfs/transaction.c [Because commit 74e97958121a ("btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations") was merged before this commit and current commit d0c2f4fa555eh ("btrfs: make concurrent fsyncs wait less when waiting for a transaction commit") has not been merged yet.] Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/btrfs/ioctl.c | 5 +---- fs/btrfs/transaction.c | 24 ++++++++++++++++++++++++ fs/btrfs/transaction.h | 2 ++ 3 files changed, 27 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index f625c42f48a3..358b9a5937a4 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -868,10 +868,7 @@ static int create_snapshot(struct btrfs_root *root, struct inode *dir, btrfs_qgroup_convert_reserved_meta(root, qgroup_reserved); qgroup_reserved = 0; - spin_lock(&fs_info->trans_lock); - list_add(&pending_snapshot->list, - &trans->transaction->pending_snapshots); - spin_unlock(&fs_info->trans_lock); + trans->pending_snapshot = pending_snapshot; ret = btrfs_commit_transaction(trans); if (ret) diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c index 968f5b45062c..a73b400450ce 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -2038,6 +2038,27 @@ static inline void btrfs_wait_delalloc_flush(struct btrfs_fs_info *fs_info) btrfs_wait_ordered_roots(fs_info, U64_MAX, 0, (u64)-1); } +/* + * Add a pending snapshot associated with the given transaction handle to the + * respective handle. This must be called after the transaction commit started + * and while holding fs_info->trans_lock. + * This serves to guarantee a caller of btrfs_commit_transaction() that it can + * safely free the pending snapshot pointer in case btrfs_commit_transaction() + * returns an error. + */ +static void add_pending_snapshot(struct btrfs_trans_handle *trans) +{ + struct btrfs_transaction *cur_trans = trans->transaction; + + if (!trans->pending_snapshot) + return; + + lockdep_assert_held(&trans->fs_info->trans_lock); + ASSERT(cur_trans->state >= TRANS_STATE_COMMIT_START); + + list_add(&trans->pending_snapshot->list, &cur_trans->pending_snapshots); +} + int btrfs_commit_transaction(struct btrfs_trans_handle *trans) { struct btrfs_fs_info *fs_info = trans->fs_info; @@ -2124,6 +2145,8 @@ int btrfs_commit_transaction(struct btrfs_trans_handle *trans) spin_lock(&fs_info->trans_lock); if (cur_trans->state >= TRANS_STATE_COMMIT_START) { + add_pending_snapshot(trans); + spin_unlock(&fs_info->trans_lock); refcount_inc(&cur_trans->use_count); ret = btrfs_end_transaction(trans); @@ -2206,6 +2229,7 @@ int btrfs_commit_transaction(struct btrfs_trans_handle *trans) * COMMIT_DOING so make sure to wait for num_writers to == 1 again. */ spin_lock(&fs_info->trans_lock); + add_pending_snapshot(trans); cur_trans->state = TRANS_STATE_COMMIT_DOING; spin_unlock(&fs_info->trans_lock); wait_event(cur_trans->writer_wait, diff --git a/fs/btrfs/transaction.h b/fs/btrfs/transaction.h index f73654d93fa0..eb26eb068fe8 100644 --- a/fs/btrfs/transaction.h +++ b/fs/btrfs/transaction.h @@ -122,6 +122,8 @@ struct btrfs_trans_handle { struct btrfs_transaction *transaction; struct btrfs_block_rsv *block_rsv; struct btrfs_block_rsv *orig_rsv; + /* Set by a task that wants to create a snapshot. */ + struct btrfs_pending_snapshot *pending_snapshot; refcount_t use_count; unsigned int type; /* -- 2.31.1
2 1
0 0
[PATCH openEuler-22.03-LTS-SP1 0/7] Sync bugfix from OLK-5.10
by Zheng Yejian 05 Jul '24

05 Jul '24
Daniel Borkmann (1): bpf: Fix __reg_bound_offset 64->32 var_off subreg propagation Krister Johansen (1): bpf: ensure main program has an extable Kumar Kartikeya Dwivedi (1): bpf: Clobber stack slot when writing over spilled PTR_TO_BTF_ID Martin KaFai Lau (1): bpf: Check the other end of slot_type for STACK_SPILL Stanislav Fomichev (2): bpf: Don't EFAULT for getsockopt with optval=NULL bpf: Don't EFAULT for {g,s}setsockopt with wrong optlen Wang Yufen (1): bpf: Fix memory leaks in __check_func_call kernel/bpf/cgroup.c | 24 +++++++- kernel/bpf/verifier.c | 61 ++++++++++++------- .../testing/selftests/bpf/prog_tests/align.c | 4 +- 3 files changed, 61 insertions(+), 28 deletions(-) -- 2.25.1
2 8
0 0
[openeuler:openEuler-1.0-LTS] BUILD SUCCESS 1b4ca2a2c1253c9e2d2428cc4fae541fdf3b326d
by kernel test robot 05 Jul '24

05 Jul '24
tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: 1b4ca2a2c1253c9e2d2428cc4fae541fdf3b326d !9765 i40e: Fix queues reservation for XDP Unverified Warning (likely false positive, please contact us if interested): drivers/uio/uio_hv_generic.c:311 hv_uio_probe() warn: 'pdata->recv_buf' double freed drivers/uio/uio_hv_generic.c:311 hv_uio_probe() warn: 'pdata->send_buf' double freed Warning ids grouped by kconfigs: recent_errors `-- x86_64-randconfig-161-20240704 |-- drivers-uio-uio_hv_generic.c-hv_uio_probe()-warn:pdata-recv_buf-double-freed `-- drivers-uio-uio_hv_generic.c-hv_uio_probe()-warn:pdata-send_buf-double-freed elapsed time: 734m configs tested: 34 configs skipped: 128 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig gcc-13.2.0 arm64 allnoconfig gcc-13.2.0 arm64 randconfig-001-20240705 gcc-13.2.0 arm64 randconfig-002-20240705 gcc-13.2.0 arm64 randconfig-003-20240705 gcc-13.2.0 arm64 randconfig-004-20240705 gcc-13.2.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240705 gcc-7 x86_64 buildonly-randconfig-002-20240705 gcc-13 x86_64 buildonly-randconfig-003-20240705 clang-18 x86_64 buildonly-randconfig-004-20240705 clang-18 x86_64 buildonly-randconfig-005-20240705 clang-18 x86_64 buildonly-randconfig-006-20240705 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240705 clang-18 x86_64 randconfig-002-20240705 gcc-13 x86_64 randconfig-003-20240705 clang-18 x86_64 randconfig-004-20240705 gcc-13 x86_64 randconfig-005-20240705 gcc-13 x86_64 randconfig-006-20240705 gcc-13 x86_64 randconfig-011-20240705 clang-18 x86_64 randconfig-012-20240705 gcc-9 x86_64 randconfig-013-20240705 clang-18 x86_64 randconfig-014-20240705 gcc-13 x86_64 randconfig-015-20240705 clang-18 x86_64 randconfig-016-20240705 gcc-9 x86_64 randconfig-071-20240705 gcc-13 x86_64 randconfig-072-20240705 gcc-13 x86_64 randconfig-073-20240705 clang-18 x86_64 randconfig-074-20240705 gcc-13 x86_64 randconfig-075-20240705 clang-18 x86_64 randconfig-076-20240705 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:OLK-6.6] BUILD SUCCESS b206e4b36a7f6d4d7806d653f1e71867dd56571d
by kernel test robot 05 Jul '24

05 Jul '24
tree/branch: https://gitee.com/openeuler/kernel.git OLK-6.6 branch HEAD: b206e4b36a7f6d4d7806d653f1e71867dd56571d !9757 net: openvswitch: fix overwriting ct original tuple for ICMPv6 Warning ids grouped by kconfigs: recent_errors `-- arm64-allmodconfig `-- clang:warning:no-such-include-directory:drivers-infiniband-hw-hiroce3-include-mag elapsed time: 723m configs tested: 21 configs skipped: 124 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig clang-19 arm64 allnoconfig gcc-13.2.0 arm64 randconfig-001-20240705 clang-19 arm64 randconfig-002-20240705 clang-19 arm64 randconfig-003-20240705 clang-19 arm64 randconfig-004-20240705 clang-19 loongarch allmodconfig gcc-13.2.0 loongarch allnoconfig gcc-13.2.0 loongarch randconfig-001-20240705 gcc-13.2.0 loongarch randconfig-002-20240705 gcc-13.2.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240705 gcc-7 x86_64 buildonly-randconfig-002-20240705 gcc-13 x86_64 buildonly-randconfig-003-20240705 clang-18 x86_64 buildonly-randconfig-004-20240705 clang-18 x86_64 buildonly-randconfig-005-20240705 clang-18 x86_64 buildonly-randconfig-006-20240705 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240705 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[PATCH OLK-6.6 0/2] Add a switch to enable hungtask check for io
by Li Lingfeng 05 Jul '24

05 Jul '24
Add a switch to enable hungtask check for io Li Lingfeng (1): block: disable BLK_IO_HUNG_TASK_CHECK by default Yu Kuai (1): block: add a switch to enable hungtask check for io arch/arm64/configs/openeuler_defconfig | 1 + arch/x86/configs/openeuler_defconfig | 1 + block/Kconfig | 9 +++++++++ block/bio.c | 2 +- block/blk-core.c | 13 ++++++++++++- block/blk-mq.c | 2 +- block/blk.h | 1 + 7 files changed, 26 insertions(+), 3 deletions(-) -- 2.31.1
2 3
0 0
[PATCH openEuler-22.03-LTS-SP1] iomap: Don't finish dio under irq when there exists pages
by Zhihao Cheng 05 Jul '24

05 Jul '24
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA4DAW CVE: NA -------------------------------- Since commit 6fac6d0e975afe1dec ("ext4: Optimize endio process for DIO overwrites"), pages invalidating won't be done in io completeing process, which could make generic/451 failed. In generic 451, there are two concurrent tasks: task A is reading(with page cache) a file, task B is directly writing and reading to verify content. Task B will verify failed in following process: task A task B direct_write(offs=L, content_Y) submit_IO content_X = read_page(offs=L) // stale data, because IO is not completed content_X = find_page(offs=L) // content_Y != content_X Fixes: 6fac6d0e975a ("ext4: Optimize endio process for DIO overwrites") Signed-off-by: Zhihao Cheng <chengzhihao(a)huaweicloud.com> --- fs/iomap/direct-io.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c index ad12ffcc5085..4760a481e444 100644 --- a/fs/iomap/direct-io.c +++ b/fs/iomap/direct-io.c @@ -180,6 +180,11 @@ static void iomap_dio_bio_end_io(struct bio *bio) goto release_bio; } + if ((dio->flags & IOMAP_DIO_INLINE_COMP) && dio->size && + (dio->flags & IOMAP_DIO_WRITE) && + file_inode(iocb->ki_filp)->i_mapping->nrpages) + dio->flags &= ~IOMAP_DIO_INLINE_COMP; + /* * Flagged with IOMAP_DIO_INLINE_COMP, we can complete it inline */ -- 2.31.1
2 1
0 0
[PATCH OLK-5.10] iomap: Don't finish dio under irq when there exists pages
by Zhihao Cheng 05 Jul '24

05 Jul '24
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA4DAW CVE: NA -------------------------------- Since commit 48774b90b5677bdb4 ("ext4: Optimize endio process for DIO overwrites"), pages invalidating won't be done in io completeing process, which could make generic/451 failed. In generic 451, there are two concurrent tasks: task A is reading(with page cache) a file, task B is directly writing and reading to verify content. Task B will verify failed in following process: task A task B direct_write(offs=L, content_Y) submit_IO content_X = read_page(offs=L) // stale data, because IO is not completed content_X = find_page(offs=L) // content_Y != content_X Fixes: 48774b90b567 ("ext4: Optimize endio process for DIO overwrites") Signed-off-by: Zhihao Cheng <chengzhihao(a)huaweicloud.com> --- fs/iomap/direct-io.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c index 61cc9a13a40a..fc9908d79f93 100644 --- a/fs/iomap/direct-io.c +++ b/fs/iomap/direct-io.c @@ -180,6 +180,11 @@ static void iomap_dio_bio_end_io(struct bio *bio) goto release_bio; } + if ((dio->flags & IOMAP_DIO_INLINE_COMP) && dio->size && + (dio->flags & IOMAP_DIO_WRITE) && + file_inode(iocb->ki_filp)->i_mapping->nrpages) + dio->flags &= ~IOMAP_DIO_INLINE_COMP; + /* * Flagged with IOMAP_DIO_INLINE_COMP, we can complete it inline */ -- 2.31.1
2 1
0 0
[openeuler:OLK-5.10] BUILD SUCCESS 451734a9a63432990e3124ae33b413c8bb221f5a
by kernel test robot 05 Jul '24

05 Jul '24
tree/branch: https://gitee.com/openeuler/kernel.git OLK-5.10 branch HEAD: 451734a9a63432990e3124ae33b413c8bb221f5a !9716 ax25: Fix reference count leak issues of ax25_dev Warning ids grouped by kconfigs: recent_errors `-- x86_64-allnoconfig `-- drivers-arm-spe-spe.c:linux-perf-arm_pmu.h-is-included-more-than-once. elapsed time: 725m configs tested: 34 configs skipped: 128 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig clang-19 arm64 allnoconfig gcc-13.2.0 arm64 randconfig-001-20240705 clang-19 arm64 randconfig-002-20240705 clang-19 arm64 randconfig-003-20240705 clang-19 arm64 randconfig-004-20240705 clang-19 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240705 gcc-7 x86_64 buildonly-randconfig-002-20240705 gcc-13 x86_64 buildonly-randconfig-003-20240705 clang-18 x86_64 buildonly-randconfig-004-20240705 clang-18 x86_64 buildonly-randconfig-005-20240705 clang-18 x86_64 buildonly-randconfig-006-20240705 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240705 clang-18 x86_64 randconfig-002-20240705 gcc-13 x86_64 randconfig-003-20240705 clang-18 x86_64 randconfig-004-20240705 gcc-13 x86_64 randconfig-005-20240705 gcc-13 x86_64 randconfig-006-20240705 gcc-13 x86_64 randconfig-011-20240705 clang-18 x86_64 randconfig-012-20240705 gcc-9 x86_64 randconfig-013-20240705 clang-18 x86_64 randconfig-014-20240705 gcc-13 x86_64 randconfig-015-20240705 clang-18 x86_64 randconfig-016-20240705 gcc-9 x86_64 randconfig-071-20240705 gcc-13 x86_64 randconfig-072-20240705 gcc-13 x86_64 randconfig-073-20240705 clang-18 x86_64 randconfig-074-20240705 gcc-13 x86_64 randconfig-075-20240705 clang-18 x86_64 randconfig-076-20240705 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
  • ← Newer
  • 1
  • ...
  • 825
  • 826
  • 827
  • 828
  • 829
  • 830
  • 831
  • ...
  • 1879
  • Older →

HyperKitty Powered by HyperKitty