- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6 0/8] Support feature TLBI
by lishusen 16 Jan '24

16 Jan '24

Support feature TLBI Quan Zhou (5): KVM: arm64: Support a new HiSi CPU type KVM: arm64: Probe and configure DVMBM capability on HiSi CPUs KVM: arm64: Add kvm_vcpu_arch::cpus_ptr and pre_cpus_ptr KVM: arm64: Add kvm_arch::dvm_cpumask and dvm_lock KVM: arm64: Implement the capability of DVMBM Yanan Wang (1): KVM: arm64: Only probe Hisi ncsnp feature on Hisi CPUs Zenghui Yu (2): KVM: arm64: Probe Hisi CPU TYPE from ACPI/DTB KVM: arm64: Add support for probing Hisi ncsnp capability .../admin-guide/kernel-parameters.txt | 3 + arch/arm64/configs/openeuler_defconfig | 1 + arch/arm64/include/asm/kvm_host.h | 16 + arch/arm64/kernel/image-vars.h | 5 + arch/arm64/kvm/Kconfig | 1 + arch/arm64/kvm/Makefile | 1 + arch/arm64/kvm/arm.c | 52 +++ arch/arm64/kvm/hisilicon/Kconfig | 7 + arch/arm64/kvm/hisilicon/Makefile | 2 + arch/arm64/kvm/hisilicon/hisi_virt.c | 389 ++++++++++++++++++ arch/arm64/kvm/hisilicon/hisi_virt.h | 61 +++ arch/arm64/kvm/hyp/pgtable.c | 2 +- 12 files changed, 539 insertions(+), 1 deletion(-) create mode 100644 arch/arm64/kvm/hisilicon/Kconfig create mode 100644 arch/arm64/kvm/hisilicon/Makefile create mode 100644 arch/arm64/kvm/hisilicon/hisi_virt.c create mode 100644 arch/arm64/kvm/hisilicon/hisi_virt.h -- 2.33.0

2 9

[PATCH OLK-6.6 0/2] Support feature TWED
by lishusen 16 Jan '24

16 Jan '24

Support feature TWED Jingyi Wang (1): KVM: arm64: Make use of TWED feature Zengruan Ye (1): arm64: cpufeature: TWED support detection arch/arm64/Kconfig | 10 ++++++++++ arch/arm64/include/asm/kvm_arm.h | 8 ++++++++ arch/arm64/include/asm/kvm_emulate.h | 27 +++++++++++++++++++++++++++ arch/arm64/include/asm/kvm_host.h | 8 ++++++++ arch/arm64/include/asm/virt.h | 5 +++++ arch/arm64/kernel/cpufeature.c | 12 ++++++++++++ arch/arm64/kvm/arm.c | 15 +++++++++++++++ arch/arm64/tools/cpucaps | 1 + 8 files changed, 86 insertions(+) -- 2.33.0

2 3

[PATCH OLK-5.10] netfilter: nf_tables: Reject tables of unsupported family
by Liu Jian 16 Jan '24

16 Jan '24

From: Phil Sutter <phil(a)nwl.cc> mainline inclusion from mainline-v5.18-rc1 commit f1082dd31fe461d482d69da2a8eccfeb7bf07ac2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I8VPKT CVE: CVE-2023-6040 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- An nftables family is merely a hollow container, its family just a number and such not reliant on compile-time options other than nftables support itself. Add an artificial check so attempts at using a family the kernel can't support fail as early as possible. This helps user space detect kernels which lack e.g. NFPROTO_INET. Signed-off-by: Phil Sutter <phil(a)nwl.cc> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> Conflicts: net/netfilter/nf_tables_api.c --- net/netfilter/nf_tables_api.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c index 3be68ec4f3d9..208b77e374e4 100644 --- a/net/netfilter/nf_tables_api.c +++ b/net/netfilter/nf_tables_api.c @@ -1151,6 +1151,30 @@ static int nft_objname_hash_cmp(struct rhashtable_compare_arg *arg, return strcmp(obj->key.name, k->name); } +static bool nft_supported_family(u8 family) +{ + return false +#ifdef CONFIG_NF_TABLES_INET + || family == NFPROTO_INET +#endif +#ifdef CONFIG_NF_TABLES_IPV4 + || family == NFPROTO_IPV4 +#endif +#ifdef CONFIG_NF_TABLES_ARP + || family == NFPROTO_ARP +#endif +#ifdef CONFIG_NF_TABLES_NETDEV + || family == NFPROTO_NETDEV +#endif +#if IS_ENABLED(CONFIG_NF_TABLES_BRIDGE) + || family == NFPROTO_BRIDGE +#endif +#ifdef CONFIG_NF_TABLES_IPV6 + || family == NFPROTO_IPV6 +#endif + ; +} + static int nf_tables_newtable(struct net *net, struct sock *nlsk, struct sk_buff *skb, const struct nlmsghdr *nlh, const struct nlattr * const nla[], @@ -1166,6 +1190,9 @@ static int nf_tables_newtable(struct net *net, struct sock *nlsk, u32 flags = 0; int err; + if (!nft_supported_family(family)) + return -EOPNOTSUPP; + lockdep_assert_held(&nft_net->commit_mutex); attr = nla[NFTA_TABLE_NAME]; table = nft_table_lookup(net, attr, family, genmask); -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] netfilter: nf_tables: Reject tables of unsupported family
by Liu Jian 16 Jan '24

16 Jan '24

From: Phil Sutter <phil(a)nwl.cc> mainline inclusion from mainline-v5.18-rc1 commit f1082dd31fe461d482d69da2a8eccfeb7bf07ac2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I8VPKT CVE: CVE-2023-6040 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- An nftables family is merely a hollow container, its family just a number and such not reliant on compile-time options other than nftables support itself. Add an artificial check so attempts at using a family the kernel can't support fail as early as possible. This helps user space detect kernels which lack e.g. NFPROTO_INET. Signed-off-by: Phil Sutter <phil(a)nwl.cc> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> Conflicts: net/netfilter/nf_tables_api.c --- net/netfilter/nf_tables_api.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c index c3fedbfd0ee2..e07c497e7344 100644 --- a/net/netfilter/nf_tables_api.c +++ b/net/netfilter/nf_tables_api.c @@ -853,6 +853,30 @@ static int nft_chain_hash_cmp(struct rhashtable_compare_arg *arg, return strcmp(chain->name, name); } +static bool nft_supported_family(u8 family) +{ + return false +#ifdef CONFIG_NF_TABLES_INET + || family == NFPROTO_INET +#endif +#ifdef CONFIG_NF_TABLES_IPV4 + || family == NFPROTO_IPV4 +#endif +#ifdef CONFIG_NF_TABLES_ARP + || family == NFPROTO_ARP +#endif +#ifdef CONFIG_NF_TABLES_NETDEV + || family == NFPROTO_NETDEV +#endif +#if IS_ENABLED(CONFIG_NF_TABLES_BRIDGE) + || family == NFPROTO_BRIDGE +#endif +#ifdef CONFIG_NF_TABLES_IPV6 + || family == NFPROTO_IPV6 +#endif + ; +} + static int nf_tables_newtable(struct net *net, struct sock *nlsk, struct sk_buff *skb, const struct nlmsghdr *nlh, const struct nlattr * const nla[], @@ -867,6 +891,9 @@ static int nf_tables_newtable(struct net *net, struct sock *nlsk, struct nft_ctx ctx; int err; + if (!nft_supported_family(family)) + return -EOPNOTSUPP; + lockdep_assert_held(&net->nft.commit_mutex); attr = nla[NFTA_TABLE_NAME]; table = nft_table_lookup(net, attr, family, genmask); -- 2.34.1

2 1

[PATCH OLK-6.6 00/15] Support pv feature
by lishusen 16 Jan '24

16 Jan '24

Support pv feature Zenghui Yu (1): KVM: arm64: Fix {fp_asimd,sve}_exit_stat manipulation Zengruan Ye (10): KVM: arm64: Document PV-sched interface KVM: arm64: Implement PV_SCHED_FEATURES call KVM: arm64: Support pvsched preempted via shared structure KVM: arm64: Add interface to support vCPU preempted check KVM: arm64: Support the vCPU preemption check KVM: arm64: Add SMCCC PV-sched to kick cpu KVM: arm64: Implement PV_SCHED_KICK_CPU call KVM: arm64: Add interface to support PV qspinlock KVM: arm64: Enable PV qspinlock KVM: arm64: Add tracepoints for PV qspinlock chenjiajun (1): kvm: debugfs: export remaining aarch64 kvm exit reasons to debugfs lishusen (2): KVM: arm64: Replace pv.ops by static_call for PV qspinlock feature KVM: arm64: Add configuration for feature pv-sched yezengruan (1): kvm: arm64: fix some pvsched bugs C | 0 Documentation/virt/kvm/arm/pvsched.rst | 74 ++++++++ arch/arm64/Kconfig | 20 +++ arch/arm64/include/asm/Kbuild | 1 - arch/arm64/include/asm/kvm_host.h | 39 ++++ arch/arm64/include/asm/paravirt.h | 51 ++++++ arch/arm64/include/asm/pvsched-abi.h | 16 ++ arch/arm64/include/asm/qspinlock.h | 48 +++++ arch/arm64/include/asm/qspinlock_paravirt.h | 12 ++ arch/arm64/include/asm/spinlock.h | 13 ++ arch/arm64/kernel/Makefile | 3 +- arch/arm64/kernel/paravirt-spinlocks.c | 21 +++ arch/arm64/kernel/paravirt.c | 189 ++++++++++++++++++++ arch/arm64/kernel/trace-paravirt.h | 66 +++++++ arch/arm64/kvm/Makefile | 2 +- arch/arm64/kvm/arm.c | 26 +++ arch/arm64/kvm/handle_exit.c | 12 ++ arch/arm64/kvm/hyp/include/hyp/switch.h | 2 + arch/arm64/kvm/hypercalls.c | 24 +++ arch/arm64/kvm/mmu.c | 1 + arch/arm64/kvm/pvsched.c | 81 +++++++++ arch/arm64/kvm/sys_regs.c | 11 ++ arch/arm64/kvm/trace_arm.h | 18 ++ include/linux/arm-smccc.h | 25 +++ include/linux/cpuhotplug.h | 1 + 25 files changed, 753 insertions(+), 3 deletions(-) create mode 100644 C create mode 100644 Documentation/virt/kvm/arm/pvsched.rst create mode 100644 arch/arm64/include/asm/pvsched-abi.h create mode 100644 arch/arm64/include/asm/qspinlock.h create mode 100644 arch/arm64/include/asm/qspinlock_paravirt.h create mode 100644 arch/arm64/kernel/paravirt-spinlocks.c create mode 100644 arch/arm64/kernel/trace-paravirt.h create mode 100644 arch/arm64/kvm/pvsched.c -- 2.33.0

2 16

[PATCH OLK-6.6 0/6] kabi: net: reserve space for net
by Zhengchao Shao 16 Jan '24

16 Jan '24

2 7

[PATCH OLK-5.10] mm/filemap: avoid buffered read/write race to read inconsistent data
by Baokun Li 16 Jan '24

16 Jan '24

mainline inclusion from mainline-v6.7-rc8 commit e2c27b803bb664748e090d99042ac128b3f88d92 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I8RRAT Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The following concurrency may cause the data read to be inconsistent with the data on disk: cpu1 cpu2 ------------------------------|------------------------------ // Buffered write 2048 from 0 ext4_buffered_write_iter generic_perform_write copy_page_from_iter_atomic ext4_da_write_end ext4_da_do_write_end block_write_end __block_commit_write folio_mark_uptodate // Buffered read 4096 from 0 smp_wmb() ext4_file_read_iter set_bit(PG_uptodate, folio_flags) generic_file_read_iter i_size_write // 2048 filemap_read unlock_page(page) filemap_get_pages filemap_get_read_batch folio_test_uptodate(folio) ret = test_bit(PG_uptodate, folio_flags) if (ret) smp_rmb(); // Ensure that the data in page 0-2048 is up-to-date. // New buffered write 2048 from 2048 ext4_buffered_write_iter generic_perform_write copy_page_from_iter_atomic ext4_da_write_end ext4_da_do_write_end block_write_end __block_commit_write folio_mark_uptodate smp_wmb() set_bit(PG_uptodate, folio_flags) i_size_write // 4096 unlock_page(page) isize = i_size_read(inode) // 4096 // Read the latest isize 4096, but without smp_rmb(), there may be // Load-Load disorder resulting in the data in the 2048-4096 range // in the page is not up-to-date. copy_page_to_iter // copyout 4096 In the concurrency above, we read the updated i_size, but there is no read barrier to ensure that the data in the page is the same as the i_size at this point, so we may copy the unsynchronized page out. Hence adding the missing read memory barrier to fix this. This is a Load-Load reordering issue, which only occurs on some weak mem-ordering architectures (e.g. ARM64, ALPHA), but not on strong mem-ordering architectures (e.g. X86). And theoretically the problem doesn't only happen on ext4, filesystems that call filemap_read() but don't hold inode lock (e.g. btrfs, f2fs, ubifs ...) will have this problem, while filesystems with inode lock (e.g. xfs, nfs) won't have this problem. Link: https://lkml.kernel.org/r/20231213062324.739009-1-libaokun1@huawei.com Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Cc: Andreas Dilger <adilger.kernel(a)dilger.ca> Cc: Christoph Hellwig <hch(a)infradead.org> Cc: Dave Chinner <david(a)fromorbit.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Ritesh Harjani (IBM) <ritesh.list(a)gmail.com> Cc: Theodore Ts'o <tytso(a)mit.edu> Cc: yangerkun <yangerkun(a)huawei.com> Cc: Yu Kuai <yukuai3(a)huawei.com> Cc: Zhang Yi <yi.zhang(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: mm/filemap.c Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- mm/filemap.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/mm/filemap.c b/mm/filemap.c index 04e4aad7ed67..c40eb1707cfb 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -2616,6 +2616,15 @@ ssize_t generic_file_buffered_read(struct kiocb *iocb, end_offset = min_t(loff_t, isize, iocb->ki_pos + iter->count); + /* + * Pairs with a barrier in + * block_write_end()->mark_buffer_dirty() or other page + * dirtying routines like iomap_write_end() to ensure + * changes to page contents are visible before we see + * increased inode size. + */ + smp_rmb(); + while ((iocb->ki_pos >> PAGE_SHIFT) + pg_nr > (end_offset + PAGE_SIZE - 1) >> PAGE_SHIFT) put_page(pages[--pg_nr]); -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS-SP2] mm/filemap: avoid buffered read/write race to read inconsistent data
by Baokun Li 16 Jan '24

16 Jan '24

mainline inclusion from mainline-v6.7-rc8 commit e2c27b803bb664748e090d99042ac128b3f88d92 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I8RRAT Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The following concurrency may cause the data read to be inconsistent with the data on disk: cpu1 cpu2 ------------------------------|------------------------------ // Buffered write 2048 from 0 ext4_buffered_write_iter generic_perform_write copy_page_from_iter_atomic ext4_da_write_end ext4_da_do_write_end block_write_end __block_commit_write folio_mark_uptodate // Buffered read 4096 from 0 smp_wmb() ext4_file_read_iter set_bit(PG_uptodate, folio_flags) generic_file_read_iter i_size_write // 2048 filemap_read unlock_page(page) filemap_get_pages filemap_get_read_batch folio_test_uptodate(folio) ret = test_bit(PG_uptodate, folio_flags) if (ret) smp_rmb(); // Ensure that the data in page 0-2048 is up-to-date. // New buffered write 2048 from 2048 ext4_buffered_write_iter generic_perform_write copy_page_from_iter_atomic ext4_da_write_end ext4_da_do_write_end block_write_end __block_commit_write folio_mark_uptodate smp_wmb() set_bit(PG_uptodate, folio_flags) i_size_write // 4096 unlock_page(page) isize = i_size_read(inode) // 4096 // Read the latest isize 4096, but without smp_rmb(), there may be // Load-Load disorder resulting in the data in the 2048-4096 range // in the page is not up-to-date. copy_page_to_iter // copyout 4096 In the concurrency above, we read the updated i_size, but there is no read barrier to ensure that the data in the page is the same as the i_size at this point, so we may copy the unsynchronized page out. Hence adding the missing read memory barrier to fix this. This is a Load-Load reordering issue, which only occurs on some weak mem-ordering architectures (e.g. ARM64, ALPHA), but not on strong mem-ordering architectures (e.g. X86). And theoretically the problem doesn't only happen on ext4, filesystems that call filemap_read() but don't hold inode lock (e.g. btrfs, f2fs, ubifs ...) will have this problem, while filesystems with inode lock (e.g. xfs, nfs) won't have this problem. Link: https://lkml.kernel.org/r/20231213062324.739009-1-libaokun1@huawei.com Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Cc: Andreas Dilger <adilger.kernel(a)dilger.ca> Cc: Christoph Hellwig <hch(a)infradead.org> Cc: Dave Chinner <david(a)fromorbit.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Ritesh Harjani (IBM) <ritesh.list(a)gmail.com> Cc: Theodore Ts'o <tytso(a)mit.edu> Cc: yangerkun <yangerkun(a)huawei.com> Cc: Yu Kuai <yukuai3(a)huawei.com> Cc: Zhang Yi <yi.zhang(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: mm/filemap.c Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- mm/filemap.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/mm/filemap.c b/mm/filemap.c index fd4aae06ff15..327f92544537 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -2616,6 +2616,15 @@ ssize_t generic_file_buffered_read(struct kiocb *iocb, end_offset = min_t(loff_t, isize, iocb->ki_pos + iter->count); + /* + * Pairs with a barrier in + * block_write_end()->mark_buffer_dirty() or other page + * dirtying routines like iomap_write_end() to ensure + * changes to page contents are visible before we see + * increased inode size. + */ + smp_rmb(); + while ((iocb->ki_pos >> PAGE_SHIFT) + pg_nr > (end_offset + PAGE_SIZE - 1) >> PAGE_SHIFT) put_page(pages[--pg_nr]); -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS-SP1] mm/filemap: avoid buffered read/write race to read inconsistent data
by Baokun Li 16 Jan '24

16 Jan '24

mainline inclusion from mainline-v6.7-rc8 commit e2c27b803bb664748e090d99042ac128b3f88d92 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I8RRAT Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The following concurrency may cause the data read to be inconsistent with the data on disk: cpu1 cpu2 ------------------------------|------------------------------ // Buffered write 2048 from 0 ext4_buffered_write_iter generic_perform_write copy_page_from_iter_atomic ext4_da_write_end ext4_da_do_write_end block_write_end __block_commit_write folio_mark_uptodate // Buffered read 4096 from 0 smp_wmb() ext4_file_read_iter set_bit(PG_uptodate, folio_flags) generic_file_read_iter i_size_write // 2048 filemap_read unlock_page(page) filemap_get_pages filemap_get_read_batch folio_test_uptodate(folio) ret = test_bit(PG_uptodate, folio_flags) if (ret) smp_rmb(); // Ensure that the data in page 0-2048 is up-to-date. // New buffered write 2048 from 2048 ext4_buffered_write_iter generic_perform_write copy_page_from_iter_atomic ext4_da_write_end ext4_da_do_write_end block_write_end __block_commit_write folio_mark_uptodate smp_wmb() set_bit(PG_uptodate, folio_flags) i_size_write // 4096 unlock_page(page) isize = i_size_read(inode) // 4096 // Read the latest isize 4096, but without smp_rmb(), there may be // Load-Load disorder resulting in the data in the 2048-4096 range // in the page is not up-to-date. copy_page_to_iter // copyout 4096 In the concurrency above, we read the updated i_size, but there is no read barrier to ensure that the data in the page is the same as the i_size at this point, so we may copy the unsynchronized page out. Hence adding the missing read memory barrier to fix this. This is a Load-Load reordering issue, which only occurs on some weak mem-ordering architectures (e.g. ARM64, ALPHA), but not on strong mem-ordering architectures (e.g. X86). And theoretically the problem doesn't only happen on ext4, filesystems that call filemap_read() but don't hold inode lock (e.g. btrfs, f2fs, ubifs ...) will have this problem, while filesystems with inode lock (e.g. xfs, nfs) won't have this problem. Link: https://lkml.kernel.org/r/20231213062324.739009-1-libaokun1@huawei.com Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Cc: Andreas Dilger <adilger.kernel(a)dilger.ca> Cc: Christoph Hellwig <hch(a)infradead.org> Cc: Dave Chinner <david(a)fromorbit.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Ritesh Harjani (IBM) <ritesh.list(a)gmail.com> Cc: Theodore Ts'o <tytso(a)mit.edu> Cc: yangerkun <yangerkun(a)huawei.com> Cc: Yu Kuai <yukuai3(a)huawei.com> Cc: Zhang Yi <yi.zhang(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: mm/filemap.c Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- mm/filemap.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/mm/filemap.c b/mm/filemap.c index f360440afe67..b657efc78a9c 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -2616,6 +2616,15 @@ ssize_t generic_file_buffered_read(struct kiocb *iocb, end_offset = min_t(loff_t, isize, iocb->ki_pos + iter->count); + /* + * Pairs with a barrier in + * block_write_end()->mark_buffer_dirty() or other page + * dirtying routines like iomap_write_end() to ensure + * changes to page contents are visible before we see + * increased inode size. + */ + smp_rmb(); + while ((iocb->ki_pos >> PAGE_SHIFT) + pg_nr > (end_offset + PAGE_SIZE - 1) >> PAGE_SHIFT) put_page(pages[--pg_nr]); -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS] mm/filemap: avoid buffered read/write race to read inconsistent data
by Baokun Li 16 Jan '24

16 Jan '24

mainline inclusion from mainline-v6.7-rc8 commit e2c27b803bb664748e090d99042ac128b3f88d92 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I8RRAT Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The following concurrency may cause the data read to be inconsistent with the data on disk: cpu1 cpu2 ------------------------------|------------------------------ // Buffered write 2048 from 0 ext4_buffered_write_iter generic_perform_write copy_page_from_iter_atomic ext4_da_write_end ext4_da_do_write_end block_write_end __block_commit_write folio_mark_uptodate // Buffered read 4096 from 0 smp_wmb() ext4_file_read_iter set_bit(PG_uptodate, folio_flags) generic_file_read_iter i_size_write // 2048 filemap_read unlock_page(page) filemap_get_pages filemap_get_read_batch folio_test_uptodate(folio) ret = test_bit(PG_uptodate, folio_flags) if (ret) smp_rmb(); // Ensure that the data in page 0-2048 is up-to-date. // New buffered write 2048 from 2048 ext4_buffered_write_iter generic_perform_write copy_page_from_iter_atomic ext4_da_write_end ext4_da_do_write_end block_write_end __block_commit_write folio_mark_uptodate smp_wmb() set_bit(PG_uptodate, folio_flags) i_size_write // 4096 unlock_page(page) isize = i_size_read(inode) // 4096 // Read the latest isize 4096, but without smp_rmb(), there may be // Load-Load disorder resulting in the data in the 2048-4096 range // in the page is not up-to-date. copy_page_to_iter // copyout 4096 In the concurrency above, we read the updated i_size, but there is no read barrier to ensure that the data in the page is the same as the i_size at this point, so we may copy the unsynchronized page out. Hence adding the missing read memory barrier to fix this. This is a Load-Load reordering issue, which only occurs on some weak mem-ordering architectures (e.g. ARM64, ALPHA), but not on strong mem-ordering architectures (e.g. X86). And theoretically the problem doesn't only happen on ext4, filesystems that call filemap_read() but don't hold inode lock (e.g. btrfs, f2fs, ubifs ...) will have this problem, while filesystems with inode lock (e.g. xfs, nfs) won't have this problem. Link: https://lkml.kernel.org/r/20231213062324.739009-1-libaokun1@huawei.com Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Cc: Andreas Dilger <adilger.kernel(a)dilger.ca> Cc: Christoph Hellwig <hch(a)infradead.org> Cc: Dave Chinner <david(a)fromorbit.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Ritesh Harjani (IBM) <ritesh.list(a)gmail.com> Cc: Theodore Ts'o <tytso(a)mit.edu> Cc: yangerkun <yangerkun(a)huawei.com> Cc: Yu Kuai <yukuai3(a)huawei.com> Cc: Zhang Yi <yi.zhang(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: mm/filemap.c Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- mm/filemap.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/mm/filemap.c b/mm/filemap.c index 84aa4ff2ed7b..180a0f77c704 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -2520,6 +2520,15 @@ ssize_t generic_file_buffered_read(struct kiocb *iocb, end_offset = min_t(loff_t, isize, iocb->ki_pos + iter->count); + /* + * Pairs with a barrier in + * block_write_end()->mark_buffer_dirty() or other page + * dirtying routines like iomap_write_end() to ensure + * changes to page contents are visible before we see + * increased inode size. + */ + smp_rmb(); + while ((iocb->ki_pos >> PAGE_SHIFT) + pg_nr > (end_offset + PAGE_SIZE - 1) >> PAGE_SHIFT) put_page(pages[--pg_nr]); -- 2.31.1

2 1

2024

2023

2022

2021

2020

2019

Kernel